At 01:06 AM 30/10/2001 -0800, you wrote: <snip lot of explanations>
First thanks for all this stuff, really enlightening.
This probably means that you have a 16bpp rgb565 screen. Which seems normal. It also means that the Dib is a bgr888 Dib which does not exist in Windows. So something weird is happening. Here are the interesting kind of lines:
trace:bitmap:X11DRV_DIB_SetImageBits Dib: depth=24 r=ff0000 g=ff00 b=ff trace:bitmap:X11DRV_DIB_SetImageBits Bmp: depth=16/16 r=f800 g=7e0 b=1f
This tells us that the Dib is a 24bpp dib and that it is an RGB dib, the only kind of 24bit DIB in Windows. What tells us that it's an RGB DIB is the r,g,b masks: the red color is encoded in the high bits of the 24bit value: 0xff0000. Then you hace the green, 0xff00, and the blue, 0xff, hence the rgb888 shorthand. Similarly the 'Bmp', i.e. an XImage, is a 16bpp rgb image. Here you will notice that the mask for the green color, 0x7e0, uses 6 bits instead of just 5. This gives you the rgb565 denomination. Finally we are in SetImage so we are converting the Dib into a Bmp, i.e. from rgb888 to rgb565 so we will call Convert_888_to_565_asis (since both are rgb). Now I suspect that with your application the Dib masks don't look like the above
Congratulations, you are entirely right. As in many cases, Wine does not work because it is not tolerant to strange parameters
Actually the dib masks are all equal to 0. Probably the correct fix is to assume an 'asis' (not reversed) conversion when the app does not set any mask.
Gerard