Johannes Stezenbach wrote:
> Klaus Schmidinger wrote:
>
>>Johannes Stezenbach wrote:
>>
>>>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.
>>
>>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?
>
>
> Not that I know of. AFAIK the ttpci driver never required
> byte-swapping here ("color" is not passed to the hardware,
> it's only used on the CPU so it's always CPU-byteorder).
>
> Maybe swapping is necessary for DXR3?
>
> Johannes
Well, then it should have been done in the DXR3 driver.
I have no problem with deleting these lines from VDR, since
I don't use a big endian machine (IMHO big endian was one of
the worst ideas ever in computer history...).
So, somebody with a big endian machine please test VDR without the
lines mentioned above and let me know if it works.
But please also do so with the old DVB driver, not just dvb-kernel.
VDR is supposed to still run with the DVB driver (at least that's
what I do ;-).
Klaus
