Bug 442520

Can confirm.

Hmm, I could only test it by changing code in KWin where it printed out the correct value, because I don't have Intel hardware.
Maybe we're setting it wrong somehow... What does ~/.local/share/sddm/wayland-session.log say? If you have debug logging enabled it should have a message like
"Setting rgb range: Full"
And possibly a "Atomic test for CommitMode::Test failed!" with a bunch of numbers below it. If that is there, the exact lines would be interesting.

after my steps, these lines are added to log file:

kwin_wayland_drm: Atomic test for (0) failed! Invalid argument
kwin_wayland_drm: Flags:
kwin_wayland_drm: 	 DRM_MODE_PAGE_FLIP_EVENT
kwin_wayland_drm: Drm objects:
kwin_wayland_drm: connector 79
kwin_wayland_drm: 	"CRTC_ID": 45
kwin_wayland_drm: 	"non-desktop": 0
kwin_wayland_drm: 	"DPMS": 0
kwin_wayland_drm: 	"Broadcast RGB": 0->1
kwin_wayland_drm: crtc 45
kwin_wayland_drm: 	"MODE_ID": 103
kwin_wayland_drm: 	"ACTIVE": 1
kwin_wayland_drm: 	"VRR_ENABLED": 0
kwin_wayland_drm: 	"GAMMA_LUT": 110
kwin_wayland_drm: primary plane 31
kwin_wayland_drm: 	"type": 1
kwin_wayland_drm: 	"SRC_X": 0
kwin_wayland_drm: 	"SRC_Y": 0
kwin_wayland_drm: 	"SRC_W": 125829120
kwin_wayland_drm: 	"SRC_H": 70778880
kwin_wayland_drm: 	"CRTC_X": 0
kwin_wayland_drm: 	"CRTC_Y": 0
kwin_wayland_drm: 	"CRTC_W": 1920
kwin_wayland_drm: 	"CRTC_H": 1080
kwin_wayland_drm: 	"FB_ID": 105
kwin_wayland_drm: 	"CRTC_ID": 45
kwin_wayland_drm: 	"rotation": 1
kwin_wayland_drm: 	"IN_FORMATS": 32

Okay, thanks. I have an idea about what could be causing this

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/1426

Can you test the patch?

(In reply to Zamundaaa from comment #6)
> Can you test the patch?

I have applied your patch to my system.
Now I can apply full rgb range but it is reverted
to limited when I restart Plasma session.
And when I apply full rgb range and then immediately reopen the KCM,
rgb range combobox is empty or Automatic option is selected.
These issues persist after reboot.

Git commit 4848964c6036803b5fa0d88340960b44a113da67 by Xaver Hugl.
Committed on 17/09/2021 at 13:48.
Pushed by zamundaaa into branch 'master'.

platforms/drm: allow modesets when setting Broadcast RGB

M  +5    -1    src/plugins/platforms/drm/drm_object_connector.cpp

https://invent.kde.org/plasma/kwin/commit/4848964c6036803b5fa0d88340960b44a113da67

Git commit 6455499dca1b589d87184ef128bd9b226899f8ce by Xaver Hugl.
Committed on 17/09/2021 at 13:56.
Pushed by zamundaaa into branch 'Plasma/5.23'.

platforms/drm: allow modesets when setting Broadcast RGB


(cherry picked from commit 4848964c6036803b5fa0d88340960b44a113da67)

M  +5    -1    src/plugins/platforms/drm/drm_object_connector.cpp

https://invent.kde.org/plasma/kwin/commit/6455499dca1b589d87184ef128bd9b226899f8ce

Anything more to do here, or should this be fixed now? Can you test, Patrick? Thanks!

The bug as per the first description should be fixed but the setting is not restored by kded, even though it is saved into the config file(s). I must've overlooked something in KScreen. Too much boilerplate code :/

A possibly relevant merge request was started @ https://invent.kde.org/plasma/libkscreen/-/merge_requests/34

Git commit 67e629aa18ba878d4f3566457b6fbfff7ec949fd by Xaver Hugl.
Committed on 21/09/2021 at 11:34.
Pushed by vladz into branch 'master'.

outputdevice: add missing done events

M  +8    -0    src/server/outputdevice_v2_interface.cpp

https://invent.kde.org/plasma/kwayland-server/commit/67e629aa18ba878d4f3566457b6fbfff7ec949fd

Git commit 4008dccebc51f79a283852399a778c4d546c8dd8 by Xaver Hugl.
Committed on 21/09/2021 at 12:12.
Pushed by zamundaaa into branch 'Plasma/5.23'.

outputdevice: add missing done events


(cherry picked from commit 67e629aa18ba878d4f3566457b6fbfff7ec949fd)

M  +8    -0    src/server/outputdevice_v2_interface.cpp

https://invent.kde.org/plasma/kwayland-server/commit/4008dccebc51f79a283852399a778c4d546c8dd8

Git commit b6f7e1627104bb6dc811374e92d1088530c3d1ae by Xaver Hugl.
Committed on 21/09/2021 at 11:31.
Pushed by zamundaaa into branch 'master'.

fix all the new settings

While they were written to the control file, they were not written into
the configuration files from kded and were thus reset after a session restart

M  +20   -5    src/output.cpp
M  +3    -3    src/output.h

https://invent.kde.org/plasma/libkscreen/commit/b6f7e1627104bb6dc811374e92d1088530c3d1ae

Git commit f659d88aaae2690207a39e7c60c7f2ecf3aedecb by Xaver Hugl.
Committed on 21/09/2021 at 12:13.
Pushed by zamundaaa into branch 'Plasma/5.23'.

fix all the new settings

While they were written to the control file, they were not written into
the configuration files from kded and were thus reset after a session restart


(cherry picked from commit b6f7e1627104bb6dc811374e92d1088530c3d1ae)

M  +20   -5    src/output.cpp
M  +3    -3    src/output.h

https://invent.kde.org/plasma/libkscreen/commit/f659d88aaae2690207a39e7c60c7f2ecf3aedecb

I have built 5.23 branch of libkscreen, kwayland-server, kwin, kscreen
and plasma-workspace. But rgb range is still reverted to limited 
("Automatic" is selected in KCM) after re-login.

Ack, it doesn't work with global retention. Can you try https://invent.kde.org/plasma/kscreen/-/merge_requests/44?

(In reply to Zamundaaa from comment #18)
> Ack, it doesn't work with global retention. Can you try
> https://invent.kde.org/plasma/kscreen/-/merge_requests/44?

Applied your patch. Full rgb range is preserved after reboot, but it is not
after re-login.

Git commit 38c258a1d7b007281ffae4f67621491378d0f4aa by Xaver Hugl.
Committed on 22/09/2021 at 17:21.
Pushed by zamundaaa into branch 'master'.

fix all the new settings

There were still bits missing for the global config

M  +18   -1    kded/output.cpp
M  +3    -0    kded/output.h

https://invent.kde.org/plasma/kscreen/commit/38c258a1d7b007281ffae4f67621491378d0f4aa

Git commit c2180098a5646a8d2e48c5eb6aec99fcf9e88ec4 by Xaver Hugl.
Committed on 22/09/2021 at 17:22.
Pushed by zamundaaa into branch 'Plasma/5.23'.

fix all the new settings

There were still bits missing for the global config


(cherry picked from commit 38c258a1d7b007281ffae4f67621491378d0f4aa)

M  +18   -1    kded/output.cpp
M  +3    -0    kded/output.h

https://invent.kde.org/plasma/kscreen/commit/c2180098a5646a8d2e48c5eb6aec99fcf9e88ec4

I can't reproduce the logout+login problem

I have this issue. I have tried patching with mr 44. still it doesn't work.

You need up to date builts of the Plasma/5.23 branch (or git master) for libkscreen, kscreen, kwayland-server and kwin, the single patch won't work.

RGB range is reverted to "Automatic" affer re-login on Plasma 5.23 too.
"Automatic" means "Limited" on my system.

Operating System: Arch Linux
KDE Plasma Version: 5.23.0
KDE Frameworks Version: 5.87.0
Qt Version: 5.15.2
Graphics Platform: Wayland

Can confirm, on Opensuse TW w/ 5.23 I'm having the exact same issue as pointed out by Patrick Silva. I was going to file a bug for the case and discovered this one instead.

To better define my environment:
I have two monitors, my FHD laptop on the left and my secondary FHD screen on the right, which is also the "main" one (although no such definition exists on wayland yet). My secondary monitor, when RGB Range is on "automatic" is actually set on "limited" (although it should refer to "full" as it is perfectly capable to do such setting).

I noticed that whenever I force "Full" (no matter for which screen and no matter the "Save display's properties" setting below), if I disconnect my secondary screen on the right and reconnect it, all the setting (even those related to the laptop screen) revert to "automatic". Hence, my secondary screen reverts to a limited RGB range, which is quite annoying now that I discovered my monitor does not have washed out colors ahaha.

Laptop screen: Dell XPS 13 9343
Secondary screen: Dell U2419HC

Let me know if I can attach further information/logs etc!

Operating System: openSUSE Tumbleweed 20211016
KDE Plasma Version: 5.23.0
KDE Frameworks Version: 5.86.0
Qt Version: 5.15.2
Kernel Version: 5.14.11-1-default (64-bit)
Graphics Platform: Wayland
Processors: 4 × Intel® Core™ i5-5200U CPU @ 2.20GHz
Memory: 7,7 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 5500

Can you check for "Atomic test for (0) failed!" in ~/.local/sddm/wayland-session.log?
I don't have a device that supports it and faking support in KWin still seems to make it work fine, maybe there's something with driver interaction that makes it fail.

> Can you check for "Atomic test for (0) failed!" in ~/.local/sddm/wayland-session.log?

I just read your second comment and I believe I don't have debug logging enabled, can you tell me how can I enable it? Sorry noob here. 
I tried adding "export QT_LOGGING_RULES="kwin_*.debug=true" to my .bashrc, logout, and then launch "systemsettings5 kcm_kscreen" but I can't see any additional info added to the logfile

Either set it like this for your user account: https://invent.kde.org/plasma/kwin/-/wikis/Environment-Variables#usage or put it in /etc/environment to set it globally
When you have that, set rgb range to something else than automatic, log out, log in and have a look at the session log

Created attachment 142670 [details]
Before Logout, initial state of the log

Before Logout, the screen is already in Automatic RGB mode, initial state of the log

Created attachment 142671 [details]
Before Logout, Atuomatic -> Full

The logs records the instant where I change RGB mode from Automatic to Full, before logging out

Created attachment 142672 [details]
After Logout

The logs shows the state after logout/login -> the screen is back to Automatic RGB mode

Created attachment 142673 [details]
After logout, Automatic to Full

After logout, I switch again from Automatic to Full, the logs records this action

I added "export QT_LOGGING_RULES="kwin_*.debug=true" as suggested, removed the log and rebooted to reach a clean state.

I recorded 4 different logs for the 4 subsequent actions done:
* 00a: shows the initial state of the log, the screen is on Automatic and no preference has been set yet
* 00b: the log records the instant when I switch from Automatic to Full, before logout
*** LOGOUT ***
* 01a: shows the state after logout, the screen is back in Automatic mode
* 01b: I switch again from Automatic to Full, the log records this action

Points of Interest I noticed using diff:
--> Comparison among 00b and 01a (logout happens in between):
* Line 7: The properties of Crtc 60 change (why?)
* Line 70: The properties of connector 77 change (why?)
* Line 71: Connector 85 (crtc 60) goes from Automatic to Full
* Line 74 and 75: The two hex addresses changes (IDs?)
* Line 421 in 01a sets the RGB range to Automatic

--> Comparison among 01a and 01b:
* Line 522: the RGB range is set to Full

-------

I didn't find any "kwin_wayland_drm: Atomic test for (0) failed! Invalid argument" string in these logs, however we can find on line 4:

"kwin_wayland_drm: Using Atomic Mode Setting on gpu "/dev/dri/card0"

So I guess the error does not produce in my case (?)

Thanks for the investigation, the bug is almost certainly in KScreen then.

*** Bug 446617 has been marked as a duplicate of this bug. ***

Could you share the folder ~/.local/share/kscreen content

Created attachment 144933 [details]
my ~/.local/share/kscreen folder

Created attachment 144937 [details]
Mrcuve0 - kscreen folder

(In reply to Mrcuve0 from comment #39)
> Created attachment 144937 [details]
> Mrcuve0 - kscreen folder

Thanks for those folders.

Your two configs have `"rgbrange": 0,` (automatic) in common, it should be `"rgbrange": 1,` for Full.

 It seems to indicate kscreen kded did not save the rgb range correctly, or KWin did not transmit it.

So a great thing that can help is to be in a automatic state, run
`WAYLAND_DEBUG=1 kcmshell5 kscreen`, keep the output, (this is quite verbose).
Then switch to full.
We should see in the trace a `output_devicev2.send_rgb_range(1)` or similar after the activation, if not the bug is in KWin side.

I'm adding two different logs: 

* The first one `kscreen_terminal.log` is the one you asked (I'd like to understand why redirecting with tee or > didn't work with this particular command, anyway I copy pasted the stdout to this file :D).
* The second one `kscreen.log` is the one produced by setting the .sh file in plasma-workspace/env like https://community.kde.org/Solid/Projects/ScreenManagement suggests.

Hope both help. Anyway, I quickly searched for the string you mentioned and couldn't see it.

It is also woth mentioning that both screens (e-DP1, my laptop's builtin, and DP-1 Dell U2419HC, my external one) were set to "automatic" before launching the command. However, DP-1 was clearly showing a "full-RGB" image. I tried to restart and disconnect DP-1 multiple times while having "automatic" in kscreen to force it to a visually "limited" scale but I couldn't. Also closing the laptop lid didn't change anything. 

It's interesting because some months ago (at least as soon as i got 5.23 on tumbleweed) these operations would have triggered the bug instantly (i.e. DP-1 would clearly show a "limited" image), now I cannot find a way to reproduce it sistematically (but I can guarantee you that I still have to manually launch kscreen just to set to "full" DP-1 from time to time)

Created attachment 144959 [details]
Mrcuve0 - kscreen_terminal.log

Created attachment 144960 [details]
Mrcuve0 - kscreen.log (.local/share/kscreen/)

Just to add additional information to my setup, some days ago I wanted to try OC my screens to 75Hz "for the lulz" following https://old.reddit.com/r/linux_gaming/comments/e339il/how_to_overclock_your_monitor_on_wayland/.
Hence why you'll find 75Hz in the configs and logs.

It probably does not have effects on the bug but, you know, sometimes "very unlikely" configs have an impact on what you are trying to debug and you find it only after hours of wasted time

(In reply to Mrcuve0 from comment #42)
> Created attachment 144959 [details]
> Mrcuve0 - kscreen_terminal.log

Great, this confirms the issue is on Kscreen side:

[4081578,804]  -> kde_output_management_v2@49.create_configuration(new id kde_output_configuration_v2@55)
[4081578,967]  -> kde_output_configuration_v2@55.mode(kde_output_device_v2@50, kde_output_device_mode_v2@4278190082)
[4081579,040]  -> kde_output_configuration_v2@55.mode(kde_output_device_v2@51, kde_output_device_mode_v2@4278190115)
[4081579,063]  -> kde_output_configuration_v2@55.set_rgb_range(kde_output_device_v2@51, 1)
[4081579,098]  -> kde_output_configuration_v2@55.apply()
[...]
[4081635,736] kde_output_device_v2@51.rgb_range(1)
[4081635,782] kde_output_device_v2@51.done()
[4081635,815] kde_output_configuration_v2@55.applied()

In someone with the needed hardware could test the tentative kwin patch https://invent.kde.org/plasma/kwin/-/merge_requests/1830
This should make kwin restore your rgb range setting on startup.

Git commit d81b106c1554a36c14c55d81083268a79b057a91 by Méven Car, on behalf of Méven Car.
Committed on 03/01/2022 at 15:40.
Pushed by meven into branch 'master'.

Apply the rgbrange read from Kscreen configuration on startup

M  +1    -0    src/abstract_wayland_output.cpp
M  +4    -0    src/backends/drm/drm_backend.cpp

https://invent.kde.org/plasma/kwin/commit/d81b106c1554a36c14c55d81083268a79b057a91

Hi guys,

the behavior didn't change.  
After logout/login cycle, "rgbrange" stays "1" for the files in "kscreen/control/outputs" and "kscreen/control/configs" but not for the files in "kscreen" and in "kscreen/outputs".
They are reverted to "0". 
Furthermore, the apply/discard prompt doesn't show up after hitting apply, so the settings are reverted after the timeout. When starting kscreen via kcmshell5, it works like it should.

Tested with the latest release:

Betriebssystem: Debian GNU/Linux
KDE-Plasma-Version: 5.24.0
KDE-Frameworks-Version: 5.90.0
Qt-Version: 5.15.2
Kernel-Version: 5.16.0-7.slh.1-aptosid-amd64 (64-bit)
Grafik-Plattform: Wayland
Prozessoren: 12 × Intel® Core™ i7-8700K CPU @ 3.70GHz
Speicher: 31,2 GiB Arbeitsspeicher
Grafikprozessor: Mesa DRI Intel® UHD Graphics 630

Best regards

Marc

*** Bug 450029 has been marked as a duplicate of this bug. ***

*** Bug 450172 has been marked as a duplicate of this bug. ***

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwayland-server/-/merge_requests/360

I managed to reproduce the bug, this MR should finally fix it for good. If someone else could verify that would be good though

Git commit b90a3cbb4c3615fa6bf6dc8ffb5747da7d5deb60 by Xaver Hugl.
Committed on 11/03/2022 at 02:51.
Pushed by ngraham into branch 'master'.

outputchangeset: set default values for vrr policy and rgb range

If this is not done then KScreen will sometimes unintentionally reset them
to the default.
FIXED-IN: 5.24.4

M  +2    -0    src/server/outputchangeset_v2.cpp

https://invent.kde.org/plasma/kwayland-server/commit/b90a3cbb4c3615fa6bf6dc8ffb5747da7d5deb60

Git commit a8e66dd1360624f9fef016598435182d7faa635a by Nate Graham, on behalf of Xaver Hugl.
Committed on 11/03/2022 at 16:14.
Pushed by ngraham into branch 'Plasma/5.24'.

outputchangeset: set default values for vrr policy and rgb range

If this is not done then KScreen will sometimes unintentionally reset them
to the default.
FIXED-IN: 5.24.4


(cherry picked from commit b90a3cbb4c3615fa6bf6dc8ffb5747da7d5deb60)

M  +2    -0    src/server/outputchangeset_v2.cpp

https://invent.kde.org/plasma/kwayland-server/commit/a8e66dd1360624f9fef016598435182d7faa635a

Hi guys,

the bug fix looks good.
Running version 5.24.4 and didn't encountered this issue anymore. 
Also the RGB setting in kscreen settings menu gets remembered correctly.

Thanks and best regards,

Marc