redshift stopped working between two revisions

[sydneymeyer]

I have been losely following sway development lately and since my last update redshift appears to have stopped working.

This has happened between the following setups:

Sway built from 14.08.2018 (commit b4887ba) and built from 23.09.2018 (commit 0bc9dc1).

wlroots built from 13.08.2018 (commit 1a73baa) and built from 22.09.2018 (commit f5658c2).

redshift fork from github.com/giucam/redshift built from 24.11.2015 (commit 1b9c8ac11125e2df0b8f9779376dd35cd56d5951).

Linux Kernel Version: 4.17.14-arch1-1-ARCH respective 4.18.9-arch1-1-ARCH from Arch Linux.

I have also tried the wayland branch from github.com/minus7/redshift built from 01.09.2018 (commit a2177ed9942477868ccc514372f32a0fbcbe189e) on the mentioned sway/wlroots combo.

Furthermore, giucam's redshift fork never worked flawlessly on this config. It always threw segmentation faults and worked, i.e. adjusting color temperature, only sporadically, also while exiting with a segmentation fault. Since the last update, it has stopped working completely.

redshift was invoked like "redshift -m wayland -O 3000 -v".

Sway Version:
1.0-alpha.6-39-g0bc9dc19

Sway config:
sway_config.txt

Sway log:
sway_log.txt

Is this perhaps a know issue?

[emersion]

What's your graphics card?

[sydneymeyer]

Intel Core i7 8550u with UHD Graphics 620 on ThinkPad X1 2018.

[emersion]

I can confirm it doesn't work anymore on my Intel graphics card.

@SirCmpwn, I think using the legacy interface for changing gamma tables while using the atomic interface for everything else is breaking redshift on Intel.

[emersion]

Scratch that, it does work but since redshift exits it resets the gamma tables. @minus7, maybe we could block when users use -O?

@sydneymeyer, can you confirm it works if you specify a location, like redshift -v -l 48:48 -m wayland?

[sydneymeyer]

@emersion No, unfortunately it does not. It tries to adjust the temperature gradually from ~6400K to 5000K without actually doing so and exits with segfault if i cancel the process.

[emersion]

Can you try wlroots' gamma control example instead of redshift: https://github.com/swaywm/wlroots/blob/master/examples/gamma-control.c

Can you try wlroots with this branch: https://github.com/emersion/wlroots/tree/intel-gamma

[sydneymeyer]

If i have understood everthing correctly,

"./gamma-control -g 1" gives:

failed to set gamma table

Built wlroots from emersion/wlroots intel-gamma tree with same output.

Same result with redshift, failed to set gamma table with "gamma-control" from
examples.

[minus7]

Last I checked gamma setting didn't work for me with atomic mode on amdgpu (even after @SirCmpwn's patch), so I'm still using WLR_DRM_NO_ATOMIC=1

Edit: still doesn't work in atomic mode

[minus7]

@emersion Oneshot mode shouldn't change behavior on Wayland by blocking, imo. On the other hand, not working in oneshot mode is also a change in behavior

[emersion]

Yeah, it should either error out or work, but it shouldn't silently fail.

[minus7]

Actually, it looks like oneshot mode already blocks for Mac; so adding more special cases there would be a valid option

[sydneymeyer]

I tried @minus7's suggestion about running with WLR_DRM_NO_ATOMIC=1 together with his wayland branch from redshift and it is indeed working fine here, i.e. redshift -m wayland -l 50:4 -v is gradually adjusting color temperature, Oneshot mode switches temperature and immediateley jumps back to where is was before.

@giucam's redshift fork appears to be working again with WLR_DRM_NO_ATOMIC=1 as before, that is, adjusting temperature in Oneshot mode only sporadically once every few invocations and adjusts temperature just fine with above mentioned redshift options and then exits always with segfault.

I dont know if this helps anybody, because frankly this compositor stuff is way above my head.

[edo-codes]

I have an Intel GPU, and when running wlroots and sway master (no forks), and using Lourens-Rich's redshift fork, redshift only works when starting sway with WLR_DRM_NO_ATOMIC=1.

[DawidLoubser]

I can concur that, on the machine I'm currently using (intel embedded graphics) redshift no longer works either. Running on 1.0.alpha.6.r21.g082488a8-1

[emersion]

Anyone could git bisect this?

[sydneymeyer]

I think it stopped working with this commit.
swaywm/wlroots@633663c

Corresponding Sway Version: sway version 1.0-alpha.5-186-g602ccca1

[martinetd]

I can confirm reverting that commit fixes things for me on intel graphics... So basically can't mix atomic and legacy with intel, while AMD needs legacy anyway.

I don't have any AMD hardware to check, is there any variable that stores amd or not we could use?
Maybe the glGetString(GL_VENDOR) in render/gles2/renderer.c (gives "Intel open source..." on intel), but it's not really in the right part of the code...

Actually, it looks like oneshot mode already blocks for Mac; so adding more special cases there would be a valid option

(on this off topic I have a trivial patch that blocks as I use oneshot and adapted my script to pkill old redshift process then start a new one, and the flicker sure is ugly... Really going to need a better remote control; reading temperature from stdin and using a pipe maybe...)

[ascent12]

We are capable of detecting the driver, but I am against adding any sort of driver specific code. I'd prefer a temporary environment variable or something to force legacy gamma if it ends up being an issue for people.

[martinetd]

Happy with that. Thought from people using AMD cards & redshift?

Will submit a patch tomorrow if that's all it takes

[emersion]

Thought from people using AMD cards & redshift?

Yeah, we would need a new temporary WLR_DRM_NO_ATOMIC_GAMMA env variable as a workaround for AMD users.

[minus7]

The non-atomic gamma setting on atomic mode does not work on AMDGPU either for me. I don't have a radeon-capable card in a PC right now, so no idea about that.

[ddevault]

It works on one of my cards atm, fwiw.

[minus7]

Just checked again, doesn't work unless I set WLR_DRM_NO_ATOMIC=1. It did work when it still was set using the atomic API in atomic mode, but required switching ttys or turning DPMS off/on for changes to take effect though.

[YaLTeR]

This redshift doesn't seem to work for me regardless of WLR_DRM_NO_ATOMIC_GAMMA. sway version 1.0-beta.2-147-g212baf2f (Jan 10 2019, branch 'master'), AMD RX 580, AMDGPU, Linux 4.18.

[emersion]

Does it work with WLR_DRM_NO_ATOMIC?

[YaLTeR]

Yep, seems to work with WLR_DRM_NO_ATOMIC=1 regardless of WLR_DRM_NO_ATOMIC_GAMMA.

[emersion]

Does it work if you use the AMDGPU driver with DC enabled? (Without any env variables)

[YaLTeR]

Seems to have the same behavior (only works with WLR_DRM_NO_ATOMIC=1 and doesn't work without, regardless of WLR_DRM_NO_ATOMIC_GAMMA).

[emersion]

Can you run https://github.com/ascent12/drm_info and paste the output here?

[YaLTeR]

https://gist.github.com/YaLTeR/807b51a74fddc49cc61a12f3f6e0fa67

I stripped out card0—it's the Intel integrated graphics which I don't use.

[emersion]

Hmm. GAMMA_LUT properties are in there. Maybe DRM_MODE_ATOMIC_TEST_ONLY doesn't apply them, but it works for plane positions, so I'm not sure. I don't have a card with GAMMA_LUT props, so I can't really try things out.

[mabequinho]

@emersion both redshift and wlroots gamma-control are supposed to make changes only after reload?

1.0-beta.2-264-g9e6c6ce3 (Jan 22 2019, branch 'HEAD'), wlroots-c41d013, Linux4.20.3, amdgpu(rx550), firmware-20181218.

[emersion]

both redshift and wlroots gamma-control are supposed to make changes only after reload?

No.

[YaLTeR]

Does it work if you use the AMDGPU driver with DC enabled? (Without any env variables)

Revisiting this, just noticed without any env variables redshift does work but the gamma changes are applied only on mode change (even if I change to the same mode).

[e00E]

Is there anything I can do to help get this fixed? I created the above referenced closed issue because I have this problem with an AMD RX Vega 64.

[ascent12]

I'm pretty sure a fix is required inside of the amdgpu kernel driver or otherwise show we're not using the gamma interface in the proper way.

[sydneymeyer]

I don't know wheter this issue can be closed or not, but i am running sway 1.0 now and even without WLR_DRM_NO_ATOMIC=1 "wayland-patched" redshift appears to be working fine, at least on two different systems (i.e. Intel HD Graphics 4000 and Intel UHD Graphics 620).

[emersion]

Intel doesn't expose the atomic property for gamma LUT. So it's just falling back to legacy.

[sydneymeyer]

Is there any possibility that since sway commit 4105982 (Remove orbital gamma-control protocol) and wlroots commit 3dec88e4555ee5fd95ffd69133623816cb0c25c4 (Remove orbital screenshooter and gamma-control) the wayland patched forks from redshift (e.g. aur package redshift-wayland-git) have stopped working?

[emersion]

amdgpu users have reported this issue is now fixed with the latest kernel.

the wayland patched forks from redshift (e.g. aur package redshift-wayland-git) have stopped working?

Yes. You need to use redshift-wlr-gamma-control-git.

[sydneymeyer]

Yes. You need to use redshift-wlr-gamma-control-git.

Thanks a bunch, emersion. i can now continue to track swaywm upstream..