You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Reported in version: 1.2.14 Reported for operating system, platform: Linux, x86_64
Comments on the original bug report:
On 2010-03-13 09:20:57 +0000, Donald wrote:
After upgrading to Xorg 7.5 (clean install from source, with removing previous 7.4 release) many games do not set screen brightness correctly. After searching for a solution I found at least two same reports on Archlinux and Debian bugtrackers (http://bugs.archlinux.org/task/17446 and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565638 respectively). Screen becomes very dark, r_gamma do not do anything. As a temporary solution gamma can be adjusted with xgamma tool, with loses on color quality.
Steps to reproduce:
Install xorg 7.5
Run any game that uses SDL and gamma control (for example, OpenArena).
Bug appears on x86 too, with any drivers available today (proprietary and open source). For me it appears on ATI and NVIDIA cards (on NVIDIA - both proprietary and nouveau drivers). Note that native glx games such as Nexuiz are working properly.
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...
On 2010-03-24 00:56:41 +0000, Donald wrote:
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.
On 2010-03-25 01:54:40 +0000, Sam Lantinga wrote:
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?
On 2010-03-31 10:05:23 +0000, Donald wrote:
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.
On 2010-04-16 03:12:30 +0000, carl wrote:
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
On 2010-04-17 04:28:12 +0000, Laurento Frittella wrote:
A possible workaround consists in changing gamma before launching the game:
$ xgamma -gamma 1.6
On 2010-05-02 20:46:35 +0000, Donald wrote:
No changes?
Maybe I can help by providing any debugging information?
On 2010-08-15 10:59:15 +0000, Kevin Locke wrote:
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.
On 2010-08-15 11:00:46 +0000, Kevin Locke wrote:
Created attachment 533
Add support for XRandR and VidMode gamma ramps
On 2010-10-04 00:15:40 +0000, Donald wrote:
(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.
On 2010-11-06 13:40:42 +0000, Steven wrote:
Testing it with my old Xorg-7.1/Fedora 7/Nvidia proprietry drivers, and it makes my screen go blank.
On 2011-02-16 04:42:58 +0000, Sam Lantinga wrote:
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.
On 2015-10-17 03:48:40 +0000, Daniel Scharrer wrote:
SDL 2 does have SDL_SetWindowGammaRamp it still doesn't work with as of 2.0.3
This bug report was migrated from our old Bugzilla tracker.
These attachments are available in the static archive:
Reported in version: 1.2.14
Reported for operating system, platform: Linux, x86_64
Comments on the original bug report:
On 2010-03-13 09:20:57 +0000, Donald wrote:
On 2010-03-19 01:16:59 +0000, Ozkan Sezer wrote:
On 2010-03-20 16:42:05 +0000, Sven Arvidsson wrote:
On 2010-03-24 00:56:41 +0000, Donald wrote:
On 2010-03-25 01:54:40 +0000, Sam Lantinga wrote:
On 2010-03-31 10:05:23 +0000, Donald wrote:
On 2010-04-16 03:12:30 +0000, carl wrote:
On 2010-04-17 04:28:12 +0000, Laurento Frittella wrote:
On 2010-05-02 20:46:35 +0000, Donald wrote:
On 2010-08-15 10:59:15 +0000, Kevin Locke wrote:
On 2010-08-15 11:00:46 +0000, Kevin Locke wrote:
On 2010-10-04 00:15:40 +0000, Donald wrote:
On 2010-11-06 13:40:42 +0000, Steven wrote:
On 2011-02-16 04:42:58 +0000, Sam Lantinga wrote:
On 2015-10-17 03:48:40 +0000, Daniel Scharrer wrote:
On 2016-11-16 07:02:29 +0000, Luke wrote:
The text was updated successfully, but these errors were encountered: