Bug 1227956 - GNOME doesn't respect xorg.conf Gamma settings
Summary: GNOME doesn't respect xorg.conf Gamma settings
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: gdm
Version: 22
Hardware: All
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-06-03 23:35 UTC by Sean Lynn Rhone
Modified: 2016-07-19 20:09 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-07-19 20:09:41 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
xorg.conf with Gamma option present (960 bytes, text/plain)
2015-06-03 23:35 UTC, Sean Lynn Rhone
no flags Details

Description Sean Lynn Rhone 2015-06-03 23:35:58 UTC
Created attachment 1034509 [details]
xorg.conf with Gamma option present

The monitors I use and the laptop I have look best when screen gamma is set to 0.8. The default gamma of 1.0 is noticeably too bright.

To fix this on distros using X.Org, I add a Gamma 0.8 option to a xorg.conf file (99-graphics.conf in /usr/share/X11/xorg.conf.d/).

It seems Fedora, openSUSE TW (with GNOME) and even Ubuntu all ignore this Gamma setting visually (Xorg log shows that the screen(s) are using the specified gamma). This has only started happening relatively recently, as of Fedora 22 (worked fine on Fedora 21) and as of Ubuntu (Unity) 15.04 (worked fine on Ubuntu with Unity on 14.10).

This seems to be specific to distros using GNOME. Using Fedora 22 KDE spin, openSUSE TW with Plasma 5, and Xubuntu (Xfce) all respect the Gamma option.


How reproducible:
- Always


Steps to Reproduce:
1. Add Gamma option to monitor under the "Monitor" section on a user-created xorg.conf file
2. Reboot

Actual results:
- Gamma isn't applied visually


Expected results:
- For Gamma to be applied visually


Additional info:
- I'm using AMD hardware, and can confirm this happening on both a Radeon HD 7850 on a desktop, and on a 7660G + 7670M dual graphics laptop (with either EXA or Glamor).

Comment 1 Sean Lynn Rhone 2015-06-03 23:39:48 UTC
I'm thinking there might be some kind of non-obvious color manager running that's taking precedence over xorg.conf, but even after removing gnome-color-manager on Fedora 22, Gamma still isn't set.

Gamma also isn't set at the login screen, which makes me think whatever is happening happens real early. This occurs on both GDM (Fedora 22) and LightDM (Ubuntu 15.04).

Also while I think it's unrelated, this happens on both kernel 3.19 and 4.0.4, and regardless of open-source graphics stack components (stable versions on both Fedora 22 and Ubuntu 15.04, and bleeding-edge on Ubuntu).

Comment 2 Sean Lynn Rhone 2015-06-12 00:27:34 UTC
This also occurs regardless of using intel, radeon, or modesetting drivers, and as-implied, also occurs on a laptop using Intel graphics (Haswell). So this doesn't seem specific to any xorg driver or hardware combination.

This also doesn't seem specific to GDM either. On Fedora 22, I installed LightDM, disabled GDM and enabled LightDM, and gamma is still not set visually on the GNOME session (I'm unsure if it's set on LightDM or not).

I should also add this doesn't seem specific to X.Org or Wayland directly either. Regardless of GNOME session or Login running in Wayland or X.Org, the gamma still isn't set visually.

Comment 3 Fedora End Of Life 2016-07-19 20:09:41 UTC
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.