Johannes Stezenbach wrote:
> ...
>>Now, inserting this byte order conversion before colour space
>>conversion fixed OSD colours for me:
>>
>>---
>> color = ((color & 0xFF) << 24) | ((color & 0xFF00) << 8) |
>> ((color & 0xFF0000) >> 8) | ((color & 0xFF000000) >> 24);
>>---
>>
>>It supposedly breaks OSD for hardware of opposite byte order, so some
>>kind of byte order detection logic around it. I do not know how that
>>is supposed to be done in kernel code.
>
>
> (you would use:
> #inlude <asm/byteorder.h>
> ...
> color= cpu_to_le32(color)
> or
> cpu_to_le32s(color);
> )
>
> I believe that is a vdr bug. Vdr swaps the byteorder for __BIG_ENDIAN
> in dvbosd.c:cDvbOsd::Flush(). I don't know why. It's not necessary,
> just use CPU byte order verywhere.
>
>
> Johannes
Well, apparently it _was_ necessary at some point, because people complained
to _me_ and made me do
#if __BYTE_ORDER == __BIG_ENDIAN
// actually the driver itself should access the bytes according to the current endianness!
colors[i] = ((colors[i] & 0xFF) << 24) | ((colors[i] & 0xFF00) << 8) | ((colors[i] & 0xFF0000) >> 8) | ((colors[i] & 0xFF000000) >> 24);
#endif
in VDR's cDvbOsd::Flush() (note the comment ;-).
Has this changed somewhere down the road of driver development?
If so, please advise how I should check for the actual driver version here
in order to find out whether there is a driver in use that has this
fixed or not.
Klaus
