| Summary: | Powerdevil causes Samsung Odyssey G5 to go on/off repeatedly forever with DDC support enabled | ||
|---|---|---|---|
| Product: | [Plasma] Powerdevil | Reporter: | kde |
| Component: | general | Assignee: | Plasma Bugs List <plasma-bugs> |
| Status: | CONFIRMED --- | ||
| Severity: | major | CC: | batoupar, blumoopjapalt, davidpetko07, espidev, jpetso, kdedev, natalie_clarius, nate, rockowitz2, xaver.hugl |
| Priority: | HI | Keywords: | regression |
| Version: | 6.2.0 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| See Also: |
https://bugs.kde.org/show_bug.cgi?id=495744 https://bugs.kde.org/show_bug.cgi?id=496295 |
||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
kde
2024-10-11 11:05:33 UTC
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. |