Hi Ove, Thanks for the kind help - I was just diving into the palette code to try to work out how it worked!
Do you actually run Windows in a 256-color mode? If not, then Windows does not have a need for messing with a system palette, so it neither honors realization requests nor does it send any palette messages (not even WM_QUERYNEWPALETTE, which wine always sent last time I checked).
That was what interested me from Alexanders update - I run my windows system in 16 bit and my Linux system in 24 bit color, so I was even more suprised that the palette needed playing with.
So if windows would not generate WM_QUERYNEWPALETTE inside RealizePalette for >256 colours? Looking through the code I think it is 'easier' to do it inside palette.c since we maintain a flag, X11DRV_PALETTE_VIRTUAL for true colour, otherwise we need to look it up each time.
I have 2 complete guesses af a fix, any thoughts as to which is more appropriate? (As they both work for me but could easily break something!)
/* For X11DRV_PALETTE_VIRTUAL (>256 colours), no need to realize */ if( X11DRV_PALETTE_PaletteFlags & X11DRV_PALETTE_VIRTUAL )) return 0;
1. Dont do updating of the mapping for truecolour? Put the code at the top of X11DRV_RealizePalette so we skip the rest 2. Do the mapping but fake a zero return code? Put the code at the bottom of X11DRV_RealizePalette
Any thoughts which is better?
(My current patch which I will run with for now is attached)
Thanks! Jason