Support wlroots gamma control protocol

[CameronNemo]

Continuation of #663. Squashed commits.

Adds support for the gamma control protocol that wlroots compositors (sway, wayfire) offer. I have tested this patch on Sway 1.0.

Summary of changes:

• Add wlroots gamma control protocol (copied from wlroots protocols repo): 126 lines of XML
• Add wlroots gamma control implementation: 397 lines of C
• Add os compatibility functions (MIT licensed, from Collabora): 157 lines of C
• Miscellaneous other build adjustments, glued in C code, protocols: 137 lines of xml, autoconf, automake, C, and yaml

[CameronNemo]

Would appreciate recommendation on the CI failure. Is Ubuntu 14.04 still a targeted platform?

[e00E]

Is this the place to report problems instead of the other PR?
For me this is the output while there is no visible color temp or brightness:

$ redshift -v
Solar elevations: day above 3.0, night below -6.0
Temperatures: 6500K at day, 2000K at night
Brightness: 1.00:0.80
Gamma (Daytime): 1.000, 1.000, 1.000
Gamma (Night): 1.000, 1.000, 1.000
Waiting for initial location to become available...
Location: <my location>
Color temperature: 6500K
Brightness: 1.00
Status: Enabled
Period: Night
Color temperature: 2000K
Brightness: 0.80

I am wondering if Gamma (Night): 1.000, 1.000, 1.000 is even correct. Shouldn't it be different from the day values?

$ sway --version
sway version 1.0-rc1-92-gbe0588ef (Feb 21 2019, branch 'makepkg')

[kakurasan]

@CameronNemo PKG_CHECK_VAR is not supported on Ubuntu 14.04 (pkg-config is too old, see https://lists.freedesktop.org/archives/pkg-config/2013-January/000912.html) but supported on 16.04 (replace dist: trusty with dist: xenial in .travis.yml). Also note that Ubuntu 14.04 reaches End of Life on April 30, 2019.

However, there is another issue: wayland-scanner doesn't support private-code on Xenial. This is supported only since version 1.15.0. When libwayland is older than 1.15.0, we should use code (deprecated since 1.15.0) instead of private-code.

I'm preparing Meson changes for this PR in my branch (only for testing) and Travis build passes.

[CameronNemo]

@kakurasan wlroots needs libwayland > 1.16.0 anyway, so disabling wlroots gamma on older build systems (i.e. xenial) is no big deal.

[CameronNemo]

@e00E can you test with wlroots 0.5 and sway 1.0? This is what I see:

Elevaciones solares: día por encima de 3.0 °, noche por debajo de -6.0 °
Temperaturas: 6500 K de día, 4500 K de noche
Brillo : 1.00:1.00
Gamma (Día): 1.000, 1.000, 1.000
Gamma (Noche): 1.000, 1.000, 1.000
A la espera de que la ubicación inicial esté disponible...
Ubicación: 34.00° N, 118.00° O
Temperatura de color: 6500 K
Brillo: 1.00
Estado: Activado
Período: Noche
Temperatura de color: 4500 K
^CEstado: Desactivado
Período: Desconocido
Temperatura de color: 6500 K

[e00E]

It still does not work but I noticed the gamma-control example in wlroots does not work either. Maybe this is a bug with wlroots with my hardware. By not work I mean that there is no error but no visible gamma or brightness change either.

[TheTumultuousUnicornOfDarkness]

I have the same issue: no error with wayland method but no visible gamma change.
I am using Sway 1.0 with wlroots 0.5.0.

[CameronNemo]

@e00E @x0rg please report these issues to wlroots. Include hardware information, logs, and anything else they ask for.

[e00E]

@x0rg swaywm/sway#2700

[zetorian]

This branch has been working almost flawlessly for months now on my system (nvidia optimus laptop - occasionally connected to multiple monitors).

is there any chance of it getting merged upstream?

[CameronNemo]

@zetorian I would personally love that, but it appears the maintainer has not had enough free time to devote to redshift. Hopefully that changes soon.

[cole-h]

FYI: Sway and wlroots just removed the gamma control protocols you were using in favor of ones under the wlr name (or I assume so; redshift wasn't working until I reverted those recent commits). Replacing the gamma-control-client-protocol.h and orbital-authorizer-client-protocol.h includes (and removing any code referencing the orbital header) with wlr-gamma-control-unstable-v1-client-protocol.h solved the issue for me and I now have gamma control back. This diff works well for me, but your mileage may vary.

Hope this helps.

[CameronNemo]

@cole-h AIUI, this issue only affects those running sway from master, yes? Also -- your diff seems to be missing the protocol file changes.

[cole-h]

And anything that uses wlroots (from master), I believe. It makes sense that was missing; I just made enough changes to the code for gamma to work with sway again. Mostly, I just wanted to put this out there for those who were running into the same issue or if it would in some way help you.

[valpackett]

This PR already uses wlr_gamma_control_unstable_v1, not the removed non-v1 version. Header/file name doesn't matter, it's local to this project, what matters is the name in the XML file.

[maximbaz]

I'm using redshift from this PR on two laptops with Arch Linux, sway and generally identical dotfiles, and on one of them I have weird problems:

• Sometimes screen flickers, for a second colors become broken like on the photo below, then redshift restarts and everything goes back to normal
• If I turn redshift off, colors will get broken like on the image below (running redshift again fixes the colors)

If I run redshift from terminal, I get no errors in the console, but normally I use redshift from a systemd service, and my journalctl is full of the errors below:

Process 25051 (redshift) of user 1000 dumped core.

Stack trace of thread 25051:
#0  0x00005631eafb12d7 n/a (redshift + 0xa2d7)
#1  0x00005631eafac2ea n/a (redshift + 0x52ea)
#2  0x00007f4a0904e023 __libc_start_main (libc.so.6 + 0x27023)
#3  0x00005631eafaca6e n/a (redshift + 0x5a6e)

I think when my screen flickers for a second, it is exactly the case when redshift coredumps and restarts.

Any hints or ideas on what could be wrong, how to investigate?

[CameronNemo]

@maximbaz try #663, it has been updated since I opened this.