2011/2/11 Keith Packard <kei...@keithp.com>: > On Thu, 10 Feb 2011 15:23:27 -0800, Keith Packard <kei...@keithp.com> wrote: > >> I'm taking a look at this stuff to see if I can't at least figure out >> how it's supposed to work. I don't want to ship half-a-fix when we know >> it's broken, just not precisely how badly. > > Ok, upon further review, it seems that this patch: > > Author: Maarten Maathuis <madman2...@gmail.com> 2008-12-17 07:56:26 > Committer: Maarten Maathuis <madman2...@gmail.com> 2008-12-17 08:03:12 > Parent: 1556815d34cecb4b4b62d2a4ce813b1435a937ec (Cygwin/X: Initialize > native HWND atom when built !XWIN_MULTIWINDOWEXTWM) > Child: bf65523ab0b39774f07a7ae478ff3f5653fad469 (Cygwin/X: Fix for > mis-aligned icon data creates bad background masks (#4491)) > Branches: many (259) > Follows: xorg-server-1.5.99.1 > Precedes: xorg-server-1.6.99.900 > > randr: Improve per-crtc gamma support. > > - The Gamma values from the monitor section are now used during > initial config. > - The old colormap system is disabled when gamma set hook is > available. > - Gamma values are now persistent for the lifetime of the xserver. > - This requires no driver changes and should be driver ABI > compatible. > > might have benefitted from further review. This patch completely > disables all colormaps for any driver supporting the CRTC-based gamma > functions. > > This means that no visuals other than TrueColor will work > correctly with the current code. > > Your patch will disable the RandR gamma code for pseudo-color screens, > which isn't optimal either (although, probably better than the current > situation). > > A 'correct' solution would merge the current colormap data with the > per-crtc gamma data and store that using the new gamma LUT writing > function (gamma_set). All of that code exists, in the old colormap code, > except it uses the screen gamma table instead of the per-crtc one. > > That seems like a couple of hours of typing to me, at least. > > However, armed with this knowledge, I would suggest that a better > short-term fix would be to re-enable the old colormap code for any > hardware which is using something other than true color for the default > visual. This will leave direct color visuals on 15/16/24 bit hardware > broken, but at least it will let 8-bit hardware work again. > > -- > keith.pack...@intel.com > > _______________________________________________ > xorg-devel@lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: http://lists.x.org/mailman/listinfo/xorg-devel >
I'm willing to look at this again, but i can't give a timeframe right now. So if anyone is in a rush or thinks he/she can fix this relatively quickly, be my guest, otherwise i'll have a look again. I'll admit i wasn't thinking about "odd" visuals when i did this and at the time the review process of patches certainly wasn't what it is today. Maarten. -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
