How are my gamma/X11 settings being saved?

AmagicalFishy · 2021-02-16 05:26:55

I just got a new monitor (which I use w/ my laptop) and it's default gamma is too high. Unlike my old one, there is no option on the monitor itself to change the gamma. This means that I can only control the gamma via software—instead of set-and-forget as I had prior.

The problem is that whenever RedShift changes the colors on the monitor, it resets the gamma instead of changing the colors relative to the currently set gamma. Similarly, whenever I restart my computer, the gamma resets.

I don't have any .xorg.conf files; my /etc/X11/xorg.conf.d is empty (this kind of stuff has always been a huge pain in the ass); I've had to do so many things to get the output working appropriately that I don't even know what I"m using at this point lol). My /etc/X11/xinitrc/xinitrc looks like this: https://pastebin.com/GAEU2whH ... but I don't think that's actually being used (none of the commands @ the bottom of the file are actually found on my system, and noen of the files it references @ the top of the file exist).

I can change the settings temporarily with "nvidia-settings", but the moment I exit it everything resets (and, if I can manage to get it to **not** reset, everything resets when RedShift turns on or I restart the computer anyway).

I've tried various xorg.conf files, but they're just ignored. The only one that seems to be used is in /usr/share/X11/xorg.conf.d/10-nvidia-drm-outputclass.conf, and that's meager:

Section "OutputClass"
    Identifier "nvidia"
    MatchDriver "nvidia-drm"
    Driver "nvidia"
    Option "AllowEmptyInitialConfiguration"
    ModulePath "/usr/lib/nvidia/xorg"
    ModulePath "/usr/lib/xorg/modules"
EndSection

Note: There's no Monitor section, so I'm assuming this can't be where X11 is getting its config-stuff from.

I can save monitor-placement and things like this via KDE Plasma's settings, and all of that persists, so presumably settings are saved somewhere (there's also a gamma-correction section in the settings, but it only changes the gamma for my laptop screen—there's no option for changing the gamma of an external monitor anywhere).

My $XDG_SESSION_TYPE is "x11" so I'm definitely not using Wayland. The only files that have ".conf" in any X11 folder on my system are:

/etc/X11/xorg.conf.d
/etc/X11/xorg.conf.d/20-intel.conf.bak
/etc/X11/xorg.conf.d/20-nvidia.conf.bak
/usr/lib/qt/mkspecs/unsupported/qnx-X11-g++/qmake.conf
/usr/share/X11/xorg.conf.d
/usr/share/X11/xorg.conf.d/10-nvidia-drm-outputclass.conf
/usr/share/X11/xorg.conf.d/10-quirks.conf
/usr/share/X11/xorg.conf.d/40-libinput.conf

The only one with anything Nvidia related at all is the drm-outputclass.conf file.

There is an ".nvidia-settings-rc" file on my homepage which is, apparnetly, generated by nvidia-settings—but if I change that directly, it just resets to what it was as if I hadn't done anything. Plus, even if I could change things via nvidia-settings—they still get reset when KDE Night Color turns on. :l

Basically: I have no idea what I'm doing, how my monitor configurations are saved or customized, and am just vomiting out as much (I think) relevant info. as I can.

Last edited by AmagicalFishy (2021-02-16 05:38:26)

loqs · 2021-02-16 05:42:59

Find the correct value using xgamma from xorg-xgamma then add a Gamma entry in the monitor section see xorg.conf.5 and Xorg#Monitor_settings.

AmagicalFishy · 2021-02-16 05:53:40

That doesn't work; I mentioned in the post that the .conf files are ignored.

Last edited by AmagicalFishy (2021-02-16 05:54:58)

kokoko3k · 2021-02-16 05:56:00

AFAIK, redhsift should not reset the existing gamma ramp unless started with "-P"
https://man.archlinux.org/man/redshift.1

Ropid · 2021-02-16 05:56:23

Redshift uses the gamma feature to do its color change. This is why it will clash with your gamma settings. I can see something about a gamma config file setting in the redshift man-page. Maybe you can make redshift combine its color shift work with your gamma settings? If redshift has a feature like that, it would solve your problem. If this doesn't work, then you have to give up on redshift.

About where the result of running a command like "xgamma" or "xrandr --gamma" is saved: it's not saved anywhere. You have to make the command run at login to apply it every time.

You can run commands at desktop startup in a bash script file "~/.xprofile" if you use a graphical login. You need to create the ~/.xprofile file yourself, it doesn't exist by default. You can also run commands at startup through the KDE settings. This would then (probably?) only work for KDE while .xprofile works for all desktops.

For the nvidia-settings tool, you have to run a command "nvidia-settings --load-config-only" at login to make the tool apply your saved settings, again with "~/.xprofile" or similar.

There is also a gamma config setting described somewhere in "man xorg.conf". I never tried it. I would assume it's just like running xgamma or xrandr except the Xorg server would re-run it automatically when you disconnect and connect a monitor.

loqs · 2021-02-16 06:06:47

AmagicalFishy wrote:

That doesn't work; I mentioned in the post that the .conf files are ignored.

/etc/X11/xorg.conf.d
/usr/share/X11/xorg.conf.d

Directories

/etc/X11/xorg.conf.d/20-intel.conf.bak
/etc/X11/xorg.conf.d/20-nvidia.conf.bak

Wrong extension

/usr/lib/qt/mkspecs/unsupported/qnx-X11-g++/qmake.conf

Wrong path

/usr/share/X11/xorg.conf.d/10-nvidia-drm-outputclass.conf
/usr/share/X11/xorg.conf.d/10-quirks.conf
/usr/share/X11/xorg.conf.d/40-libinput.conf

10-nvidia-drm-outputclass.conf you agree works. 10-quirks.conf do you have matching hardware to conclude the config is not working? 40-libinput.conf how did you conclude this config file is not working?

What was the contents of the config file you created with a Monitor section with a gamma entry that did not work?
Edit:
Does creating /etc/X11/xorg.conf.d/monitor.conf with contents

Section "Monitor"
        Identifier "Monitor0"
        Gamma 0.0
EndSection

Have any effect? It may well apply to the wrong display. Please post the contents of Xorg.log.

Last edited by loqs (2021-02-16 06:22:25)

AmagicalFishy · 2021-02-16 07:24:41

That does not have any effect, no. I know that the backup files in /etc/X11/xorg.conf.d are the wrong extension (they're backups from when I was messing with this stuff before).

I created a file "10-display-outputs.conf" in /usr/share/X11/xorg.conf.d with the contents:

Section "Device" 
    Identifier "NVIDIA Card"
    Driver "nvidia"
EndSection

Which had an effect: it disabled my laptop's monitor and enabled *only* my HDMI external monitor. I tried a bunch of different monitor, screen, and device configurations to no effect. AFAICT, both the HDMI output and the internal monitor drivers are "nvidia". If I remove that above section, then everything goes back to normal—that is, both monitors display as expected (but with the gamma-too-high on my external monitor).

According to the Xorg docs, a Monitor section needs to be associated w/ a Device section, and a Screen section needs to be associated w/ a Monitor section. Apparently the only way to get a Monitor section associated w/ a particular output is by adding an option to the appropriate Device section, something like (if your Monitor section identifier is "ExtMonitor") "Option Monitor-eDP-1 ExtMonitor". I tried this (taking the output names supplied by xrandr) but it didn't have any effect either.

I would expect something like:

Section "Device" 
    Identifier "NVIDIA Card"
    Driver "nvidia"
    Option "Monitor edP-1" "Internal Monitor"
    Option "Monitor HDMI-1-0" "External Monitor"
EndSection

Section "Monitor"
    Identifier "Internal Monitor"
EndSection

Section "Monitor"
    Identifier "External Monitor"
EndSection

To at least turn on both monitors.

**Xorg.1.log**: https://pastebin.com/NTH0LLbi
**Xorg.0.log**: https://pastebin.com/50HYLtTD

Edit: Ok, I think the output names given by xrandr are NOT the output names that xorg wants

So I see:

[   576.794] (--) NVIDIA(0): Valid display device(s) on GPU-0 at PCI:1:0:0
[   576.794] (--) NVIDIA(0):     DFP-0 (boot)
[   576.794] (--) NVIDIA(0):     DFP-1
[   576.794] (--) NVIDIA(0):     DFP-2

In my logs. When I change the above mentioned options to DFP-1/2/3 the options are apparently accepted (I don't see a "Option is ignored" message) but... nothing happens.

I found a /root/xorg.conf.new file while searching for what the system is doing default. This has two monitor sections, to which I added the Gamma option. This didn't change anything.
why is this so difficult i just want to change the god damned gamma on my monitor -__________-

Last edited by AmagicalFishy (2021-02-16 07:53:24)

loqs · 2021-02-16 07:56:45

[     6.520] (II) xfree86: Adding drm device (/dev/dri/card1)
[     6.520] (II) xfree86: Adding drm device (/dev/dri/card0)

How are the two GPUs configured to work? How is X started? You mention an external monitor and the internal laptop display are they both always connected?

AmagicalFishy · 2021-02-16 08:10:23

KDE Plasma starts X using sddm. AFAICR, the GPUs weren't configured explicitly; I just installed the nvidia drivers. When I was setting this up it was equally a pain, so I tried everything from Optimus Manager to nouveau and settled on the nvidia drivers. The external monitor is connected roughly 50% of the time.

A big issue here is that KDE apparently saves monitor/display settings somewhere, and every time the computer is booted up those settings are restored, including things like the relative location of each monitor. If I unplug the external monitor, then everything shifts to the laptop monitor as expected—where is KDE storing all of this? If I find that out, I could presumably change a gamma setting for the external monitor. It doesn't look like these things are being initially saved via any .conf files.

kokoko3k · 2021-02-16 08:33:06

If i understood the problem well, redshift takes over your gamma settings when it starts and while it runs.
First, redshift gives you the ability to apply an Additional gamma correction, from the manpage:

       -g R:G:B
              Additional gamma correction to apply.
[..]
       An example configuration file with the same effect as the above command line:
           [redshift]
[..]
              gamma=0.8
[..]

This should be enough to take care of all your needs (day/night temperature AND personalized gamma for your monitor).

If not (eg: multiple monitors, personalized monitor(s) color profiles/complex luts), bear in mind that there are multiple methods to adjust gamma ramp that can coexist.
On my intel igp, redshift returns the following:

koko@Gozer# redshift -m list
Available adjustment methods:
  drm
  randr
  vidmode
  dummy

I don't remember which methods are handled by nvidia driver (redhisft could list them all even if not supported, i don't know, so check and don't assume they will work just because they are listed), but if nvidia supports at least two methods (but dummy one, of course), then you can apply 2 overlapping, yet independent/self-contained, gamma corrections. One with redshift and the other with kde or xcalib,xgamma and so on.

-EDIT-
Also, check this, it seems like a third option (and the simpler one, if it works).
There they speak about a preserve parameter i couldn't find in the redshift manpage that should alter the current gamma instead of cooking it from zero, but you've to make sure redshift starts after the desidered gamma has been set.
Your choice.
https://github.com/jonls/redshift/issues/309

Last edited by kokoko3k (2021-02-16 08:46:21)

seth · 2021-02-16 08:37:22

the GPUs weren't configured explicitly … setting this up it was equally a pain, so I tried everything from Optimus Manager to nouveau and settled on the nvidia drivers

You do understand that this is contradictive?

both the HDMI output and the internal monitor drivers are "nvidia".

No.

We need to sort out your otimus config first.
The internal display is wired to the intel chip, the external to the nvidia one and the latest logs you shared show you're running on the intel chip.
In order to get the external display to show somthing, you'd have to use sth. like https://wiki.archlinux.org/index.php/PR … erse_PRIME so we *must* know what you're doing.

I think the output names given by xrandr are NOT the output names that xorg wants

Yes they are.

I don't see a "Option is ignored" message

Neither are in the shared logs.

I found a /root/xorg.conf.new

Which is just some irrelevant file you saved there, likely w/ nvidia-settings.

Please post *every* file in

/{usr/share,etc}/X11/xorg.conf*

and an updated xorg log and the output of "xrandr -q" so we get an idea what you're at and don't change things until somebody told you to not create a moving target.

AmagicalFishy · 2021-02-16 09:02:49

I said that tte GPU's weren't configured explicitly, not that they weren't configured at all.

The output names given by xrandr are not the output names Xorg wants—when I use those output names in a .conf file I get an error that says something like "Option Monitor-edP-1 was not used", but when I use the output names given by the Xorg logs, I don't get an error. Similarly, this question indicates the same thing. (According to the comments, some systems are consistent. Mine is not).

"/root/xorg.conf.new" is generated by the "X -configure" command.

There are no files in /etc/X11/xorg.conf.d
The only file relevant to NVIDIA stuff is 10-nvidia-drm-outputclass.conf, which contains:

Section "OutputClass"
    Identifier "nvidia"
    MatchDriver "nvidia-drm"
    Driver "nvidia"
    Option "AllowEmptyInitialConfiguration"
    ModulePath "/usr/lib/nvidia/xorg"
    ModulePath "/usr/lib/xorg/modules"
EndSection

The other two files contain this:
10-quirks.conf

# Collection of quirks and blacklist/whitelists for specific devices.


# Accelerometer device, posts data through ABS_X/ABS_Y, making X unusable
# http://bugs.freedesktop.org/show_bug.cgi?id=22442 
Section "InputClass"
        Identifier "ThinkPad HDAPS accelerometer blacklist"
        MatchProduct "ThinkPad HDAPS accelerometer data"
        Option "Ignore" "on"
EndSection

# https://bugzilla.redhat.com/show_bug.cgi?id=523914
# Mouse does not move in PV Xen guest
# Explicitly tell evdev to not ignore the absolute axes.
Section "InputClass"
        Identifier "Xen Virtual Pointer axis blacklist"
        MatchProduct "Xen Virtual Pointer"
        Option "IgnoreAbsoluteAxes" "off"
        Option "IgnoreRelativeAxes" "off"
EndSection

# https://bugs.freedesktop.org/show_bug.cgi?id=55867
# Bug 55867 - Doesn't know how to tag XI_TRACKBALL
Section "InputClass"
        Identifier "Tag trackballs as XI_TRACKBALL"
        MatchProduct "trackball"
        MatchDriver "evdev"
        Option "TypeName" "TRACKBALL"
EndSection

# https://bugs.freedesktop.org/show_bug.cgi?id=62831
# Bug 62831 - Mionix Naos 5000 mouse detected incorrectly
Section "InputClass"
        Identifier "Tag Mionix Naos 5000 mouse XI_MOUSE"
        MatchProduct "La-VIEW Technology Naos 5000 Mouse"
        MatchDriver "evdev"
        Option "TypeName" "MOUSE"
EndSection

40-libinput.conf

# Match on all types of devices but joysticks
#
# If you want to configure your devices, do not copy this file.
# Instead, use a config snippet that contains something like this:
#
# Section "InputClass"
#   Identifier "something or other"
#   MatchDriver "libinput"
#
#   MatchIsTouchpad "on"
#   ... other Match directives ...
#   Option "someoption" "value"
# EndSection
#
# This applies the option any libinput device also matched by the other
# directives. See the xorg.conf(5) man page for more info on
# matching devices.

Section "InputClass"
        Identifier "libinput pointer catchall"
        MatchIsPointer "on"
        MatchDevicePath "/dev/input/event*"
        Driver "libinput"
EndSection

Section "InputClass"
        Identifier "libinput keyboard catchall"
        MatchIsKeyboard "on"
        MatchDevicePath "/dev/input/event*"
        Driver "libinput"
EndSection

Section "InputClass"
        Identifier "libinput touchpad catchall"
        MatchIsTouchpad "on"
        MatchDevicePath "/dev/input/event*"
        Driver "libinput"
EndSection

Section "InputClass"
        Identifier "libinput touchscreen catchall"
        MatchIsTouchscreen "on"
        MatchDevicePath "/dev/input/event*"
        Driver "libinput"
EndSection

Section "InputClass"
        Identifier "libinput tablet catchall"
        MatchIsTablet "on"
        MatchDevicePath "/dev/input/event*"
        Driver "libinput"
EndSection

Here are Xorg.0.log and Xorg.1.log; these are the most recent ones which reflect the default settings (i.e. - both monitors working as intended, one monitor's gamma too high).

I am not using PRIME or reverse PRIME, nor am I using optimus-manager. I'm pretty sure, if I'm using nouveau + Nvidia, that must have come from the most basic of setups. I don't have an "intel" module.

Last edited by AmagicalFishy (2021-02-16 09:06:21)

seth · 2021-02-16 09:20:37

"Option Monitor-edP-1 was not used"

Because that's nonsensical.

Section "Monitor"
	Identifier "edP-1"
	Gamma "0.8"
EndSection

If you use the correct output name from xrandr (probably some HDMI?) and ensure no userspace is intervening (redshift etc.), can you play w/ the gamma value this way?

The modesetting driver is controlling the intel chip, the nvidia driver the nvidia chip and you can just remove xf86-video-nouveau
Internal display:

[     6.070] (II) modeset(0): EDID for output eDP-1
[     6.070] (II) modeset(0): Manufacturer: AUO  Model: 319d  Serial#: 585803690

External display:

[     7.498] (--) NVIDIA(GPU-0): Microstep MSI MAG270VC2 (DFP-0): connected
[     7.498] (--) NVIDIA(GPU-0): Microstep MSI MAG270VC2 (DFP-0): Internal TMDS
[     7.499] (--) NVIDIA(GPU-0): Microstep MSI MAG270VC2 (DFP-0): 600.0 MHz maximum pixel clock

[     5.751] (--) PCI:*(0@0:2:0) 8086:3e9b:1558:8500 rev 0, Mem @ 0xa2000000/16777216, 0x80000000/268435456, I/O @ 0x00005000/64, BIOS @ 0x????????/131072

Intel chip active, feel free to check glxinfo.

=> Something redirects the intel source into the nvidia sink, you might do that w/ krandr (ie. KDE)

AmagicalFishy · 2021-02-16 16:08:38

That results in an error

[  3251.516] Parse error on line 12 of section Monitor in file /usr/share/X11/xorg.conf.d/10-nvidia-drm-outputclass.conf
	gamma correction value(s) expected
 either one value or three r/g/b values.

On the other hand! Using:

Section "Monitor"
	Identifier "HDMI-0-1"
	Gamma 0.2 0.2 0.2
EndSection

Does not, but my gamma isn't actually changed at all, nor does it change if I use different identifiers (the ones provided by xorg.log for example, or eDP-1, the output of my laptop screen). KDE-Night Color/RedShift are disabled.

It makes sense that something would have to pass through the Intel chip to the Nvidia one yeah, especially if that something is KDE

Last edited by AmagicalFishy (2021-02-16 16:09:43)

seth · 2021-02-16 16:45:30

Apparently the gamam setting doesn't like the quotes, sorry.

Can you change

xrandr --output HDMI-0-1 --gamma  0.2:0.2:0.2

(Default is 1:1:1)

AmagicalFishy · 2021-02-16 17:46:59

Yeah, that works (but it resets as soon as e.g. KDE Night Color turns on and turns off)

Last edited by AmagicalFishy (2021-02-16 18:07:16)

seth · 2021-02-16 20:40:37

but it resets as soon as e.g. KDE Night Color turns on and turns off

I'm afraid that's inevitable since all those measures work on the same infrastructure (the server gamma ramps)

You could perhaps use https://aur.archlinux.org/packages/sunwait/ to clobber your own daylight aware gamma adjustment that takes the basic output differences into account?

AmagicalFishy · 2021-02-17 03:59:34

Hrm. After all that, I might just end up returning this monitor and purchasing the older version.

why would they make a monitor with so many different options but no gamma option!?

Anyway, thanks for all your help.

Arch Linux

#1 2021-02-16 05:26:55

How are my gamma/X11 settings being saved?

#2 2021-02-16 05:42:59

Re: How are my gamma/X11 settings being saved?

#3 2021-02-16 05:53:40

Re: How are my gamma/X11 settings being saved?

#4 2021-02-16 05:56:00

Re: How are my gamma/X11 settings being saved?

#5 2021-02-16 05:56:23

Re: How are my gamma/X11 settings being saved?

#6 2021-02-16 06:06:47

Re: How are my gamma/X11 settings being saved?

#7 2021-02-16 07:24:41

Re: How are my gamma/X11 settings being saved?

#8 2021-02-16 07:56:45

Re: How are my gamma/X11 settings being saved?

#9 2021-02-16 08:10:23

Re: How are my gamma/X11 settings being saved?

#10 2021-02-16 08:33:06

Re: How are my gamma/X11 settings being saved?

#11 2021-02-16 08:37:22

Re: How are my gamma/X11 settings being saved?

#12 2021-02-16 09:02:49

Re: How are my gamma/X11 settings being saved?

#13 2021-02-16 09:20:37

Re: How are my gamma/X11 settings being saved?

#14 2021-02-16 16:08:38

Re: How are my gamma/X11 settings being saved?

#15 2021-02-16 16:45:30

Re: How are my gamma/X11 settings being saved?

#16 2021-02-16 17:46:59

Re: How are my gamma/X11 settings being saved?

#17 2021-02-16 20:40:37

Re: How are my gamma/X11 settings being saved?

#18 2021-02-17 03:59:34

Re: How are my gamma/X11 settings being saved?

Board footer