Oh my. I'm tempted to blame Samsung and their firmware issues, but perhaps there's more to that.

You're on Arch, did you have it working under Plasma 6.1? That one already had much of the connection event logic, if it worked there then maybe we're only looking at a minor (but fatal) difference.

(In reply to Jakob Petsovits from comment #1)
> Oh my. I'm tempted to blame Samsung and their firmware issues, but perhaps
> there's more to that.
> 
> You're on Arch, did you have it working under Plasma 6.1? That one already
> had much of the connection event logic, if it worked there then maybe we're
> only looking at a minor (but fatal) difference.

It worked very well on 6.1 and 6.1.5, had absolutely no issues there. Started behaving after the 6.2 update.

I had the same issue, and what fixed it for me was setting the refresh rate to 60hz in the monitor, launching Plasma, then setting it back to 180hz.

Never mind, this issue appears to persist after a relogin

Same for me, I waited for the last update of KDE.
Plasma 6.1 is working well, but 6.2 keeps KDE crashing when I'm on a samsung odyssey G5.
If I plug in another screen, it work without issue, but not with my main screen.

For now, I get back my system to a backup without finding any fix.

Same system log as the author here. I can add my log generated by kde during the crash:


_______________________________________________________________________

Application: plasmashell (plasmashell), signal: Segmentation fault


warning: Can't open file anon_inode:i915.gem which was expanded to anon_inode:i915.gem during file-backed mapping note processing

warning: Can't open file /memfd:JSGCHeap:QtQml (deleted) during file-backed mapping note processing

warning: Can't open file /memfd:JITCode:QtQml (deleted) during file-backed mapping note processing

warning: Can't open file /memfd:unknown-usage:QtQml (deleted) during file-backed mapping note processing

warning: Can't open file /memfd:pulseaudio (deleted) during file-backed mapping note processing

warning: Can't open file /home/batoupar/.cache/plasma_theme_default.kcache (deleted) during file-backed mapping note processing

warning: Can't open file /memfd:JSVMStack:QtQml (deleted) during file-backed mapping note processing
[New LWP 2071]
[New LWP 2076]
[New LWP 2084]
[New LWP 2085]
[New LWP 2096]
[New LWP 2098]
[New LWP 2097]
[New LWP 2204]
[New LWP 2217]
[New LWP 2088]
[New LWP 2224]
[New LWP 2218]
[New LWP 2247]
[New LWP 2219]
[New LWP 2250]
[New LWP 2095]
[New LWP 3962]
[New LWP 2251]
[New LWP 2248]
[New LWP 2249]
[New LWP 3965]
[New LWP 3030]
[New LWP 2258]
[New LWP 3963]
[New LWP 3061]
[New LWP 2259]
[New LWP 2269]
[New LWP 3964]
[New LWP 3966]
[New LWP 2279]
[New LWP 2267]
[New LWP 2252]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by /usr/bin/plasmashell --no-respawn'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007d2a422a53f4 in ?? () from /usr/lib/libc.so.6
[Current thread is 1 (Thread 0x7d2a3c5d8a00 (LWP 2071))]
Cannot QML trace cores :(
/usr/share/drkonqi/gdb/python/gdb_preamble/preamble.py:516: DeprecationWarning: datetime.datetime.utcfromtimestamp() is deprecated and scheduled for removal in a future version. Use timezone-aware objects to represent datetimes in UTC: datetime.datetime.fromtimestamp(timestamp, datetime.UTC).
  boot_time = datetime.utcfromtimestamp(psutil.boot_time()).strftime('%Y-%m-%dT%H:%M:%S')
/usr/share/drkonqi/gdb/python/gdb_preamble/preamble.py:533: DeprecationWarning: datetime.datetime.utcnow() is deprecated and scheduled for removal in a future version. Use timezone-aware objects to represent datetimes in UTC: datetime.datetime.now(datetime.UTC).
  'timestamp': datetime.utcnow().isoformat(),
[Current thread is 1 (Thread 0x7d2a3c5d8a00 (LWP 2071))]
...

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

Bug 495316 is from another user of the exact same monitor, BTW. It seems like the monitor from hell!

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

(In reply to Devin Lin from comment #3)
> I had the same issue, and what fixed it for me was setting the refresh rate
> to 60hz in the monitor, launching Plasma, then setting it back to 180hz.

Are you able to confirm if just setting it to 60hz stops the issue from happening instead of setting it back to a higher frame rate when logging in again? I might have to just run at 60hz as a workaround until it's fixed hopefully soon.

With further observations I have found that waiting until the distro logo fades in, and then logging in, the issue doesn't happen for some reason. Unfortunately I'm not even able to decrease the frame rate in the monitor's settings to see if that changed anything.

(In reply to blumoopjapalt from comment #10)
> With further observations I have found that waiting until the distro logo
> fades in, and then logging in, the issue doesn't happen for some reason.
> Unfortunately I'm not even able to decrease the frame rate in the monitor's
> settings to see if that changed anything.

Have you trief disabling ddcutil as described in the original post? I have absolutely no issues whatsoever ever since, it runs fine on 165Hz

(In reply to kde from comment #11)
> (In reply to blumoopjapalt from comment #10)
> > With further observations I have found that waiting until the distro logo
> > fades in, and then logging in, the issue doesn't happen for some reason.
> > Unfortunately I'm not even able to decrease the frame rate in the monitor's
> > settings to see if that changed anything.
> 
> Have you trief disabling ddcutil as described in the original post? I have
> absolutely no issues whatsoever ever since, it runs fine on 165Hz

Where is the path (In reply to kde from comment #11)
> (In reply to blumoopjapalt from comment #10)
> > With further observations I have found that waiting until the distro logo
> > fades in, and then logging in, the issue doesn't happen for some reason.
> > Unfortunately I'm not even able to decrease the frame rate in the monitor's
> > settings to see if that changed anything.
> 
> Have you trief disabling ddcutil as described in the original post? I have
> absolutely no issues whatsoever ever since, it runs fine on 165Hz
Tried this by going into terminal with F2+Ctrl+Alt in SDDM, reboot, and sadly still have the issue. I've added the line Environment="POWERDEVIL_NO_DDCUTIL=1" near the top and no dice, on Aurora ublue image.

Nevermind, I took another look at KDE's power devil page and realized that you need to put [Service] above a override line. This time, it finally works!!! I was about to go bananas lol.

Same for me, in /etc/environment, I add POWERDEVIL_NO_DDCUTIL=1 and reboot with the last update, it's working.
For now it's a good workaround if you want to update your system!

How i can fix it in Fedora Atomic? I can't changing configuration files there

(In reply to worthymelight from comment #15)
> How i can fix it in Fedora Atomic? I can't changing configuration files there

I'm using ublue Aurora image, it worked for me by switching to tty in SDDM and do this command:
systemctl --user edit plasma-powerdevil.service

Then add the environment variable, and reboot.

I did some line-by-line digging into the source code, apparently Powerdevil for some reason sets the display brightness when Plasma starts, which causes the monitor to crash. The status returned though is DDCRC_OK. After the monitor comes back online, powerdevil sets the brightness again, which causes the monitor to crash again...

(In reply to Devin Lin from comment #17)
> I did some line-by-line digging into the source code, apparently Powerdevil
> for some reason sets the display brightness when Plasma starts, which causes
> the monitor to crash. The status returned though is DDCRC_OK. After the
> monitor comes back online, powerdevil sets the brightness again, which
> causes the monitor to crash again...

This is presumably KWin/Wayland integration, which sets brightness to its stored value for the monitor (currently defaulting to 1.0 if none is stored) when PowerDevil announces the monitor's brightness controls to KWin. It also sets the brightness value again on any output configuration change. If the monitor disappears but then re-appears again, PowerDevil will announce it again to KWin and the cycle continues.

Thanks for digging. This is another data point (perhaps the biggest one) that we need to be able to disable hardware brightness controls per monitor.

Could you also check if setting brightness manually with ddcutil (`ddcutil --display=<which> setvcp 10 50`) will also cause the monitor to crash?

(In reply to Jakob Petsovits from comment #18)
> (In reply to Devin Lin from comment #17)
> > I did some line-by-line digging into the source code, apparently Powerdevil
> > for some reason sets the display brightness when Plasma starts, which causes
> > the monitor to crash. The status returned though is DDCRC_OK. After the
> > monitor comes back online, powerdevil sets the brightness again, which
> > causes the monitor to crash again...
> 
> This is presumably KWin/Wayland integration, which sets brightness to its
> stored value for the monitor (currently defaulting to 1.0 if none is stored)
> when PowerDevil announces the monitor's brightness controls to KWin. It also
> sets the brightness value again on any output configuration change. If the
> monitor disappears but then re-appears again, PowerDevil will announce it
> again to KWin and the cycle continues.
> 
> Thanks for digging. This is another data point (perhaps the biggest one)
> that we need to be able to disable hardware brightness controls per monitor.
> 
> Could you also check if setting brightness manually with ddcutil (`ddcutil
> --display=<which> setvcp 10 50`) will also cause the monitor to crash?

Indeed, running `ddcutil --display=1 setvcp 10 50` causes the display to crash after a fresh reboot of the monitor. Interestingly enough, it prints `Display not found`

It is inconsistent though in that if you change some settings (ex. setting the refresh rate) and then run the command, it doesn't crash anymore, but instead fails with: `Verification failed for feature 10`

(In reply to Devin Lin from comment #19)
> Indeed, running `ddcutil --display=1 setvcp 10 50` causes the display to
> crash after a fresh reboot of the monitor. Interestingly enough, it prints
> `Display not found`
> 
> It is inconsistent though in that if you change some settings (ex. setting
> the refresh rate) and then run the command, it doesn't crash anymore, but
> instead fails with: `Verification failed for feature 10`

In that case, it may pay off to discuss this behavior on the ddcutil issue queue, at https://github.com/rockowitz/ddcutil/issues. I don't see an issue specifically for the Samsung G5, however there is some discussion about "Verification failed for feature 10" at https://github.com/rockowitz/ddcutil/issues/323, seen for various different monitors.

Let's not mark this RESOLVED UPSTREAM though until we know that ddcutil is actually in a position to deliver any kind of fix for this. If it isn't, the fix will have to be a checkbox to disable hardware brightness for this monitor despite the hardware claiming that it can do it.

(In reply to Jakob Petsovits from comment #20)
> (In reply to Devin Lin from comment #19)
> > Indeed, running `ddcutil --display=1 setvcp 10 50` causes the display to
> > crash after a fresh reboot of the monitor. Interestingly enough, it prints
> > `Display not found`
> > 
> > It is inconsistent though in that if you change some settings (ex. setting
> > the refresh rate) and then run the command, it doesn't crash anymore, but
> > instead fails with: `Verification failed for feature 10`
> 
> In that case, it may pay off to discuss this behavior on the ddcutil issue
> queue, at https://github.com/rockowitz/ddcutil/issues. I don't see an issue
> specifically for the Samsung G5, however there is some discussion about
> "Verification failed for feature 10" at
> https://github.com/rockowitz/ddcutil/issues/323, seen for various different
> monitors.
> 
> Let's not mark this RESOLVED UPSTREAM though until we know that ddcutil is
> actually in a position to deliver any kind of fix for this. If it isn't, the
> fix will have to be a checkbox to disable hardware brightness for this
> monitor despite the hardware claiming that it can do it.

I opened this issue: https://github.com/rockowitz/ddcutil/issues/466

I feel like there is room for better default behavior here, since it wasn't an issue before Plasma 6.2. Is it necessary to have to set the brightness when a monitor is detected? It'd be pretty hard for most users to figure out that the issue is caused by setting hardware brightness when it happens at boot; it's more obvious if it happened at the stage where users were manually setting the setting.

(In reply to Devin Lin from comment #21)
> I feel like there is room for better default behavior here, since it wasn't
> an issue before Plasma 6.2. Is it necessary to have to set the brightness
> when a monitor is detected?
Yes. Not all monitors remember the brightness level on their own.

> It'd be pretty hard for most users to figure out
> that the issue is caused by setting hardware brightness when it happens at
> boot; it's more obvious if it happened at the stage where users were
> manually setting the setting.
https://invent.kde.org/plasma/powerdevil/-/merge_requests/456 might work around this. As a more general way to fix this though, we probably just need to make a list of "known broken" displays and not use DDC/CI on them ever.

I'm the developer of ddcutil. 

I have added, in branch 2.1.5-dev,  option ***--disable-ddc**  to disable DDC communication for a single monitor model.   It takes as an argument a monitor model identifier, for example ***--disable-ddc SAM-U32H75x-4578***.  The identifier is the same used to construct the file name of the user defined features file, and is now also reported by **ddcutil detect --verbose**.

Probably the most useful way to specify this option in the ddcutil configuration file ddcutilrc.  If specified in the [global] section, it applies to both the **ddcutil** command and the the shared library.  If specified in the [libddcutil] section, it applies only to the shared library, which is what PowerDevil uses.

If useful, the libddcutil API could be extended to expose this ability.

A few comments on various comments: 

- Re status DDCRC_OK when setting a feature value.  Depending on configuration, **setvcp** or its API equivalent, may or may not attempt to read the feature value after setting it.  Unless verification is enabled, all DDCRC_OK means is that the monitor acknowledges receipt of a DDC request packet.  There is no guarantee that is has successfully acted on the request.  When verification is enabled, **setvcp**, or its API equivalent, essentially performs a **getvcp** operation to verify that the value has been set.

- Re a DDCRC_NULL_RESPONSE status.  The monitor has returned a DDC NULL Message in response to a request.  Though sometimes abused for other purposes by some monitors that don't conform to the DDC/CI spec, in this context it pretty clearly means that the monitor was unable to formulate a valid reply for some reason, e.g. monitor state. 

- Re "ddcutil --display=1 setvcp 10 50" reporting  "Display not found", this means that no monitors were detected during ddcutil initialization, so the there is no "--display=1" .  Note also that "--display 1" is superfluous.  If no display is detected, ddcutil defaults to operating on the first display detected.  

- I'm unclear as to what is meant by a display "crashing".  What exactly is the behaviour seen?  Similarly, what does "rebooting" mean?

- Re "setvcp 10 xx" failing, in some modes, e.g. Cinema, Gaming, HDR, some monitors will reject requests to change brightness and related features.  Perhaps the high frame rate is one of those situations.

Finally, regarding monitors repeatedly disconnecting and reconnecting, my Samsung U32H750 will sometimes go blank when other monitors are being turned on/off  and appear to be disconnected.  It few seconds later an image appears the monitor is detected as connected.  That's why you see the "Delaying 6 seconds to avoid a false disconnect/connect sequence..." messages in the logs.

> Finally, regarding monitors repeatedly disconnecting and reconnecting, my
> Samsung U32H750 will sometimes go blank when other monitors are being turned
> on/off  and appear to be disconnected.  It few seconds later an image
> appears the monitor is detected as connected.  That's why you see the
> "Delaying 6 seconds to avoid a false disconnect/connect sequence..."
> messages in the logs.

This is the behaviour or „reboot“. Just repeatedly every few seconds without turning on/off anything myself but doing this itself. 
1. blank
2. brand of the screen is visible
3. desktop is visible for 1-2 seconds
4. blank again
5. repeat

idk should if that helps. Could try recording it if it would help!?

(In reply to kde from comment #24)
> > Finally, regarding monitors repeatedly disconnecting and reconnecting, my
> > Samsung U32H750 will sometimes go blank when other monitors are being turned
> > on/off  and appear to be disconnected.  It few seconds later an image
> > appears the monitor is detected as connected.  That's why you see the
> > "Delaying 6 seconds to avoid a false disconnect/connect sequence..."
> > messages in the logs.
> 
> This is the behaviour or „reboot“. Just repeatedly every few seconds without
> turning on/off anything myself but doing this itself. 
> 1. blank
> 2. brand of the screen is visible
> 3. desktop is visible for 1-2 seconds
> 4. blank again
> 5. repeat
> 
> idk should if that helps. Could try recording it if it would help!?

Exatly the same for me with Samsung Odyssey G5 LS32DG502EUXEN on wayland.
 But I found a workaround, when on login screen, type the password, turn off screen, press enter, wait a few seconds and then turn on the screen and then it works as normal.

FWIW I have Samsung G5 LC34G55TWWPXEN and I have not encountered this. However, one similar-ish thing I've seen is that when Plasma locks itself automatically and I wait long enough, I will have to unplug/replug the power cord to the display to get it show anything.

+1 I have the same issue on my Samsung Odyssey G5. Disabling ddcutuil fixed it for me.

With KDE Plasma 6.3.1 on Bazzite, this issue will reappear after waking up from sleep, with the disabling ddcutil fix. It's unfortunate, I had to switch back with GNOME.

False alarm from my above comment, fix is still working for me when I did a fresh install of Bazzite KDE this time.

Can someone here please attach the edid of their screen? You can get it with
> cat /sys/class/drm/card1-DP-1/edid > edid.bin
(connector name may need adjusting)

(In reply to Zamundaaa from comment #30)
> Can someone here please attach the edid of their screen? You can get it with
> > cat /sys/class/drm/card1-DP-1/edid > edid.bin
> (connector name may need adjusting)

Hopefully I did this correctly, https://drive.google.com/file/d/1bJsSq6XhLnCTgnleTeQS92IA6OFhH_YH/view?usp=drive_link

This is one of the two bugs that prevents me from using KDE Plasma full-time, hopefully this information can lead to an eventual fix.

Can you make the info at that link public?

(In reply to Nate Graham from comment #32)
> Can you make the info at that link public?

I just fixed the file to be public from the Drive app hopefully.

Alternative link: https://www.mediafire.com/file/2yfvp1aervlnp8k/edid.bin/file

Unfortunately that's a 0 byte file. Can you try it again?

(In reply to Nate Graham from comment #34)
> Unfortunately that's a 0 byte file. Can you try it again?

Sorry I did that terminal command wrong this time, this time with the correct connector name.
https://drive.google.com/file/d/1-gDJvzZMMMPjJQnqKwtvTzfxmRzo5-J-/view?usp=drivesdk

Created attachment 182309 [details]
edid file

Thank you! decoded version using edid-decode:


00 ff ff ff ff ff ff 00 4c 2d 89 74 31 53 53 30
17 22 01 04 b5 46 28 78 3b e1 45 a5 55 51 9d 27
10 50 54 bf ef 80 71 4f 81 00 81 c0 81 80 95 00
a9 c0 b3 00 01 01 1e f9 00 5a a0 a0 14 50 0d 20
68 00 ba 89 21 00 00 1a 00 00 00 fd 00 41 a5 f2
f2 40 01 0a 20 20 20 20 20 20 00 00 00 fc 00 4f
64 79 73 73 65 79 20 47 35 0a 20 20 00 00 00 ff
00 48 4e 41 58 36 30 30 31 34 30 0a 20 20 01 b8

02 03 2a f1 44 90 3f 1f 04 23 09 07 07 83 01 00
00 e3 05 c0 00 6d 1a 00 00 02 01 41 a5 00 00 00
00 00 00 e6 06 05 01 53 53 00 56 5e 00 a0 a0 a0
29 50 30 20 35 00 ba 89 21 00 00 1a 6f c2 00 a0
a0 a0 55 50 30 20 35 00 ba 89 21 00 00 1a a7 8d
80 50 70 38 14 40 08 20 68 00 ba 89 21 00 00 1a
02 3a 80 18 71 38 2d 40 58 2c 45 00 ba 89 21 00
00 1e 00 00 00 00 00 00 00 00 00 00 00 00 00 30

----------------

Block 0, Base EDID:
  EDID Structure Version & Revision: 1.4
  Vendor & Product Identification:
    Manufacturer: SAM
    Model: 29833
    Serial Number: 810767153 (0x30535331)
    Made in: week 23 of 2024
  Basic Display Parameters & Features:
    Digital display
    Bits per primary color channel: 10
    DisplayPort interface
    Maximum image size: 70 cm x 40 cm
    Gamma: 2.20
    DPMS levels: Off
    Supported color formats: RGB 4:4:4, YCrCb 4:4:4, YCrCb 4:2:2
    First detailed timing includes the native pixel format and preferred refresh rate
    Display supports continuous frequencies
  Color Characteristics:
    Red  : 0.6474, 0.3339
    Green: 0.3164, 0.6142
    Blue : 0.1533, 0.0625
    White: 0.3134, 0.3291
  Established Timings I & II:
    IBM     :   720x400    70.081663 Hz   9:5     31.467 kHz     28.320000 MHz
    DMT 0x04:   640x480    59.940476 Hz   4:3     31.469 kHz     25.175000 MHz
    Apple   :   640x480    66.666667 Hz   4:3     35.000 kHz     30.240000 MHz
    DMT 0x05:   640x480    72.808802 Hz   4:3     37.861 kHz     31.500000 MHz
    DMT 0x06:   640x480    75.000000 Hz   4:3     37.500 kHz     31.500000 MHz
    DMT 0x08:   800x600    56.250000 Hz   4:3     35.156 kHz     36.000000 MHz
    DMT 0x09:   800x600    60.316541 Hz   4:3     37.879 kHz     40.000000 MHz
    DMT 0x0a:   800x600    72.187572 Hz   4:3     48.077 kHz     50.000000 MHz
    DMT 0x0b:   800x600    75.000000 Hz   4:3     46.875 kHz     49.500000 MHz
    Apple   :   832x624    74.551266 Hz   4:3     49.726 kHz     57.284000 MHz
    DMT 0x10:  1024x768    60.003840 Hz   4:3     48.363 kHz     65.000000 MHz
    DMT 0x11:  1024x768    70.069359 Hz   4:3     56.476 kHz     75.000000 MHz
    DMT 0x12:  1024x768    75.028582 Hz   4:3     60.023 kHz     78.750000 MHz
    DMT 0x24:  1280x1024   75.024675 Hz   5:4     79.976 kHz    135.000000 MHz
    Apple   :  1152x870    75.061550 Hz 192:145   68.681 kHz    100.000000 MHz
  Standard Timings:
    DMT 0x15:  1152x864    75.000000 Hz   4:3     67.500 kHz    108.000000 MHz
    DMT 0x1c:  1280x800    59.810326 Hz  16:10    49.702 kHz     83.500000 MHz
    DMT 0x55:  1280x720    60.000000 Hz  16:9     45.000 kHz     74.250000 MHz
    DMT 0x23:  1280x1024   60.019740 Hz   5:4     63.981 kHz    108.000000 MHz
    DMT 0x2f:  1440x900    59.887445 Hz  16:10    55.935 kHz    106.500000 MHz
    DMT 0x53:  1600x900    60.000000 Hz  16:9     60.000 kHz    108.000000 MHz (RB)
    DMT 0x3a:  1680x1050   59.954250 Hz  16:10    65.290 kHz    146.250000 MHz
  Detailed Timing Descriptors:
    DTD 1:  2560x1440  164.833290 Hz  16:9    240.657 kHz    637.740000 MHz (698 mm x 393 mm)
                 Hfront   13 Hsync  32 Hback   45 Hpol P
                 Vfront    6 Vsync   8 Vback    6 Vpol N
    Display Range Limits:
      Monitor ranges (Range Limits Only): 65-165 Hz V, 242-242 kHz H, max dotclock 640 MHz
    Display Product Name: 'Odyssey G5'
    Display Product Serial Number: 'HNAX600140'
  Extension blocks: 1
Checksum: 0xb8

----------------

Block 1, CTA-861 Extension Block:
  Revision: 3
  Underscans IT Video Formats by default
  Basic audio support
  Supports YCbCr 4:4:4
  Supports YCbCr 4:2:2
  Native detailed modes: 1
  Video Data Block:
    VIC  16:  1920x1080   60.000000 Hz  16:9     67.500 kHz    148.500000 MHz (native)
    VIC  63:  1920x1080  120.000000 Hz  16:9    135.000 kHz    297.000000 MHz
    VIC  31:  1920x1080   50.000000 Hz  16:9     56.250 kHz    148.500000 MHz
    VIC   4:  1280x720    60.000000 Hz  16:9     45.000 kHz     74.250000 MHz
  Audio Data Block:
    Linear PCM:
      Max channels: 2
      Supported sample rates (kHz): 48 44.1 32
      Supported sample sizes (bits): 24 20 16
  Speaker Allocation Data Block:
    FL/FR - Front Left/Right
  Colorimetry Data Block:
    BT2020YCC
    BT2020RGB
  Vendor-Specific Data Block (AMD), OUI 00-00-1A:
    Version: 2
    Feature Caps: 0x01
    Minimum Refresh Rate: 65 Hz
    Maximum Refresh Rate: 165 Hz
    Flags 1.x: 0x00
    Flags 2.x: 0x00
    Maximum luminance: 0 (50.000 cd/m^2)
    Minimum luminance: 0 (0.000 cd/m^2)
    Unknown: 0x00 0x00
  HDR Static Metadata Data Block:
    Electro optical transfer functions:
      Traditional gamma - SDR luminance range
      SMPTE ST2084
    Supported static metadata descriptors:
      Static metadata type 1
    Desired content max luminance: 83 (301.833 cd/m^2)
    Desired content max frame-average luminance: 83 (301.833 cd/m^2)
    Desired content min luminance: 0 (0.000 cd/m^2)
  Detailed Timing Descriptors:
    DTD 2:  2560x1440   59.950550 Hz  16:9     88.787 kHz    241.500000 MHz (698 mm x 393 mm)
                 Hfront   48 Hsync  32 Hback   80 Hpol P
                 Vfront    3 Vsync   5 Vback   33 Vpol N
    DTD 3:  2560x1440  119.997589 Hz  16:9    182.996 kHz    497.750000 MHz (698 mm x 393 mm)
                 Hfront   48 Hsync  32 Hback   80 Hpol P
                 Vfront    3 Vsync   5 Vback   77 Vpol N
    DTD 4:  1920x1080  164.831818 Hz  16:9    181.315 kHz    362.630000 MHz (698 mm x 393 mm)
                 Hfront    8 Hsync  32 Hback   40 Hpol P
                 Vfront    6 Vsync   8 Vback    6 Vpol N
    DTD 5:  1920x1080   60.000000 Hz  16:9     67.500 kHz    148.500000 MHz (698 mm x 393 mm)
                 Hfront   88 Hsync  44 Hback  148 Hpol P
                 Vfront    4 Vsync   5 Vback   36 Vpol P
Checksum: 0x30  Unused space in Extension Block: 13 bytes

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

Git commit 2fec79a01d7e4ca0ce6ff0541c5eeb913c9127c9 by Xaver Hugl.
Committed on 23/06/2025 at 17:24.
Pushed by zamundaaa into branch 'master'.

outputconfigurationstore: disallow DDC/CI for the Samsung Odyssey G5

The monitor's implementation is completely broken and makes it reboot every single
time that we attempt to change the brightness setting.

A  +-    --    autotests/integration/data/Odyssey G5.bin
M  +38   -22   autotests/integration/outputchanges_test.cpp
M  +13   -0    src/core/output.cpp
M  +1    -0    src/core/output.h
M  +1    -1    src/outputconfigurationstore.cpp
M  +2    -1    src/workspace.cpp

https://invent.kde.org/plasma/kwin/-/commit/2fec79a01d7e4ca0ce6ff0541c5eeb913c9127c9

Git commit ca4b2c7d05c7f81d0ce2bc68f5f97d6ec63c8b2c by Xaver Hugl.
Committed on 23/06/2025 at 19:08.
Pushed by zamundaaa into branch 'Plasma/6.4'.

outputconfigurationstore: disallow DDC/CI for the Samsung Odyssey G5

The monitor's implementation is completely broken and makes it reboot every single
time that we attempt to change the brightness setting.
(cherry picked from commit 2fec79a01d7e4ca0ce6ff0541c5eeb913c9127c9)

A  +-    --    autotests/integration/data/Odyssey G5.bin
M  +38   -22   autotests/integration/outputchanges_test.cpp
M  +13   -0    src/core/output.cpp
M  +1    -0    src/core/output.h
M  +1    -1    src/outputconfigurationstore.cpp
M  +2    -1    src/workspace.cpp

https://invent.kde.org/plasma/kwin/-/commit/ca4b2c7d05c7f81d0ce2bc68f5f97d6ec63c8b2c