Support for running Redshift outside X

[maandree]

Using Direct Rendering Manager, Redshift can now change gamma ramps for the monitors while running in Linux's TTY. This requires that the users is a member of the group video (as is always required when working with graphics without a display server.)

If Direct Rendering Manager is used to change the gamma ramps while an graphical session is active in the foreground (and X display is running on the active VT) Direct Rendering Manager will ignore the request and report that you do not have sufficient permissions. This rejection is ignored so nothing funny happens if the users opens a VT with a graphical session.

Changes to gamma ramps using Direct Rendering Manager are in effect on all VT:s with the exception on graphical ones because the X servers keeps tracks of gamma ramps for each display and applies the gamma ramps associated with a display when it is reactivated.

Possible improvements:

• Figure out whether Redshift is associated with an X display, and user DRM otherwise.

[jonls]

open should be enough to determine if permissions are ok by checking errno (or maybe I misunderstand this TODO?).

[maandree]

Note well expressed TODO: The idea is that on failure the permission bits, owner and groups as well as you group membership should be read to determine why your are not able to open it and give a good explaination why you cannot use it. For example, the sysadmin might have given you membership to video but have change the permissions so that only root can get access to the graphics card as it can change monitor resolution which for example some schools (for some reason I do not understand) remove that permission from you.

[jonls]

Very cool, I did not know that DRM was capable of adjusting gamma ramps.

[maandree]

Grep:ing /usr/include is king!

[jonls]

Some weird style here, should be } else {...

[maandree]

I have fixed the check at atoi and consistency with braces. But I do not know how to squash the commits without having to rewrite them and all commits in the other pull requests.

[jonls]

Ok then how about you squash these and I merge them, and you can then rebase your other pulls on the new master?

[maandree]

I have squash the commits in this branch.

[jonls]

it seems that we could end here if drmModeCrtcGetGamma fails, in which case perror("malloc") is misleading.

[jonls]

Great, I did some more testing and I have a few more questions. I noticed that there is no error message when there is a failure to adjust gamma, instead it will just pretend that everything is ok. Did you add more error reporting in the multimonitor branch? If you already did we can just postpone it for that pull.

I see that you put drm at the top of the gamma_methods array in redshift.c which means that it will take priority above randr and vidmode. I don't think that is right since most people will still expect randr to run by default. I think drm should have autostart set to 0 so that it will only start when explicitly selected.

[maandree]

I noticed that there is no error message when there is a failure to adjust gamma, instead it will just pretend that everything is ok.

Everything is ok, I tought I added a comment but perhaps I forget. But I did write about it in the pull request:

If Direct Rendering Manager is used to change the gamma ramps while an graphical
session is active in the foreground (and X display is running on the active VT) Direct
Rendering Manager will ignore the request and report that you do not have sufficient
permissions. This rejection is ignored so nothing funny happens if the users opens a
VT with a graphical session.

I see that you put drm at the top of the gamma_methods array in redshift.c which means that it will take priority above randr and vidmode.

Did not think about that, I just went alphabetical. I will fix that.

[jonls]

Ok, what I mean is, e.g if DRM is supported but the size of the gamma ramp is returned as 0 then we skip that gamma ramp because we cannot do any adjustment but actually we should probably report an error so the user can determine that something is not working.

[maandree]

Oh, I missed to check that, I will add a check with an error report.

[jonls]

Works fine for me now. I noticed that the gamma adjustment is not reinstated when switching to an X screen and back again, which is a pity. Do you see the same issue? If you squash the commits again I will merge.

[maandree]

Yes, the gamma settings from the X display is used. If you have on instance for X and another instance for TTY, it shouldn't be noticable provided that they have the same configurations.

[maandree]

I have squashed the commits.