linuxkms: Prospective fix for rendering to BGRA frame buffers with th…#10509
linuxkms: Prospective fix for rendering to BGRA frame buffers with th…#10509
Conversation
…e software renderer
The implementation was essentially ABGR instead of BGRA. BGRA is defined like this:
[31:0] B:G:R:A 8:8:8:8 little endian
Replaces #10331
|
cc @sandreas Could you try this PR? Thanks :) |
Here are the results: As you see, your patch does not work as expected. I'm suspecting that the display asks for the BGRA spec but does not implement it correctly but just uses the |
|
I think you're right, this might be a hardware issue. I wish I could test BGRA on my machine, but it only supports xrgb :(. Is there any possibility of swapped pins/cables on your hardware? |
This might indeed be a problem. I don't know for sure, that this LCD is made for this hardware - it just fits with the cables. However, since I might not the only one with this problem and the bit shifting is basically the same code for every standard except the one integer with the shifting level (24, 16, 8, 0), it would probably not be a bad idea to be able to reconfigure the RGBA components in a vec to be able to reorder them using a default order for each standard: use proc_macro::TokenStream;
use quote::quote;
use syn::{parse_macro_input, ItemFn, Ident};
#[proc_macro_attribute]
pub fn colors(attr: TokenStream, item: TokenStream) -> TokenStream {
let order = parse_macro_input!(attr as syn::punctuated::Punctuated<Ident, syn::Token![,]>);
let func = parse_macro_input!(item as ItemFn);
let shifts = order.iter().map(|ident| {
match ident.to_string().as_str() {
"R" => 24,
"G" => 16,
"B" => 8,
"A" => 0,
_ => panic!("Unknown color {}", ident),
}
});
let extracts = shifts.map(|shift| {
quote! {
((merged >> #shift) & 0xff) as u8
}
});
let sig = &func.sig;
let vis = &func.vis;
let expanded = quote! {
#vis #sig {
[#(#extracts),*]
}
};
expanded.into()
}#[colors(R, G, B, A)]
fn components(merged: i32) -> [u8; 4]; |
|
I've got one more question about the device: Do you know if it's running in little-endian or in big-endian mode? |


…e software renderer
The implementation was essentially ABGR instead of BGRA. BGRA is defined like this:
Replaces #10331