| Summary: | Gamma control do not work with Xorg 7.5 release | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Donald <dj.jankins> |
| Component: | video | Assignee: | Sam Lantinga <slouken> |
| Status: | RESOLVED WONTFIX | QA Contact: | Sam Lantinga <slouken> |
| Severity: | major | ||
| Priority: | P2 | CC: | daniel, erbrochendes, kevin, laurento.frittella, lukebenes, sa, sezeroz, stevenaaus |
| Version: | 1.2.14 | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Attachments: | Add support for XRandR and VidMode gamma ramps | ||
|
Description
Donald
2010-03-13 09:20:57 UTC
I was told that the size of the gamma ramp is no longer 256 in all cases since Xorg 7.4. Maybe the reason? (See tyrquake, http://www.disenchant.net/git/?p=tyrquake;a=commitdiff;h=ed46d97c106471672c571eebd51dedc0508e1225 for example.) This is caused by http://cgit.freedesktop.org/xorg/xserver/commit/?id=91f73b79b7ae64e5b846d1efeb470bb61a913720 I confirmed it by avoiding this change as described here: http://www.mail-archive.com/xorg@lists.freedesktop.org/msg05439.html I guess SDL can be updated, but it kinda sucks as this breaks a lot of old proprietary games such as all titles from iD, UT2004 etc... I did as described in http://www.mail-archive.com/xorg@lists.freedesktop.org/msg05439.html, but it did not worked. Also, I restored Xorg 7.4 from backup and run it with recent 2.6.33 kernel and this bug appeared again (with 2.6.32 gamma work, but Xorg 7.4 was some buggy with 3D and caused crashes on my system), so I lost a chance to update kernel and avoid this. I think this must be fixed in SDL. The code calling X11_SetGammaRamp() assumes that it can set the full 256 entries. I don't have any hardware that I can test this on. Can someone verify the desired mapping from a specific 256 entry gamma ramp to a ramp of a different size? For example, if someone is implementing a red flash, what are the various possible values of the gamma size and how would you map the red channel with 256 entries to that size? Sorry for my late answer. I'm not very familiar with graphic development. According to xdpyinfo output, default number of color cells is 256 on my box. I got the same problem under debian testing with UrbanTerror. is there an work o round? how can i help to fix this bug ASAP! Xorg 7.5 is like this not usable! My System: Debian testing AMD ATI 4850 tested with radeon and fglrx driver A possible workaround consists in changing gamma *before* launching the game: $ xgamma -gamma 1.6 No changes? Maybe I can help by providing any debugging information? I am also experiencing this bug (first noticed in ioquake3). After a bit of investigation, it looks to me like the real problem is that commit 91f73b disabled colormap support for displays that support gamma (since xf86HandleColormaps now returns early for CRTCs which support gamma). The fact that the gamma ramp can be of an arbitrary size is a side-effect of the gamma API provided by XRandR or VidMode. I worked up a patch which adds support for setting the gamma ramp using either XRandR or VidMode. It uses the same nearest-match resizing of the ramp as used in the tyrquake commit mentioned by Ozkan Sezer (although it could easily be converted to use linear interpolation or another method if it is deemed to be better). The real problem with the patch is that the colormap gamma ramp from pre-91f73b is per-window while the XRandR and VidMode gamma ramps are per-screen and persistent. So for non-fullscreen SDL applications, changing the gamma ramp will change the rest of the screen as well. I added save/restore functions so that the gamma ramp will be restored to its original value on shutdown, but if the SDL application crashes or doesn't shutdown the video properly, the user's screen gamma will not return to the original values they set (and, of course, if they use their system preferences to change the gamma while the SDL application is running, the saved values will overwrite their changed values). Also, someone with more knowledge of XRandR should probably look at the code. I'm not sure what assumptions are safe to make about CRTCs being hot plugged during application execution, so I tried to be conservative as possible, but there may be some corner cases I overlooked. Created attachment 533 [details]
Add support for XRandR and VidMode gamma ramps
(In reply to comment #10) > Created an attachment (id=533) [details] > Add support for XRandR and VidMode gamma ramps Thank you, Kevin, for this useful patch! This workaround works for me now. I don't often use windowed mode for SDL applications, so this works for me perfectly. Another, but less perfect workaround for ioquake3 based games I found on gaming forums is setting value of cvar "r_overBrightBits" to zero. Testing it with my old Xorg-7.1/Fedora 7/Nvidia proprietry drivers, and it makes my screen go blank. The gamma API has been removed in SDL 1.3, due to lack of support on many platforms, and the current patch doesn't work on all Xorg distributions. SDL 2 *does* have SDL_SetWindowGammaRamp it still doesn't work with as of 2.0.3 Here's the coresponding X.org bug report: https://bugs.freedesktop.org/show_bug.cgi?id=27222 Please reconsider reimplementing this on top of whatever `xgamma` / `xrandr --gamma` use. The x org server bug was fixed in 1.19. https://cgit.freedesktop.org/xorg/xserver/commit/?id=b4e46c0444bb09f4af59d9d13acc939a0fbbc6d6 https://bugs.freedesktop.org/show_bug.cgi?id=27222 |