Bug 107459 - Atomically set gamma ramps are not applied until TTY switch
Summary: Atomically set gamma ramps are not applied until TTY switch
Status: RESOLVED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/AMDgpu (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-08-02 18:54 UTC by Drew DeVault
Modified: 2019-08-16 12:34 UTC (History)
6 users (show)

See Also:
i915 platform:
i915 features:


Attachments
dmesg.log (71.29 KB, text/plain)
2018-08-06 12:32 UTC, Drew DeVault
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Drew DeVault 2018-08-02 18:54:13 UTC
When atomically setting gamma ramps on AMDGPU (specifically ), the changes don't take effect until switching to another TTY and back again. Using the legacy DRM interface works as expected.

To reproduce, build and run the rootston Wayland compositor:

https://github.com/swaywm/wlroots

We will shortly be merging this patch for a new gamma control protocol extension, which you will need to apply if we haven't merged it by the time you attempt it:

https://github.com/swaywm/wlroots/pull/1157

An sample program will be available in the build directory, ./examples/gamma-control, which can adjust gamma. By default this will use the atomic interface, set WLR_DRM_NO_ATOMIC=1 before starting rootston to use the legacy interface. Our atomic gamma code is here:

https://github.com/swaywm/wlroots/blob/master/backend/drm/atomic.c#L199-L230
Comment 1 Drew DeVault 2018-08-02 18:55:26 UTC
>When atomically setting gamma ramps on AMDGPU (specifically ), the changes don't take effect until switching to another TTY and back again. Using the legacy DRM interface works as expected.

Specifically the RX 550, that is.
Comment 2 Michel Dänzer 2018-08-03 07:36:40 UTC
Please attach the corresponding dmesg output.
Comment 3 Drew DeVault 2018-08-05 13:58:15 UTC
Sorry for the delay. I did the following:

dmesg -n debug
# Reproduce problem
dmesg -n info
# Examine dmesg

There was nothing new written to the log.
Comment 4 Michel Dänzer 2018-08-06 09:02:37 UTC
I mean just the output of dmesg without any arguments, to see various information about the initialization of the driver and the kernel in general.
Comment 5 Drew DeVault 2018-08-06 12:32:05 UTC
Created attachment 140977 [details]
dmesg.log

Gotcha. Log attached.

Also, I spoke with a friend using the same GPU, they are able to reproduce the issue.
Comment 6 emersion 2019-06-11 05:53:58 UTC
sway users have reported this bug has been fixed in the latest kernel.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.