[Powerdevil] [Bug 490557] Laptop leaves sleeping-mode while lid closed
https://bugs.kde.org/show_bug.cgi?id=490557 Jakob Petsovits changed: What|Removed |Added CC||jpe...@petsovits.com --- Comment #1 from Jakob Petsovits --- This is generally pretty difficult because we don't get to hear about the cause of the system being woken up. Not sure if the kernel even knows about it. There have been past efforts to make the system suspend again when the lid is still closed (https://invent.kde.org/plasma/powerdevil/-/merge_requests/279) and there is some potential for Plasma to make improvements this way, but it's not easy to get right without introducing regressions. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 490356] PowerDevil crash in Core::onResumingFromIdle()
https://bugs.kde.org/show_bug.cgi?id=490356 Jakob Petsovits changed: What|Removed |Added CC||gufi...@gmail.com --- Comment #8 from Jakob Petsovits --- *** Bug 490508 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 490508] Power management daemon crash on screen locking
https://bugs.kde.org/show_bug.cgi?id=490508 Jakob Petsovits changed: What|Removed |Added CC||jpe...@petsovits.com Resolution|--- |DUPLICATE Status|REPORTED|RESOLVED --- Comment #2 from Jakob Petsovits --- *** This bug has been marked as a duplicate of bug 490356 *** -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 490631] Custom Power Management event Durations UI configuration missing
https://bugs.kde.org/show_bug.cgi?id=490631 Jakob Petsovits changed: What|Removed |Added CC||jpe...@petsovits.com --- Comment #1 from Jakob Petsovits --- The intention is to pop up the duration selection dialog every time the "Custom..." element is selected. When you confirm a new custom duration, it is inserted as an extra element in the list of dropdown options, in addition to the preset values and the "Custom..." option. The new custom duration (e.g. "After 7 minutes") is then selected, so you can switch to the "Custom..." element again to enter a different custom duration. Are you saying that after you've previously configured a custom duration, selecting the "Custom..." option again doesn't pop up the custom duration dialog again? Or is this working, but you consider it unintuitive? -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 486506] Firefox (Flatpak) does not inhibit power management when playing videos
https://bugs.kde.org/show_bug.cgi?id=486506 Jakob Petsovits changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|UPSTREAM|--- --- Comment #16 from Jakob Petsovits --- https://bugs.kde.org/show_bug.cgi?id=472541#c8 had an interesting observation, in that KDE implements Wayland inhibition locks correctly but some apps or inhibit helpers don't associate them to focused Wayland surfaces and thus the lock is not respected by the compositor. https://codeberg.org/river/river/issues/1079#issuecomment-2013817 has another comment about this. https://bugzilla.mozilla.org/show_bug.cgi?id=1877022 was a Firefox issue for that problem. This leads to the actual source code in https://hg.mozilla.org/mozilla-central/file/tip/widget/gtk/WakeLockListener.cpp which shows that Firefox does implement support for the xdg portal D-Bus API, however only as a fallback after the old-school `org.freedesktop.Inhibit` D-Bus API has been tried. The aforementioned Wayland API is yet different and only a last-resort fallback, so probably not further relevant for the purpose of this bug. In theory, Firefox should be trying the various D-Bus interfaces in order, and switch to the next candidate if the previous ones don't work. We should trace D-Bus calls via dbus-monitor before punting responsibility onto Firefox, especially if a "blocking sleep and screen locking" message appears in the Battery applet. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 490421] PowerDevil crash in Core::onKIdleTimeoutReached()
https://bugs.kde.org/show_bug.cgi?id=490421 Jakob Petsovits changed: What|Removed |Added Version Fixed In|6.1.3 |6.1.4 --- Comment #4 from Jakob Petsovits --- Sorry about the version tag, the fix didn't make it into Plasma 6.1.3 but instead will be in 6.1.4 initially. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 490356] PowerDevil crash in Core::onResumingFromIdle()
https://bugs.kde.org/show_bug.cgi?id=490356 Jakob Petsovits changed: What|Removed |Added Version Fixed In|6.1.3 |6.1.4 --- Comment #7 from Jakob Petsovits --- Sorry about the version tag, the fix didn't make it into Plasma 6.1.3 but instead will be in 6.1.4 initially. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 490356] PowerDevil crash in Core::onResumingFromIdle()
https://bugs.kde.org/show_bug.cgi?id=490356 Jakob Petsovits changed: What|Removed |Added Latest Commit|https://invent.kde.org/plas |https://invent.kde.org/plas |ma/powerdevil/-/commit/7a92 |ma/powerdevil/-/commit/8c16 |9fa01ed036f60c5a15c72416b4e |86c9e97edb9a06e06e2f41cfe53 |40eb03160 |51cef7986 --- Comment #6 from Jakob Petsovits --- Git commit 8c1686c9e97edb9a06e06e2f41cfe5351cef7986 by Jakob Petsovits. Committed on 18/07/2024 at 17:14. Pushed by jpetso into branch 'Plasma/6.1'. daemon: Don't leave dangling Action pointers in idle-time containers If we delete the Action but don't clean up related map/set elements, the powerdevil daemon can crash e.g. in Core::onResumingFromIdle() and Core::onKIdleTimeoutReached(). This has been an issue since commit 584cfdf0 (or d91bc62f on 6.1) which made it possible for already-created actions to get deleted again at a later time. Related: bug 490421 (cherry picked from commit 7a929fa01ed036f60c5a15c72416b4e40eb03160) Co-authored-by: Jakob Petsovits M +10 -4daemon/powerdevilcore.cpp https://invent.kde.org/plasma/powerdevil/-/commit/8c1686c9e97edb9a06e06e2f41cfe5351cef7986 -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 490421] PowerDevil crash in Core::onKIdleTimeoutReached()
https://bugs.kde.org/show_bug.cgi?id=490421 Jakob Petsovits changed: What|Removed |Added Latest Commit|https://invent.kde.org/plas |https://invent.kde.org/plas |ma/powerdevil/-/commit/7a92 |ma/powerdevil/-/commit/8c16 |9fa01ed036f60c5a15c72416b4e |86c9e97edb9a06e06e2f41cfe53 |40eb03160 |51cef7986 --- Comment #3 from Jakob Petsovits --- Git commit 8c1686c9e97edb9a06e06e2f41cfe5351cef7986 by Jakob Petsovits. Committed on 18/07/2024 at 17:14. Pushed by jpetso into branch 'Plasma/6.1'. daemon: Don't leave dangling Action pointers in idle-time containers If we delete the Action but don't clean up related map/set elements, the powerdevil daemon can crash e.g. in Core::onResumingFromIdle() and Core::onKIdleTimeoutReached(). This has been an issue since commit 584cfdf0 (or d91bc62f on 6.1) which made it possible for already-created actions to get deleted again at a later time. Related: bug 490356 (cherry picked from commit 7a929fa01ed036f60c5a15c72416b4e40eb03160) Co-authored-by: Jakob Petsovits M +10 -4daemon/powerdevilcore.cpp https://invent.kde.org/plasma/powerdevil/-/commit/8c1686c9e97edb9a06e06e2f41cfe5351cef7986 -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 490356] PowerDevil crash in Core::onResumingFromIdle()
https://bugs.kde.org/show_bug.cgi?id=490356 Jakob Petsovits changed: What|Removed |Added Version Fixed In||6.1.3 -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 490421] PowerDevil crash in Core::onKIdleTimeoutReached()
https://bugs.kde.org/show_bug.cgi?id=490421 Jakob Petsovits changed: What|Removed |Added Version Fixed In||6.1.3 -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 490356] PowerDevil crash in Core::onResumingFromIdle()
https://bugs.kde.org/show_bug.cgi?id=490356 Jakob Petsovits changed: What|Removed |Added Latest Commit||https://invent.kde.org/plas ||ma/powerdevil/-/commit/7a92 ||9fa01ed036f60c5a15c72416b4e ||40eb03160 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakob Petsovits --- Git commit 7a929fa01ed036f60c5a15c72416b4e40eb03160 by Jakob Petsovits. Committed on 18/07/2024 at 12:25. Pushed by jpetso into branch 'master'. daemon: Don't leave dangling Action pointers in idle-time containers If we delete the Action but don't clean up related map/set elements, the powerdevil daemon can crash e.g. in Core::onResumingFromIdle() and Core::onKIdleTimeoutReached(). This has been an issue since commit 584cfdf0 (or d91bc62f on 6.1) which made it possible for already-created actions to get deleted again at a later time. Related: bug 490421 M +10 -4daemon/powerdevilcore.cpp https://invent.kde.org/plasma/powerdevil/-/commit/7a929fa01ed036f60c5a15c72416b4e40eb03160 -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 490421] PowerDevil crash in Core::onKIdleTimeoutReached()
https://bugs.kde.org/show_bug.cgi?id=490421 Jakob Petsovits changed: What|Removed |Added Latest Commit||https://invent.kde.org/plas ||ma/powerdevil/-/commit/7a92 ||9fa01ed036f60c5a15c72416b4e ||40eb03160 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from Jakob Petsovits --- Git commit 7a929fa01ed036f60c5a15c72416b4e40eb03160 by Jakob Petsovits. Committed on 18/07/2024 at 12:25. Pushed by jpetso into branch 'master'. daemon: Don't leave dangling Action pointers in idle-time containers If we delete the Action but don't clean up related map/set elements, the powerdevil daemon can crash e.g. in Core::onResumingFromIdle() and Core::onKIdleTimeoutReached(). This has been an issue since commit 584cfdf0 (or d91bc62f on 6.1) which made it possible for already-created actions to get deleted again at a later time. Related: bug 490356 M +10 -4daemon/powerdevilcore.cpp https://invent.kde.org/plasma/powerdevil/-/commit/7a929fa01ed036f60c5a15c72416b4e40eb03160 -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 489932] lid close results in sleep even when connected to external monitor
https://bugs.kde.org/show_bug.cgi?id=489932 Jakob Petsovits changed: What|Removed |Added CC||jpe...@petsovits.com --- Comment #2 from Jakob Petsovits --- PowerDevil ignores logind settings, its own settings (i.e. power state behavior configured in System Settings / Power Management) replace logind behavior. I can't confirm the bug though. The laptop lid settings in System Settings for my "On Battery" profile are set to "Sleep", and the checkbox "Even when an external monitor is connected" is unchecked. With this configuration, when I close the laptop, the laptop keeps running and the external monitor becomes the only screen. Only when I check the checkbox and apply, then the laptop actually goes to sleep. The "HandleButtonEvents" action that governs this behavior wouldn't be affected by all the recent display refactoring changes, because it never relied on PowerDevil's internal DDC/CI monitor recognition to begin with. It gets its data from KWin, which gets the set of connected displays directly from the kernel. Although I wonder if the "output type" from KWin is perhaps KScreen::Output::Unknown so the monitor gets ignored for determining this behavior? -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 490421] PowerDevil crash in Core::onKIdleTimeoutReached()
https://bugs.kde.org/show_bug.cgi?id=490421 Jakob Petsovits changed: What|Removed |Added Summary|Crashed while idle. |PowerDevil crash in ||Core::onKIdleTimeoutReached ||() -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 490421] Crashed while idle.
https://bugs.kde.org/show_bug.cgi?id=490421 Jakob Petsovits changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=490356 -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 490356] PowerDevil crash in Core::onResumingFromIdle()
https://bugs.kde.org/show_bug.cgi?id=490356 Jakob Petsovits changed: What|Removed |Added Summary|Power Manager crashed and |PowerDevil crash in |reset monitor (DisplayPort) |Core::onResumingFromIdle() |backlight to 0 (dpms) | See Also||https://bugs.kde.org/show_b ||ug.cgi?id=490421 --- Comment #4 from Jakob Petsovits --- Renaming from the original title "Power Manager crashed and reset monitor (DisplayPort) backlight to 0 (dpms)". -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 490356] Power Manager crashed and reset monitor (DisplayPort) backlight to 0 (dpms)
https://bugs.kde.org/show_bug.cgi?id=490356 Jakob Petsovits changed: What|Removed |Added CC||kevin.legoug...@gmail.com --- Comment #3 from Jakob Petsovits --- *** Bug 489923 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 489923] KDE Power Management System crash in Core::onResumingFromIdle()
https://bugs.kde.org/show_bug.cgi?id=489923 Jakob Petsovits changed: What|Removed |Added CC||jpe...@petsovits.com Summary|KDE Power Management System |KDE Power Management System |crash |crash in ||Core::onResumingFromIdle() Resolution|--- |DUPLICATE Status|REPORTED|RESOLVED --- Comment #1 from Jakob Petsovits --- I've got an understanding of the issue and a fix, marking as duplicate of 490356. Thanks for reporting the crash! *** This bug has been marked as a duplicate of bug 490356 *** -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 490356] Power Manager crashed and reset monitor (DisplayPort) backlight to 0 (dpms)
https://bugs.kde.org/show_bug.cgi?id=490356 Jakob Petsovits changed: What|Removed |Added Ever confirmed|0 |1 CC||jpe...@petsovits.com Status|REPORTED|ASSIGNED --- Comment #2 from Jakob Petsovits --- Likely also fixed by https://invent.kde.org/plasma/powerdevil/-/merge_requests/406, although the initial target of that fix was the backtrace of Bug 490421. Thanks for reporting! -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 490421] Crashed while idle.
https://bugs.kde.org/show_bug.cgi?id=490421 Jakob Petsovits changed: What|Removed |Added CC||jpe...@petsovits.com Status|REPORTED|ASSIGNED Ever confirmed|0 |1 --- Comment #1 from Jakob Petsovits --- A relevant merge request has been created @ https://invent.kde.org/plasma/powerdevil/-/merge_requests/406 -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 430439] Going to 0% brightness using the applet's slider doesn't turn off the backlight; 0% using keyboard actions does
https://bugs.kde.org/show_bug.cgi?id=430439 --- Comment #9 from Jakob Petsovits --- Git commit 6ca6308ccd2f3266f20f84af6658fa97547e12ee by Jakob Petsovits. Committed on 18/07/2024 at 07:13. Pushed by jpetso into branch 'master'. wayland: Use brightness range 1..max for internal displays This avoids regressing compared to PowerDevil in 6.1 which also protected against setting internal display brightness to 0. Related: bug 483490 M +2-1src/wayland/externalbrightness_v1.cpp https://invent.kde.org/plasma/kwin/-/commit/6ca6308ccd2f3266f20f84af6658fa97547e12ee -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 483490] No longer possible to set DDC/CI compatible external monitor to 0% brightness using system tray screen brightness slider (limited to 1%)
https://bugs.kde.org/show_bug.cgi?id=483490 --- Comment #9 from Jakob Petsovits --- Git commit 6ca6308ccd2f3266f20f84af6658fa97547e12ee by Jakob Petsovits. Committed on 18/07/2024 at 07:13. Pushed by jpetso into branch 'master'. wayland: Use brightness range 1..max for internal displays This avoids regressing compared to PowerDevil in 6.1 which also protected against setting internal display brightness to 0. Related: bug 430439 M +2-1src/wayland/externalbrightness_v1.cpp https://invent.kde.org/plasma/kwin/-/commit/6ca6308ccd2f3266f20f84af6658fa97547e12ee -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 489799] Powerdevil kcm: Keyboard accelrerators don't show up, and sometimes don't work if they do
https://bugs.kde.org/show_bug.cgi?id=489799 Jakob Petsovits changed: What|Removed |Added Component|general |kcm_powerdevil Product|Powerdevil |systemsettings CC||jpe...@petsovits.com, ||k...@privat.broulik.de -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 486506] Firefox (Flatpak) does not inhibit power management when playing videos
https://bugs.kde.org/show_bug.cgi?id=486506 --- Comment #14 from Jakob Petsovits --- (In reply to Justin Zobel from comment #13) > (In reply to Valeriy from comment #12) > > (In reply to Justin Zobel from comment #11) > > > (In reply to Valeriy from comment #10) > > > > Hello, everyone. Seems like this is a result of misconfiguration on the > > > > flatpak package's maintainers. Add permission to talk with > > > > org.freedesktop.ScreenSaver of Session Bus and Firefox should prevent > > > > the > > > > screen from locking again if you watch videos. > > > > > > Have you tested this with a local build or confirmed this from Mozilla on > > > their Bugzilla tracker? > > > > I've only tested this locally on my machine. > > Well if it works there I'd suggest reporting to Mozilla so they can > integrate it into their Flatpak build. In a Flatpak environment, they should probably use the `org.freedesktop.portal.Inhibit` interface [1] rather than `org.freedesktop.Inhibit`. KDE's portal implementation exists [2], so in theory this would allow the most cross-platform implementation as `org.freedesktop.Inhibit` is now considered legacy for non-sandboxed apps (those should use the systemd inhibit interface [3] instead). But I agree with Justin that Firefox developers should have a look at why their Flatpak build isn't using the portal API. [1] https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.Inhibit.html [2] https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/blob/master/src/inhibit.cpp [3] https://www.freedesktop.org/software/systemd/man/latest/org.freedesktop.login1.html -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 489169] Powerdevil crashes a lot in ddc_close_display() after update to Plasma 6.1.0
https://bugs.kde.org/show_bug.cgi?id=489169 --- Comment #14 from Jakob Petsovits --- (In reply to ezh from comment #13) > So, did it made into 6.1.2? Nate changed the Version Fixed In field to 6.1.2. The release ended up recreating the powerdevil 6.1.2 release tarball before it got released to the public. So you'll get it anywhere that Plasma 6.1.2 is available. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 489169] Powerdevil crashes a lot in ddc_close_display() after update to Plasma 6.1.0
https://bugs.kde.org/show_bug.cgi?id=489169 Jakob Petsovits changed: What|Removed |Added Version Fixed In||6.1.3 --- Comment #11 from Jakob Petsovits --- The merge narrowly missed 6.1.2, so it looks like 6.1.3 in two weeks will be the first release containing this fix. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 489169] Powerdevil crashes a lot in ddc_close_display() after update to Plasma 6.1.0
https://bugs.kde.org/show_bug.cgi?id=489169 Jakob Petsovits changed: What|Removed |Added Latest Commit|https://invent.kde.org/plas |https://invent.kde.org/plas |ma/powerdevil/-/commit/7e11 |ma/powerdevil/-/commit/2097 |30ffcf7ad667272dabf83451522 |82d50796d8aa2bfe36753c69ed6 |36a38bf2a |c77ec5c99 --- Comment #10 from Jakob Petsovits --- Git commit 209782d50796d8aa2bfe36753c69ed6c77ec5c99 by Jakob Petsovits. Committed on 02/07/2024 at 12:06. Pushed by jpetso into branch 'Plasma/6.1'. daemon/controllers: Reintroduce a mutex around ddca_open_display2() ddcutil keeps some global state, and in particular we've seen a crash in ddc_close_display() related to its open_displays hashmap. One likely culprit for such a crash is that brightness workers run on separate threads, one per DDCutilDisplay object, so they could get executed simultaneously when more than one external monitor is involved. A less likely, but still possible culprit is when a DDCutilDisplay constructor opens a display handle at the same time that a brightness worker sets the brightness of a different display on a different thread. We could look into combining all brightness setter calls into a single BrightnessWorker that gets shared across DDCutilDisplay objects, but this would introduce extra complexity and still wouldn't address the constructor vs. brightness setter issue. So this commit reintroduces a mutex to isolate all of these usages from each other. We had one in 5.x, which was removed in 6.0 at my (in hindsight incorrect) request: https://invent.kde.org/plasma/powerdevil/-/merge_requests/312#note_865976, https://invent.kde.org/plasma/powerdevil/-/merge_requests/312#note_867942 (cherry picked from commit 7e1130ffcf7ad667272dabf8345152236a38bf2a) Co-authored-by: Jakob Petsovits M +5-1daemon/controllers/ddcutildetector.cpp M +41 -30 daemon/controllers/ddcutildisplay.cpp M +3-1daemon/controllers/ddcutildisplay.h https://invent.kde.org/plasma/powerdevil/-/commit/209782d50796d8aa2bfe36753c69ed6c77ec5c99 -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 489169] Powerdevil crashes a lot in ddc_close_display() after update to Plasma 6.1.0
https://bugs.kde.org/show_bug.cgi?id=489169 Jakob Petsovits changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Latest Commit||https://invent.kde.org/plas ||ma/powerdevil/-/commit/7e11 ||30ffcf7ad667272dabf83451522 ||36a38bf2a --- Comment #9 from Jakob Petsovits --- Git commit 7e1130ffcf7ad667272dabf8345152236a38bf2a by Jakob Petsovits. Committed on 02/07/2024 at 12:03. Pushed by jpetso into branch 'master'. daemon/controllers: Reintroduce a mutex around ddca_open_display2() ddcutil keeps some global state, and in particular we've seen a crash in ddc_close_display() related to its open_displays hashmap. One likely culprit for such a crash is that brightness workers run on separate threads, one per DDCutilDisplay object, so they could get executed simultaneously when more than one external monitor is involved. A less likely, but still possible culprit is when a DDCutilDisplay constructor opens a display handle at the same time that a brightness worker sets the brightness of a different display on a different thread. We could look into combining all brightness setter calls into a single BrightnessWorker that gets shared across DDCutilDisplay objects, but this would introduce extra complexity and still wouldn't address the constructor vs. brightness setter issue. So this commit reintroduces a mutex to isolate all of these usages from each other. We had one in 5.x, which was removed in 6.0 at my (in hindsight incorrect) request: https://invent.kde.org/plasma/powerdevil/-/merge_requests/312#note_865976, https://invent.kde.org/plasma/powerdevil/-/merge_requests/312#note_867942 M +5-1daemon/controllers/ddcutildetector.cpp M +41 -30 daemon/controllers/ddcutildisplay.cpp M +3-1daemon/controllers/ddcutildisplay.h https://invent.kde.org/plasma/powerdevil/-/commit/7e1130ffcf7ad667272dabf8345152236a38bf2a -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 483040] Brightness slider in System Tray is jumpy, especially if dragged continuously or scrolled
https://bugs.kde.org/show_bug.cgi?id=483040 Jakob Petsovits changed: What|Removed |Added CC||jpe...@petsovits.com Resolution|--- |FIXED Status|CONFIRMED |RESOLVED Version Fixed In||6.1.0 --- Comment #5 from Jakob Petsovits --- (In reply to Fushan Wen from comment #2) > Should be fixed in 6.1 with the ported dataengine I haven't encountered this since the dataengine port went into 6.1. Also there's the extra fixes from Bug 470106, the latest of which went into Plasma 6.1.1. The brightness slider now seems snappy and not jumpy, so I think it's reasonable to mark this as fixed. Let us know if you still encounter any related issues. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 482713] DDC-based Screen brightness control randomly unavailable in some sessions
https://bugs.kde.org/show_bug.cgi?id=482713 --- Comment #14 from Jakob Petsovits --- Git commit 220b6b9531b21bb3d2cc790c6a3718af3df7aa7b by Volodymyr Zolotopupov. Committed on 02/07/2024 at 08:35 CET. Pushed by jpetso into branch 'master'. ddcutildisplay: give some time before changing brightness after the monitor resumes M +4-1daemon/controllers/ddcutildisplay.cpp https://invent.kde.org/plasma/powerdevil/-/commit/220b6b9531b21bb3d2cc790c6a3718af3df7aa7b And also cherry-picked into Plasma/6.1 (will be released with 6.1.2): https://invent.kde.org/plasma/powerdevil/-/commit/0c084dcb444173273b60934af7bdb321d39dbf13 -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 434486] Powerdevil bug killing my bluetooth?
https://bugs.kde.org/show_bug.cgi?id=434486 Jakob Petsovits changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |UNMAINTAINED --- Comment #5 from Jakob Petsovits --- Ivan Tkachenko recently found and fixed an issue that resulted in two "QObject::disconnect: Unexpected nullptr parameter" log lines, see the merge request at https://invent.kde.org/plasma/powerdevil/-/merge_requests/371. Other than the undesirable logs, there was no bug. There's a good chance that your logs were merely the consequence of your bluetooth device's batteries disappearing, at which point the older powerdevil service would print such log lines. Given that we now have a good explanation for these logs, and (as mentioned earlier) PowerDevil in Plasma 6.0 or above does not interface with Bluetooth devices other than tracking their battery state, and any bug-fixing work will only go towards the 6.x series, I think we should close this bug. If there is still an issue and reason to believe that Plasma/PowerDevil/BlueDevil is indeed the culprit, please report a new bug with description and logs updated to newer versions. -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 488134] On X11, when screen is locked and all black, hitting ESC key turns the screen on and then back off immediately
https://bugs.kde.org/show_bug.cgi?id=488134 Jakob Petsovits changed: What|Removed |Added CC||jpe...@petsovits.com -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 489169] Powerdevil crashes a lot in ddc_close_display() after update to Plasma 6.1.0
https://bugs.kde.org/show_bug.cgi?id=489169 --- Comment #6 from Jakob Petsovits --- I don't see it in this backtrace, but the one from Bug 489163 has two different threads (Thread 1 and Thread 3) both in BrightnessWorker::ddcSetBrightness(). This made me think - the DDCutilDisplay class's m_brightnessWorkerThread is created per instance, which means that for more than one monitor we'd have more than one brightness setter thread. I think this could be the root of this issue, and would explain why I've never seen the crash in my single-DDC-monitor setup despite months of use. I'll try tomorrow to refactor it so that the same thread is used across all different monitors, to prevent simultaneous function execution messing up ddcutil's internal (global) state. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 476540] Screens dims but doesn't un-dim after screens were switched off
https://bugs.kde.org/show_bug.cgi?id=476540 Jakob Petsovits changed: What|Removed |Added CC||jpe...@petsovits.com --- Comment #12 from Jakob Petsovits --- Would you guys agree that Bug 452492 looks like the same issue? Also note 482713 that has a proof of concept patch for testing if a longer wait before the brightness write command can help. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 482713] DDC-based Screen brightness control randomly unavailable in some sessions
https://bugs.kde.org/show_bug.cgi?id=482713 --- Comment #9 from Jakob Petsovits --- (In reply to zvova7890 from comment #6) > I don't think it is my case, but with 6.1 I have issues when the monitor > goes to sleep (DPMS). Probably, when it wakes up, Powerdevil tries to work > with HDMI/DP i2c too early, and the monitor sometimes isn't yet ready to > respond. Thanks for running this experiment. Might be related to Bug 476540, which is also seemingly related to DPMS. (My theory is that we should disable any brightness commands while DPMS has the monitor turned off, and then apply the last requested brightness after the monitor comes back.) Could you check what the value of `status` is when ddca_open_display2() fails? ddcutil_status_codes.h doesn't have a "wait and try again" status code like EAGAIN, but I wonder if perhaps DDCRC_DPMS_ASLEEP (value -3030) serves a similar purpose in this case. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 478620] Mouse navigation with numpad doesn't work under Wayland
https://bugs.kde.org/show_bug.cgi?id=478620 Jakob Petsovits changed: What|Removed |Added CC||jpe...@petsovits.com -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 489222] display brightness changing to 1 (on PC external monitors, not a notebook)
https://bugs.kde.org/show_bug.cgi?id=489222 --- Comment #6 from Jakob Petsovits --- (In reply to ezh from comment #4) > Is this format OK? Thanks, that's a good trace. Looking at the code, I wonder if in ddcutil's ddc_close_display() (at ddc/ddc_packet_io.c:373, according to your trace) the hash table is concurrently being accessed from another thread. That file has a mutex for its `open_displays` global variable (called `open_displays_mutex`) but it's not in use for opening and closing displays. The ddc_open_display() function has a comment "protect with lock?" next to a similar access of the same variable. Our code is setting the brightness from a different thread than the one that was used to initialize ddcutil. I could imagine that powerdevil's brightness setting code is doing something to `open_displays` at the same time as ddcutil's background display/connection monitoring code. Do you have backtraces of any further threads that might also show ddcutil functions happening simultaneously? -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 488954] Current 'Battery protection' state not correctly shown
https://bugs.kde.org/show_bug.cgi?id=488954 --- Comment #11 from Jakob Petsovits --- (In reply to Vinícius from comment #10) > (In reply to Tim from comment #2) > > (In reply to Jakob Petsovits from comment #1) > > > Would this be a duplicate of Bug 487745? > > > > Yes, I think so. I didn't find that one when searching before reporting. > > > > There are slight differences in the descriptions; A reboot is not necessary > > to trigger the issue and the 'Apply button' behaviour is not mentioned. > > i didn't mentioned, but i get the same behaviour, i didn't mentioned because > i though that the checkbox "syncs" with the system that's why the apply > button stay greyed out, so intended behavior i guess? The incorrect "saved state" would also affect whether the Apply button gets enabled or disabled. Not exactly intended behavior but the fix explains why it would behave incorrectly. I would assume (but can't test on my system) that the fix makes both the checkmark and the button work correctly for both of you. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 487745] Charge Limit threshold on Lenovo Ideapad don't show correctly the value of /sys/.../conservation_mode
https://bugs.kde.org/show_bug.cgi?id=487745 --- Comment #3 from Jakob Petsovits --- (In reply to Vinícius from comment #1) > now i don't know if it's an issue with the charge limit threshold or the > System settings, because the same behavior(of deselecting the option) happen > in the Login Screen (SDDM) tab :/ If there's an issue with the SDDM tab, that would most likely be a different bug. Charge limits and SDDM don't share any of this code, and System Settings can't really be responsible as it sits on a different abstraction level for this kind of issue. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 487745] Charge Limit threshold on Lenovo Ideapad don't show correctly the value of /sys/.../conservation_mode
https://bugs.kde.org/show_bug.cgi?id=487745 Jakob Petsovits changed: What|Removed |Added Status|REPORTED|RESOLVED CC||jpe...@petsovits.com Resolution|--- |DUPLICATE --- Comment #2 from Jakob Petsovits --- Marking as duplicate of Bug 488954, which was just fixed (for 6.1.1) by that bug's reporter himself. I'm pretty sure it's the same root cause, feel free to reopen if Plasma 6.1.1 does not fix the issue. Thanks! *** This bug has been marked as a duplicate of bug 488954 *** -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 488954] Current 'Battery protection' state not correctly shown
https://bugs.kde.org/show_bug.cgi?id=488954 Jakob Petsovits changed: What|Removed |Added CC||viniciusdaros2...@gmail.com --- Comment #9 from Jakob Petsovits --- *** Bug 487745 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 488954] Current 'Battery protection' state not correctly shown
https://bugs.kde.org/show_bug.cgi?id=488954 Jakob Petsovits changed: What|Removed |Added Version Fixed In||6.1.1 -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 488954] Current 'Battery protection' state not correctly shown
https://bugs.kde.org/show_bug.cgi?id=488954 Jakob Petsovits changed: What|Removed |Added Latest Commit|https://invent.kde.org/plas |https://invent.kde.org/plas |ma/powerdevil/-/commit/4344 |ma/powerdevil/-/commit/7da8 |6c371ba62ab2dd939a242affcd1 |20f5ba64766b15c1451ad0fbed3 |fd97641e9 |b714ed307 --- Comment #8 from Jakob Petsovits --- Git commit 7da820f5ba64766b15c1451ad0fbed3b714ed307 by Jakob Petsovits. Committed on 24/06/2024 at 19:58. Pushed by jpetso into branch 'Plasma/6.1'. Fix initial UI state of Battery protection setting The setting 'Battery protection' in System Settings -> Power Management -> Advanced Power Settings was always initially shown deactivated and did not reflect the actual state of the system as given in `/sys/bus/platform/drivers/ideapad_acpi/VPC2004\:00/conservation_mode`. This was fixed so that the initial GUI state reflects the current system state. (cherry picked from commit 43446c371ba62ab2dd939a242affcd1fd97641e9) Co-authored-by: Tim Jagenberg M +1-1kcmodule/profiles/ExternalServiceSettings.cpp https://invent.kde.org/plasma/powerdevil/-/commit/7da820f5ba64766b15c1451ad0fbed3b714ed307 -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 488954] Current 'Battery protection' state not correctly shown
https://bugs.kde.org/show_bug.cgi?id=488954 --- Comment #4 from Jakob Petsovits --- (In reply to Tim from comment #3) > Shouldn't the initial value of the batteryConservationMode be set to the > value read by the getconservationmode job similar to the line above? > > https://github.com/KDE/powerdevil/blob/master/kcmodule/profiles/ExternalServiceSettings.cpp#L105 So that it reads like this: setBatteryConservationMode(m_savedBatteryConservationMode); which was just written by setSavedBatteryConservationMode() with the job result, instead of setBatteryConservationMode(m_batteryConservationMode); which is merely the pre-existing value as it was initialized earlier? I think that's an extremely promising attempt at a fix. Fabian, could you test this change and submit an MR if it fixes the bug? -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 484663] Switching from low battery mode to AC power should restore previous screen brightness
https://bugs.kde.org/show_bug.cgi?id=484663 Jakob Petsovits changed: What|Removed |Added CC||snd.no...@gmail.com --- Comment #5 from Jakob Petsovits --- *** Bug 488543 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 488543] Screen should not stay dimmed after connecting power supply
https://bugs.kde.org/show_bug.cgi?id=488543 Jakob Petsovits changed: What|Removed |Added CC||jpe...@petsovits.com Status|CONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jakob Petsovits --- *** This bug has been marked as a duplicate of bug 484663 *** -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 488954] Current 'Battery protection' state not correctly shown
https://bugs.kde.org/show_bug.cgi?id=488954 --- Comment #1 from Jakob Petsovits --- Would this be a duplicate of Bug 487745? -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 488954] Current 'Battery protection' state not correctly shown
https://bugs.kde.org/show_bug.cgi?id=488954 Jakob Petsovits changed: What|Removed |Added CC||fabian.ar...@root-core.net, ||jpe...@petsovits.com -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 489003] Cant change power profiles despite power-profiles-daemon being enabled and working
https://bugs.kde.org/show_bug.cgi?id=489003 Jakob Petsovits changed: What|Removed |Added Severity|critical|normal -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 489003] Cant change power profiles despite power-profiles-daemon being enabled and working
https://bugs.kde.org/show_bug.cgi?id=489003 Jakob Petsovits changed: What|Removed |Added CC||jpe...@petsovits.com --- Comment #2 from Jakob Petsovits --- Let me confirm: You added a Power and Battery widget to your desktop, and displays different (incorrect) values there compared with the version in your system tray? But also in the original imgur album, the second image shows "No Batteries Available" when hovering over the system tray icon... so it's not just the stand-alone widget that's showing wrong values? -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 470106] brightness-control slider shows different percentage than OSD
https://bugs.kde.org/show_bug.cgi?id=470106 Jakob Petsovits changed: What|Removed |Added Resolution|--- |FIXED Version Fixed In||6.1.1 Status|ASSIGNED|RESOLVED --- Comment #9 from Jakob Petsovits --- There were a few fixes, both in the 6.0 cycle for the brightness applet and now in 6.1.1 for the background service. I haven't reproduced the original issue, but I've been trying to get the slider out of sync with sudden changes and haven't been able to break it. I believe the issue as reported is now fixed, so I'll mark it RESOLVED FIXED. If you still experience any sudden jumps or out-of-sync values getting displayed, feel free to reopen this. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 481003] display brightness applet laggy and sometimes does not react to input
https://bugs.kde.org/show_bug.cgi?id=481003 Jakob Petsovits changed: What|Removed |Added CC||jpe...@petsovits.com Version Fixed In||6.1.1 -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 470106] brightness-control slider shows different percentage than OSD
https://bugs.kde.org/show_bug.cgi?id=470106 --- Comment #8 from Jakob Petsovits --- Git commit 1017585fe5ef2263e02e6dc6f5227de15fb3ba5d by Jakob Petsovits. Committed on 22/06/2024 at 12:16. Pushed by jpetso into branch 'Plasma/6.1'. daemon: Limit KAuth backlighthelper calls to only one at a time KAuth invocations are slower than users can move a slider. So we get many brightness change requests, and KAuth can't keep up. As a result, high-frequency brightness change requests for BacklightBrightness (i.e. laptop displays) would feel very laggy and get worse over time if not given a break to catch up. This commit fixes the lagginess. Conceptually it's easy: Don't start a new KAuth helper job until the current one has reported a result. At that point, check if a different brightness level was requested in the meantime, and start another job only then. BacklightHelper can deal fine with interrupting a running animation and starting a new one from the current brightness level. Hence, there is no need to wait until the end of the brightness animation to start a new KAuth job - this would only increase latency. Starting the new job right after receiving a result is perfectly fine. In the same go, we make two related improvements. Firstly, the udev-powered brightness observer will not only ignore events when the animation timer is running, but also in between setBrightness() and the KAuth result handler where the timer is started. Secondly, the condition involving m_brightnessAnimationThreshold is changed to something sensible. It makes no sense to simply check the current brightness against a constant number (100) to determine whether the brightness change should be animated. What I think this meant to do is to ensure that there are enough brightness steps available to animate. So following this commit, we will now animate when the difference between the current and the requested brightness is 100 or more integer steps. Taken together, laptop brightness slider UX now seems decent. Related: bug 481003 (cherry picked from commit 033825d2217ec3c91af5af1fc0a6fbb66f91fdbd) M +38 -13 daemon/controllers/backlightbrightness.cpp M +3-0daemon/controllers/backlightbrightness.h https://invent.kde.org/plasma/powerdevil/-/commit/1017585fe5ef2263e02e6dc6f5227de15fb3ba5d -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 481003] display brightness applet laggy and sometimes does not react to input
https://bugs.kde.org/show_bug.cgi?id=481003 Jakob Petsovits changed: What|Removed |Added Latest Commit|https://invent.kde.org/plas |https://invent.kde.org/plas |ma/powerdevil/-/commit/0338 |ma/powerdevil/-/commit/1017 |25d2217ec3c91af5af1fc0a6fbb |585fe5ef2263e02e6dc6f5227de |66f91fdbd |15fb3ba5d --- Comment #6 from Jakob Petsovits --- Git commit 1017585fe5ef2263e02e6dc6f5227de15fb3ba5d by Jakob Petsovits. Committed on 22/06/2024 at 12:16. Pushed by jpetso into branch 'Plasma/6.1'. daemon: Limit KAuth backlighthelper calls to only one at a time KAuth invocations are slower than users can move a slider. So we get many brightness change requests, and KAuth can't keep up. As a result, high-frequency brightness change requests for BacklightBrightness (i.e. laptop displays) would feel very laggy and get worse over time if not given a break to catch up. This commit fixes the lagginess. Conceptually it's easy: Don't start a new KAuth helper job until the current one has reported a result. At that point, check if a different brightness level was requested in the meantime, and start another job only then. BacklightHelper can deal fine with interrupting a running animation and starting a new one from the current brightness level. Hence, there is no need to wait until the end of the brightness animation to start a new KAuth job - this would only increase latency. Starting the new job right after receiving a result is perfectly fine. In the same go, we make two related improvements. Firstly, the udev-powered brightness observer will not only ignore events when the animation timer is running, but also in between setBrightness() and the KAuth result handler where the timer is started. Secondly, the condition involving m_brightnessAnimationThreshold is changed to something sensible. It makes no sense to simply check the current brightness against a constant number (100) to determine whether the brightness change should be animated. What I think this meant to do is to ensure that there are enough brightness steps available to animate. So following this commit, we will now animate when the difference between the current and the requested brightness is 100 or more integer steps. Taken together, laptop brightness slider UX now seems decent. Related: bug 470106 (cherry picked from commit 033825d2217ec3c91af5af1fc0a6fbb66f91fdbd) M +38 -13 daemon/controllers/backlightbrightness.cpp M +3-0daemon/controllers/backlightbrightness.h https://invent.kde.org/plasma/powerdevil/-/commit/1017585fe5ef2263e02e6dc6f5227de15fb3ba5d -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 470106] brightness-control slider shows different percentage than OSD
https://bugs.kde.org/show_bug.cgi?id=470106 --- Comment #6 from Jakob Petsovits --- Git commit 033825d2217ec3c91af5af1fc0a6fbb66f91fdbd by Jakob Petsovits. Committed on 22/06/2024 at 11:46. Pushed by jpetso into branch 'master'. daemon: Limit KAuth backlighthelper calls to only one at a time KAuth invocations are slower than users can move a slider. So we get many brightness change requests, and KAuth can't keep up. As a result, high-frequency brightness change requests for BacklightBrightness (i.e. laptop displays) would feel very laggy and get worse over time if not given a break to catch up. This commit fixes the lagginess. Conceptually it's easy: Don't start a new KAuth helper job until the current one has reported a result. At that point, check if a different brightness level was requested in the meantime, and start another job only then. BacklightHelper can deal fine with interrupting a running animation and starting a new one from the current brightness level. Hence, there is no need to wait until the end of the brightness animation to start a new KAuth job - this would only increase latency. Starting the new job right after receiving a result is perfectly fine. In the same go, we make two related improvements. Firstly, the udev-powered brightness observer will not only ignore events when the animation timer is running, but also in between setBrightness() and the KAuth result handler where the timer is started. Secondly, the condition involving m_brightnessAnimationThreshold is changed to something sensible. It makes no sense to simply check the current brightness against a constant number (100) to determine whether the brightness change should be animated. What I think this meant to do is to ensure that there are enough brightness steps available to animate. So following this commit, we will now animate when the difference between the current and the requested brightness is 100 or more integer steps. Taken together, laptop brightness slider UX now seems decent. Related: bug 481003 M +38 -13 daemon/controllers/backlightbrightness.cpp M +3-0daemon/controllers/backlightbrightness.h https://invent.kde.org/plasma/powerdevil/-/commit/033825d2217ec3c91af5af1fc0a6fbb66f91fdbd -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 481003] display brightness applet laggy and sometimes does not react to input
https://bugs.kde.org/show_bug.cgi?id=481003 Jakob Petsovits changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Latest Commit||https://invent.kde.org/plas ||ma/powerdevil/-/commit/0338 ||25d2217ec3c91af5af1fc0a6fbb ||66f91fdbd --- Comment #5 from Jakob Petsovits --- Git commit 033825d2217ec3c91af5af1fc0a6fbb66f91fdbd by Jakob Petsovits. Committed on 22/06/2024 at 11:46. Pushed by jpetso into branch 'master'. daemon: Limit KAuth backlighthelper calls to only one at a time KAuth invocations are slower than users can move a slider. So we get many brightness change requests, and KAuth can't keep up. As a result, high-frequency brightness change requests for BacklightBrightness (i.e. laptop displays) would feel very laggy and get worse over time if not given a break to catch up. This commit fixes the lagginess. Conceptually it's easy: Don't start a new KAuth helper job until the current one has reported a result. At that point, check if a different brightness level was requested in the meantime, and start another job only then. BacklightHelper can deal fine with interrupting a running animation and starting a new one from the current brightness level. Hence, there is no need to wait until the end of the brightness animation to start a new KAuth job - this would only increase latency. Starting the new job right after receiving a result is perfectly fine. In the same go, we make two related improvements. Firstly, the udev-powered brightness observer will not only ignore events when the animation timer is running, but also in between setBrightness() and the KAuth result handler where the timer is started. Secondly, the condition involving m_brightnessAnimationThreshold is changed to something sensible. It makes no sense to simply check the current brightness against a constant number (100) to determine whether the brightness change should be animated. What I think this meant to do is to ensure that there are enough brightness steps available to animate. So following this commit, we will now animate when the difference between the current and the requested brightness is 100 or more integer steps. Taken together, laptop brightness slider UX now seems decent. Related: bug 470106 M +38 -13 daemon/controllers/backlightbrightness.cpp M +3-0daemon/controllers/backlightbrightness.h https://invent.kde.org/plasma/powerdevil/-/commit/033825d2217ec3c91af5af1fc0a6fbb66f91fdbd -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kidletime] [Bug 328987] Power saving should not trigger if joystick/controller/gamepad is in use
https://bugs.kde.org/show_bug.cgi?id=328987 Jakob Petsovits changed: What|Removed |Added CC||m...@fireburn.co.uk --- Comment #52 from Jakob Petsovits --- *** Bug 486292 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 486292] Screen switches off when gaming with a joypad
https://bugs.kde.org/show_bug.cgi?id=486292 Jakob Petsovits changed: What|Removed |Added Resolution|--- |DUPLICATE CC||jpe...@petsovits.com Status|REPORTED|RESOLVED --- Comment #1 from Jakob Petsovits --- Duplicate of a long-running bug, I don't think this is even a regression, I think Plasma never handled this properly. Steam/Wine should ideally set an idle inhibitor. As a user one can do this by wrapping a command (either the game or Steam itself) with systemd-inhibit. You can also manually block suspend using the power management applet. A proper solution unfortunately isn't as easy as inhibiting all fullscreen apps, because regular apps or websites can also go fullscreen and it wouldn't be right to auto-inhibit those without a clearer indication that those are games or media which need this. The root cause is that libinput doesn't handle game controllers like it handles touchpads, mice, keyboards and other input devices, so KWin does not register the controller as user activity and will eventually send an inactivity signal to PowerDevil. I tried my hand on a daemon to monitor controller inputs, unfortunately this has side effects as the kernel will automatically disable mouse emulation once any process opens the controller input device explicitly. So that would be simply switching one annoying bug for another. According to the KWin guys, the proper solution would be to have KWin itself open the game controller input device, do its own mouse emulation if no other process uses the controller, and have controller input activity reset the inactivity timer. *** This bug has been marked as a duplicate of bug 328987 *** -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 487900] Unreliable external screen brightness control
https://bugs.kde.org/show_bug.cgi?id=487900 Jakob Petsovits changed: What|Removed |Added CC||jpe...@petsovits.com --- Comment #4 from Jakob Petsovits --- Hm, I wonder if turning off the only monitor results in an invalid max brightness value being sent from PowerDevil to the applet that it doesn't know how to handle properly. Worth investigating. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 487792] kcm_powerdevilprofilesconfig freezes
https://bugs.kde.org/show_bug.cgi?id=487792 Jakob Petsovits changed: What|Removed |Added Resolution|--- |WAITINGFORINFO Status|REPORTED|NEEDSINFO CC||jpe...@petsovits.com --- Comment #1 from Jakob Petsovits --- Are you running a dev build that isn't installed system-wide? There's an unfortunately unavoidable issue with the Power Management KCM now requiring a matching 6.1 version of the "org.kde.powerdevil.chargethresholdhelper" KAuth helper, and whoever hasn't replaced their system's pre-existing chargethreshold helper will experience a hanging KCM. See https://community.kde.org/Plasma/Plasma_6#Known_issues for a few extra links regarding the KAuth issue (unfortunately the systemd-sysext overlay MR that would make switching easier hasn't been merged so far). -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 487706] "Presentation mode" wont disappear from the list of inhibitions when disabled from System Tray -> Display Configuration
https://bugs.kde.org/show_bug.cgi?id=487706 Jakob Petsovits changed: What|Removed |Added CC||jpe...@petsovits.com -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 487743] No keyboard light control and always on by default
https://bugs.kde.org/show_bug.cgi?id=487743 Jakob Petsovits changed: What|Removed |Added CC||jpe...@petsovits.com -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 486781] "show when important" hides the battery applet as soon as laptop charges
https://bugs.kde.org/show_bug.cgi?id=486781 Jakob Petsovits changed: What|Removed |Added CC||jpe...@petsovits.com --- Comment #4 from Jakob Petsovits --- I also find it useful to know the current charge status to tell whether it's got enough of a charge to unplug and take it elsewhere. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 441057] Support 60% Charge Limit threshold for Lenovo Ideapad and Legion laptops
https://bugs.kde.org/show_bug.cgi?id=441057 Jakob Petsovits changed: What|Removed |Added Latest Commit|https://invent.kde.org/plas |https://invent.kde.org/plas |ma/powerdevil/-/merge_reque |ma/powerdevil/-/commit/53f6 |sts/248 |88de8eff37a52efed55b52d9e51 ||f5217a185 Resolution|--- |FIXED Version Fixed In||6.1 Status|ASSIGNED|RESOLVED --- Comment #6 from Jakob Petsovits --- Git commit 53f688de8eff37a52efed55b52d9e51f5217a185 by Jakob Petsovits, on behalf of Fabian Arndt. Committed on 23/05/2024 at 01:39. Pushed by jpetso into branch 'master'. Added setting for battery conservation mode (Lenovo) The setting is not consistently persistent, it resets occasionally after power loss and/or reboot. It might be a good idea to implement a toggle for restoring the setting on reboot. The path is fixed for now, as there is no evidence of a device that differs from it. At least I wasn't able to find one after a quick search. FIXED-IN: 6.1 M +16 -0daemon/chargethreshold_helper_actions.actions M +52 -0daemon/chargethresholdhelper.cpp M +4-0daemon/chargethresholdhelper.h M +6-0daemon/dbus/org.kde.Solid.PowerManagement.xml M +30 -0daemon/powerdevilcore.cpp M +4-0daemon/powerdevilcore.h M +117 -41 kcmodule/profiles/ExternalServiceSettings.cpp M +20 -0kcmodule/profiles/ExternalServiceSettings.h M +6-0kcmodule/profiles/PowerKCM.cpp M +3-0kcmodule/profiles/PowerKCM.h M +14 -2kcmodule/profiles/ui/GlobalConfig.qml https://invent.kde.org/plasma/powerdevil/-/commit/53f688de8eff37a52efed55b52d9e51f5217a185 -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 482428] Scrolling over time-based comboboxes using a two-finger touchpad scroll malfunctions
https://bugs.kde.org/show_bug.cgi?id=482428 --- Comment #7 from Jakob Petsovits --- I'll note that the "fix" referenced above looks a little different than the suggestion for expected behavior in comment #0. > The time units should range according, like if its more than 59 seconds then > change the units to mins and if more than 59 mins then to hours and so on. I wanted to do this initially, but Qt Quick makes this sort of hard. The SpinBox component has a single field called "stepSize", it affects the value for both going up and going down. Now if I'm at 1 minute, what I would like is to go down by 1 second but up by 1 minute. This can't be done without terrible (and possibly buggy) hacks at the moment, as far as I'm aware. So in the new UI, you get drop-downs with a few preset values instead, and if those preset values aren't what you're looking for, you can configure a custom value with the "Custom..." option. The dialog that presents the custom duration prompt will provide a SpinBox input field like before, but instead of combining value and time unit in the same field, it lets you choose between seconds and minutes through a pair of radio buttons to the right of the input field. This also solves the mentioned issue, though perhaps not in the way that you originally had in mind. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 482428] Scrolling over time-based comboboxes using a two-finger touchpad scroll malfunctions
https://bugs.kde.org/show_bug.cgi?id=482428 Jakob Petsovits changed: What|Removed |Added Version Fixed In||6.1.0 -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 482853] "When locked, turn off screen" needs a checkbox to disable/enable it
https://bugs.kde.org/show_bug.cgi?id=482853 --- Comment #4 from Jakob Petsovits --- Git commit 511469e52d4676d6c71f66acaaf277a7efc25e1e by Jakob Petsovits. Committed on 22/05/2024 at 04:36. Pushed by jpetso into branch 'master'. kcmodule: Switch to comboboxes for selecting idle timeout values This follows the direction spearheaded by kcm_screenlocker, in plasma/kscreenlocker commit 311db2a9. In addition to a few select preset options, the user can also select a "Custom…" option which presents a duration prompt dialog. Using comboboxes has a few nice UX characteristics: * It allows us to replace the checkbox of some timeout settings with a textual option called "Never", which is easier to grasp. Likewise, "Immediately" is more obvious than "0 sec". * It increases the mouse area available for clicking, which makes the control easier to hit for users with low-precision pointer input devices. * It sidesteps the problem of SpinBox ignoring the defined step size when scrolling with a high-resolution scroll wheel. * By putting the SpinBox into a custom duration prompt dialog, it's more obvious that both seconds and minutes are supported for each setting. Some options also provide second-level presets. The downside is that it now takes three extra clicks to enter and confirm a custom timeout duration. Hopefully our users are comfortable with that trade-off. In order to implement this, the latest versions of the ComboBoxWithCustomValue and DurationPromptDialog components are copied from kcm_screenlocker. Several improvements to these components will be fed back to kcm_screenlocker and hopefully upstreamed to Kirigami (or Kirigami Addons) at a later time. In addition, this commit introduces TimeDurationComboBox, a glue code component combining two aforementioned components, to further reduce the amount of boilerplate required in ProfileConfig.qml. Related: bug 482428 A +164 -0kcmodule/profiles/ui/ComboBoxWithCustomValue.qml [License: LGPL(v2.1+)] A +212 -0kcmodule/profiles/ui/DurationPromptDialog.qml [License: LGPL(v2.1+)] M +264 -104 kcmodule/profiles/ui/ProfileConfig.qml D +0-49 kcmodule/profiles/ui/TimeDelaySpinBox.qml A +151 -0kcmodule/profiles/ui/TimeDurationComboBox.qml [License: LGPL(v2.1+)] https://invent.kde.org/plasma/powerdevil/-/commit/511469e52d4676d6c71f66acaaf277a7efc25e1e -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 482428] Scrolling over time-based comboboxes using a two-finger touchpad scroll malfunctions
https://bugs.kde.org/show_bug.cgi?id=482428 Jakob Petsovits changed: What|Removed |Added Resolution|--- |FIXED Latest Commit||https://invent.kde.org/plas ||ma/powerdevil/-/commit/5114 ||69e52d4676d6c71f66acaaf277a ||7efc25e1e Status|ASSIGNED|RESOLVED --- Comment #6 from Jakob Petsovits --- Git commit 511469e52d4676d6c71f66acaaf277a7efc25e1e by Jakob Petsovits. Committed on 22/05/2024 at 04:36. Pushed by jpetso into branch 'master'. kcmodule: Switch to comboboxes for selecting idle timeout values This follows the direction spearheaded by kcm_screenlocker, in plasma/kscreenlocker commit 311db2a9. In addition to a few select preset options, the user can also select a "Custom…" option which presents a duration prompt dialog. Using comboboxes has a few nice UX characteristics: * It allows us to replace the checkbox of some timeout settings with a textual option called "Never", which is easier to grasp. Likewise, "Immediately" is more obvious than "0 sec". * It increases the mouse area available for clicking, which makes the control easier to hit for users with low-precision pointer input devices. * It sidesteps the problem of SpinBox ignoring the defined step size when scrolling with a high-resolution scroll wheel. * By putting the SpinBox into a custom duration prompt dialog, it's more obvious that both seconds and minutes are supported for each setting. Some options also provide second-level presets. The downside is that it now takes three extra clicks to enter and confirm a custom timeout duration. Hopefully our users are comfortable with that trade-off. In order to implement this, the latest versions of the ComboBoxWithCustomValue and DurationPromptDialog components are copied from kcm_screenlocker. Several improvements to these components will be fed back to kcm_screenlocker and hopefully upstreamed to Kirigami (or Kirigami Addons) at a later time. In addition, this commit introduces TimeDurationComboBox, a glue code component combining two aforementioned components, to further reduce the amount of boilerplate required in ProfileConfig.qml. Related: bug 482853 A +164 -0kcmodule/profiles/ui/ComboBoxWithCustomValue.qml [License: LGPL(v2.1+)] A +212 -0kcmodule/profiles/ui/DurationPromptDialog.qml [License: LGPL(v2.1+)] M +264 -104 kcmodule/profiles/ui/ProfileConfig.qml D +0-49 kcmodule/profiles/ui/TimeDelaySpinBox.qml A +151 -0kcmodule/profiles/ui/TimeDurationComboBox.qml [License: LGPL(v2.1+)] https://invent.kde.org/plasma/powerdevil/-/commit/511469e52d4676d6c71f66acaaf277a7efc25e1e -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 482853] "When locked, turn off screen" needs a checkbox to disable/enable it
https://bugs.kde.org/show_bug.cgi?id=482853 --- Comment #3 from Jakob Petsovits --- A relevant merge request gets halfway to implementing this bug report: https://invent.kde.org/plasma/powerdevil/-/merge_requests/358 In addition to UI changes, this also does away with the upper limit on locked-screen timeouts. I designed in in a way that it should be straightforward to add a "When locked: Never" option to round out the existing functionality. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 476550] After DDC-capable monitors become dimmed, moving the mouse raises them all to a single brightness value, not the brightness they had before being dimmed
https://bugs.kde.org/show_bug.cgi?id=476550 Jakob Petsovits changed: What|Removed |Added Status|REPORTED|CONFIRMED Ever confirmed|0 |1 CC||jpe...@petsovits.com --- Comment #7 from Jakob Petsovits --- So as far as I understand, there are different parts to this issue: 1. The user changes monitor brightness via monitor OSD, also because Plasma doesn't provide per-display controls at the moment. DDC/CI doesn't tell us that a change was made, that's not part of the protocol. PowerDevil would have to read each monitor's current brightness manually before initially dimming, so we know what values to return to. This is essentially Bug 411050 comment #10, and not straightforward to fix. Setting brightness via Plasma brightness controls, or setting brightness before PowerDevil starts (i.e. before login), would be a workaround to not keeping up to date on the latest brightness values. 2. The current brightness setter API only takes a single brightness value, and that value is not adjusted for different monitors. I opened this MR to sidestep this legacy brightness setter API and instead control dimming with a brightness multiplier: https://invent.kde.org/plasma/powerdevil/-/merge_requests/360 3. There's also an issue in setBrightness() in that it doesn't adjust its single value to the different possible maximum brightness values of each monitor that's getting changed. I have a patch to fix that as well, no MR yet, but that's less important here because we're sidestepping setBrightness() anyway as per the previous point. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 411050] graphical brightness control does not read actual_brightness before changing it
https://bugs.kde.org/show_bug.cgi?id=411050 Jakob Petsovits changed: What|Removed |Added CC||jpe...@petsovits.com --- Comment #10 from Jakob Petsovits --- (In reply to Martino Fontana from comment #9) > I don't reproduce the issue on the screen brightness (I have an AMD GPU). > But I do reproduce it on the keyboard backlight > (`/sys/class/leds/platform::kbd_backlight/brightness`). > Lenovo IdeaPad 5 14ARE05, Plasma 5.25.0. Devices in the Linux "backlight" subsystem can be monitored for changes. So we should always know the latest brightness of an internal laptop display. Devices in the "leds" subsystem - but also DDC/CI monitors - cannot be monitored. It would indeed be possible to perform an explicit read operation right before making any changes, but we'd have to be careful in avoiding bugs if this essentially blocking operation gets introduced into our existing keyboard brightness and/or display brightness code. It also introduces a little extra latency, so this would have to be limited to low-frequency operations like keyboard shortcuts, while applet slider changes need to remain write-only. Another not-great but potentially useful approach would be to do regular interval polling on devices without monitoring capabilities. The upside of that is getting updated values also in your brightness applet, without even trying to change it via keyboard shortcut first. Of course, the applet could also ask for an explicit read operation when it opens, so that the sliders adjust after just a fraction of a second after being opened. In general though, asking application-level code like the applet to issue manual read operations sucks, that's introducing extra complexity while the fix is still generally a buggy hack. Another perhaps more controversial approach would be to make users pick. Do you want Plasma to manage your devices, or do you want to pipe your own brightness values into the sysfs file? If there isn't a great solution without hacks, perhaps it's reasonable for Plasma to either own that brightness control without regard to external changes, or to ignore it entirely. Especially if the fix is as easy as "set the brightness again to reclaim full ownership". TL;DR: Cooperating with devices that make changes behind your back is hard and painful. -- You are receiving this mail because: You are watching all bug changes.
[kinfocenter] [Bug 487074] More battery graph display options between 2 and 12 hours
https://bugs.kde.org/show_bug.cgi?id=487074 Jakob Petsovits changed: What|Removed |Added Summary|Add few hour option between |More battery graph display |2 and 12 hours |options between 2 and 12 ||hours -- You are receiving this mail because: You are watching all bug changes.
[kinfocenter] [Bug 487074] Add few hour option between 2 and 12 hours
https://bugs.kde.org/show_bug.cgi?id=487074 Jakob Petsovits changed: What|Removed |Added Product|Powerdevil |kinfocenter CC||jpe...@petsovits.com, ||sit...@kde.org Component|general |general --- Comment #1 from Jakob Petsovits --- Reassigning to the kinfocenter product, the battery discharge graph is not part of the PowerDevil codebase. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 486605] Add option to lock screen when screen turns off
https://bugs.kde.org/show_bug.cgi?id=486605 --- Comment #3 from Jakob Petsovits --- (In reply to Synthetic451 from comment #2) > 2. But, having it in a power profile means that a user can configure a > different locking experience for docked / undocked modes. Like if I am in > the office and it's generally a safe space and I am plugged into AC power, > maybe I don't want the screen to constantly lock. However, if I am out in a > cafe on battery, then I do. Two data points which convinced me that there is no such thing as a generally safe space in the office, even docked at one's own cubicle: * At my last workplace, people who left their laptop unlocked had to buy doughnuts for the rest of the team if someone else managed to send a message from their Slack account. * At an earlier workplace, my dear coworker opened a text editor and pasted repeated lines of "I shall not leave my laptop unlocked" or something to that effect. I'm leaning toward the global setting :) -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 486605] Add option to lock screen when screen turns off
https://bugs.kde.org/show_bug.cgi?id=486605 Jakob Petsovits changed: What|Removed |Added Status|REPORTED|CONFIRMED Ever confirmed|0 |1 --- Comment #1 from Jakob Petsovits --- This seems reasonable. I wonder whether this option would be a better fit for the "Screen Locking" configuration module though? There's already a checkbox "Lock after waking from sleep", another one could go right below it saying e.g. "Lock when screen is turned off". The functional difference would be that putting the option there makes it a global setting, rather than per power state profile. Would there be a problem with using the same behavior in all power states? -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 483099] Screen energy saving not working with DisplayPort screen
https://bugs.kde.org/show_bug.cgi?id=483099 --- Comment #14 from Jakob Petsovits --- Could this be a duplicate of Bug 480026? Which was fixed by ignoring display (re)connection events for 2 seconds instead of 1 after turning off the screens. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 413451] Explicit OLED support for brightness control (laptops)
https://bugs.kde.org/show_bug.cgi?id=413451 Jakob Petsovits changed: What|Removed |Added CC||xaver.h...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 483681] Crash in KWin::ScreenCastStream::onStreamAddBuffer()
https://bugs.kde.org/show_bug.cgi?id=483681
--- Comment #7 from Jakob Petsovits ---
Maybe one more.
(gdb) frame 6
#6 0x7165f7f2ce85 in KWin::DmaBufScreenCastBuffer::create
(pwBuffer=0x64d609f57e10, options=...) at
/home/kpetso/src/kde/plasma/kwin/src/plugins/screencast/screencastbuffer.cpp:68
68 Q_ASSERT(pwBuffer->buffer->n_datas >= uint(attrs->planeCount));
(gdb) print *attrs
$11 = {planeCount = 2, width = 800, height = 1021, format = 875713089, modifier
= 72057594037927940, fd = {_M_elems = {{m_fd = 274}, {m_fd = 276}, {m_fd = -1},
{m_fd = -1}}}, offset = {_M_elems = {0, 3276800, 0, 0}}, pitch = {_M_elems =
{3200, 128, 0, 0}}}
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 483681] Crash in KWin::ScreenCastStream::onStreamAddBuffer()
https://bugs.kde.org/show_bug.cgi?id=483681
--- Comment #6 from Jakob Petsovits ---
I hit this again. The code changed a bit since last time, but the assertion and
n_datas vs. planeCount values are similar. Let's add some extra info from my
new stack trace.
(gdb) bt
#0 0x716603aab32c in ??? () at /usr/lib/libc.so.6
#1 0x716603a5a6c8 in raise () at /usr/lib/libc.so.6
#2 0x716603a424b8 in abort () at /usr/lib/libc.so.6
#3 0x71660408c6ac in ??? () at /usr/lib/libQt6Core.so.6
#4 0x71660408cebd in QMessageLogger::fatal(char const*, ...) const () at
/usr/lib/libQt6Core.so.6
#5 0x71660408cf1a in qt_assert(char const*, char const*, int) () at
/usr/lib/libQt6Core.so.6
#6 0x7165f7f2ce85 in KWin::DmaBufScreenCastBuffer::create
(pwBuffer=0x64d609f57e10, options=...) at
/home/kpetso/src/kde/plasma/kwin/src/plugins/screencast/screencastbuffer.cpp:68
#7 0x7165f7f38496 in KWin::ScreenCastStream::onStreamAddBuffer
(this=0x64d6086b5d00, pwBuffer=0x64d609f57e10) at
/home/kpetso/src/kde/plasma/kwin/src/plugins/screencast/screencaststream.cpp:218
#8 0x7165f7f38641 in operator() (__closure=0x0, data=0x64d6086b5d00,
buffer=0x64d609f57e10) at
/home/kpetso/src/kde/plasma/kwin/src/plugins/screencast/screencaststream.cpp:262
#9 0x7165f7f38669 in _FUN () at
/home/kpetso/src/kde/plasma/kwin/src/plugins/screencast/screencaststream.cpp:263
#10 0x7165f5ba146b in impl_port_use_buffers (object=0x64d609f579d0,
direction=, port_id=, flags=,
buffers=, n_buffers=) at
../pipewire/src/pipewire/stream.c:1023
#11 0x7165f5b98f5b in negotiate_mixer_buffers (n_buffers=3,
buffers=0x7ffde3c4fba0, flags=, port=0x64d609d79c90) at
../pipewire/src/pipewire/impl-port.c:1818
#12 pw_impl_port_use_buffers (port=0x64d609d79c90,
mix=mix@entry=0x64d60a2fba58, flags=flags@entry=1,
buffers=buffers@entry=0x7ffde3c4fba0, n_buffers=n_buffers@entry=3) at
../pipewire/src/pipewire/impl-port.c:1860
#13 0x7165f5b138e6 in client_node_port_use_buffers (_data=,
direction=, port_id=, mix_id=,
flags=, n_buffers=, buffers=) at
../pipewire/src/modules/module-client-node/remote-node.c:719
#14 0x7165f5b22bc7 in client_node_demarshal_port_use_buffers
(data=, msg=) at
../pipewire/src/modules/module-client-node/protocol-native.c:572
#15 0x7165f7ebc162 in process_remote (impl=impl@entry=0x64d6086aaf90) at
../pipewire/src/modules/module-protocol-native.c:1037
#16 0x7165f7ebc940 in on_remote_data (data=0x64d6086aaf90, fd=51, mask=1)
at ../pipewire/src/modules/module-protocol-native.c:1071
#17 0x7165f7efc646 in loop_iterate (object=0x64d6088f0a88,
timeout=) at ../pipewire/spa/plugins/support/loop.c:496
#18 0x7165f7f27412 in operator() (__closure=0x64d6086f19e0) at
/home/kpetso/src/kde/plasma/kwin/src/plugins/screencast/pipewirecore.cpp:67
#19 0x7165f7f281b7 in QtPrivate::FunctorCall,
QtPrivate::List<>, void, KWin::PipeWireCore::init():: >::call(struct
{...} &, void **) (f=..., arg=0x7ffde3c50590) at
/usr/include/qt6/QtCore/qobjectdefs_impl.h:137
#20 0x7165f7f28189 in
QtPrivate::FunctorCallable
>::call, void>(struct {...} &, void *, void **) (f=...,
arg=0x7ffde3c50590) at /usr/include/qt6/QtCore/qobjectdefs_impl.h:345
#21 0x7165f7f28140 in
QtPrivate::QCallableObject,
QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase *, QObject *,
void **, bool *) (which=1, this_=0x64d6086f19d0, r=0x64d6086c1c80,
a=0x7ffde3c50590, ret=0x0) at /usr/include/qt6/QtCore/qobjectdefs_impl.h:555
#22 0x716604197679 in ??? () at /usr/lib/libQt6Core.so.6
#23 0x7166041a05ea in QSocketNotifier::event(QEvent*) () at
/usr/lib/libQt6Core.so.6
#24 0x7166052fbfcb in QApplicationPrivate::notify_helper(QObject*, QEvent*)
() at /usr/lib/libQt6Widgets.so.6
#25 0x71660413db38 in QCoreApplication::notifyInternal2(QObject*, QEvent*)
() at /usr/lib/libQt6Core.so.6
#26 0x7166042ac689 in
QEventDispatcherUNIXPrivate::activateSocketNotifiers() () at
/usr/lib/libQt6Core.so.6
#27 0x7166042b262b in
QEventDispatcherUNIX::processEvents(QFlags) ()
at /usr/lib/libQt6Core.so.6
#28 0x716604bc1472 in
QUnixEventDispatcherQPA::processEvents(QFlags)
() at /usr/lib/libQt6Gui.so.6
#29 0x716604145cce in
QEventLoop::exec(QFlags) () at
/usr/lib/libQt6Core.so.6
#30 0x716604141738 in QCoreApplication::exec() () at
/usr/lib/libQt6Core.so.6
#31 0x64d606484830 in main (argc=14, argv=0x7ffde3c50f78) at
/home/kpetso/src/kde/plasma/kwin/src/main_wayland.cpp:634
(gdb) frame 6
#6 0x7165f7f2ce85 in KWin::DmaBufScreenCastBuffer::create
(pwBuffer=0x64d609f57e10, options=...) at
/home/kpetso/src/kde/plasma/kwin/src/plugins/screencast/screencastbuffer.cpp:68
68 Q_ASSERT(pwBuffer->buffer->n_datas >= uint(attrs->planeCount));
(gdb) print pwBuffer->buffer->n_datas
$1 = 1
(gdb) print attrs->planeCount
$2 = 2
So far, so similar. I'm noticing that the pipewire code locations are also
included this time (Arch package: pipewire 1:1.0.5-1).
Pressing on.
[Powerdevil] [Bug 486592] Display Brightness slider is missing on plasma 6 due to "org.kde.powerdevil.backlighthelper.brightness failed" error on launch
https://bugs.kde.org/show_bug.cgi?id=486592 --- Comment #4 from Jakob Petsovits --- (In reply to luciros601084 from comment #2) > (...) "The backend does not specify how to authorize" So KAuth/PolKit fails to run its helpers. I still don't quite grasp the internals, the only thing I can say is that PowerDevil is using the same setup as other KAuth-powered things in KDE. Do other KAuth actions such as setting date & time (from System Settings / Date & Time) or setting SDDM backgrounds (from System Settings / Colors & Themes / Login Screen (SDDM)) work for you? -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 353032] Add ability to set screen brightness for non-laptop displays so I can adjust to the room's lighting
https://bugs.kde.org/show_bug.cgi?id=353032 Jakob Petsovits changed: What|Removed |Added CC||jpe...@petsovits.com --- Comment #4 from Jakob Petsovits --- Had a quick look, apparently xrandr's `--brightness` option works by modifying the gamma, i.e. a color transformation thing. This is probably not something we want to implement as long as brightness adjustments are part of PowerDevil, but very much in scope once we manage to move brightness adjustments from PowerDevil to KWin. Support for per-display brightness in general (i.e. for backlight and DDC displays simultaneously) is on its way, slowly. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 443299] Let powerdevil change iwconfig power saving setting dynamically
https://bugs.kde.org/show_bug.cgi?id=443299 Jakob Petsovits changed: What|Removed |Added CC||jpe...@petsovits.com Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #1 from Jakob Petsovits --- PowerDevil in Plasma 6.0 does not manage wireless interfaces anymore. However, the mentioned commands can be entered as "custom scripts" in the Energy Saving KCM, which starting in Plasma 6.0 supports different script commands for both entering and leaving a power state such as "On AC Power". (Unless the commands require root permissions, in which case everything would get a little more complicated.) If you feel that there should be a GUI option for this, plasma-nm is indeed the place for this going forward. I'll leave it up to you whether you consider this issue resolved in general, if not then please open a bug for plasma-nm (or reopen this issue while reassigning the product field). -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 486500] Screen remains dimmed after wake-up
https://bugs.kde.org/show_bug.cgi?id=486500 --- Comment #15 from Jakob Petsovits --- (In reply to Mitja from comment #14) > Its Service. My mistake. Then I don't know. The only thing that's missing from your description is restarting the PowerDevil service so the saved file takes effect: > systemctl --user restart plasma-powerdevil.service If you've done that, it should have printed more logs already. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 486500] Screen remains dimmed after wake-up
https://bugs.kde.org/show_bug.cgi?id=486500 --- Comment #13 from Jakob Petsovits --- (In reply to Mitja from comment #12) > 1. Run the command systemctl --user edit plasma-powerdevil.service > 2. Added line Environment="QT_LOGGING_RULES=org.kde.powerdevil=true" under > [Section] Did you mean [Service] rather than [Section]? If it's indeed [Section], then that's why it's not working. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 394033] Disabling Screen Energy Saving disables suspending
https://bugs.kde.org/show_bug.cgi?id=394033 Jakob Petsovits changed: What|Removed |Added CC||jpe...@petsovits.com Status|REPORTED|NEEDSINFO Resolution|--- |WAITINGFORINFO --- Comment #3 from Jakob Petsovits --- This issue was filed a while ago, not reproducible by Patrick Silva in 2019, and a number of things have changed regarding suspend policies leading up to Plasma 6.0. With the current information, I don't think this bug report is actionable right now. Can this be retested on a more recent Plasma version, perhaps with an eye on the Battery applet to check that nothing else is blocking sleep? -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 369129] Powerdevil does not provide a way to inhibit display turn-off
https://bugs.kde.org/show_bug.cgi?id=369129 Jakob Petsovits changed: What|Removed |Added Summary|Powerdevil does not provide |Powerdevil does not provide |a way to inhibit screen |a way to inhibit display |saving |turn-off CC||jpe...@petsovits.com --- Comment #6 from Jakob Petsovits --- I'll take a shot at reviving this 7+ years old bug. A lot has changed since Plasma 5.7.3, and PulseAudio is also on its way out, but perhaps the underlying concerns are still valid. Importantly, Plasma on Wayland does not have a concept of screen savers. If someone wants to invoke a "screen saver" overlay window after a period of inactivity, that's possible, but it doesn't look like screen savers as a Plasma concept are going to make a comeback outside of the lock screen itself. So let's look at the lock screen specifically. Plasma 6.0 still supports the old FreeDesktop inhibit interface, and also the newer systemd-logind inhibit interface with "sleep" and "idle" inhibitors. "sleep" works like the old InterruptSession policy, meaning it will merely prevent the system from suspending. "idle" is the policy to prevent both locking and turning off the screen, also known as ChangeScreenSettings internally. PowerDevil in 6.0 will still turn off the screen if the screen locker is already active, with the rationale that no screen contents are worth saving when they're already obscured by the lock screen. Plasma 6.0 continues to have a user option for the duration until the display(s) turn(s) off, as well as a new option for the display turn-off duration when the screen is locked. One could implement the request by merely setting these configuration values to infinite (i.e. never turn off the display) but that's not a D-Bus inhibitor interface, so it would have to override the user's own setting and probably for multiple power state profiles, too. That's not a good solution for temporary inhibition. I wonder if the best course of action would be to open a discussion in the systemd issue tracker, with the same arguments. On the other hand, unlike system suspend or shutdown, DPMS is generally owned by the desktop environment (in Wayland: the compositor itself) so systemd would not provide any behavior for this inhibitor by itself, it would rely on session services to implement it in the first place. Probably a good argument for sticking with a Plasma-first approach. Either way, it seems to me that the requested interface is related but distinct from the "idle" inhibitor. Perhaps it's worth considering to rename the existing ChangeScreenSettings policy to something that more closely represents the systemd "idle" inhibitor definition. And then reintroduce ChangeScreenSettings with a new enum value as a third policy, which is inhibited if an "idle" inhibitor exists, but can also be set independently. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 486500] Screen remains dimmed after wake-up
https://bugs.kde.org/show_bug.cgi?id=486500 Jakob Petsovits changed: What|Removed |Added Summary|Reduced brightness after|Screen remains dimmed after |standby |wake-up -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 486500] Reduced brightness after standby
https://bugs.kde.org/show_bug.cgi?id=486500 Jakob Petsovits changed: What|Removed |Added Resolution|DUPLICATE |--- Status|RESOLVED|REPORTED --- Comment #10 from Jakob Petsovits --- Actually no, let me un-duplicate this again because Bug 482278 is about brightness being dimmed after *unlocking*, whereas this bug is about brightness being dimmed immediately after wake-up (i.e. brightness would be wrong even on the lock screen). Sorry about that. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 486500] Reduced brightness after standby
https://bugs.kde.org/show_bug.cgi?id=486500 Jakob Petsovits changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=482278 -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 482278] Screen remains dimmed after unlocking
https://bugs.kde.org/show_bug.cgi?id=482278 Jakob Petsovits changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=486500 -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 482278] Screen remains dimmed after unlocking
https://bugs.kde.org/show_bug.cgi?id=482278 --- Comment #10 from Jakob Petsovits --- Actually no, let me un-duplicate Bug 486500 again because this bug is about brightness being dimmed after *unlocking*, whereas Bug 486500 is about brightness being dimmed immediately after wake-up (i.e. brightness would be wrong even on the lock screen). -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 482278] Screen remains dimmed after unlocking
https://bugs.kde.org/show_bug.cgi?id=482278 Jakob Petsovits changed: What|Removed |Added Status|REPORTED|CONFIRMED Ever confirmed|0 |1 --- Comment #9 from Jakob Petsovits --- See Bug 486500 Comment #2 for an informed guess at what's happening. Brief summary, I agree with David Warner above that this is likely timing-related and perhaps caused by a lack of coordination with the DPMS (screen turn-off/on) action. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 482278] Screen remains dimmed after unlocking
https://bugs.kde.org/show_bug.cgi?id=482278 Jakob Petsovits changed: What|Removed |Added CC||mtj...@gmail.com --- Comment #8 from Jakob Petsovits --- *** Bug 486500 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 486500] Reduced brightness after standby
https://bugs.kde.org/show_bug.cgi?id=486500 Jakob Petsovits changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |DUPLICATE --- Comment #9 from Jakob Petsovits --- This looks close enough to Bug 482278 to call both reports duplicates of each other. Let's continue at the other bug, as it has been around for longer with more participants (although this one has more useful info so far). *** This bug has been marked as a duplicate of bug 482278 *** -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 465256] Powerdevil not enabling external monitor brightness controls despite ddcutil being detected
https://bugs.kde.org/show_bug.cgi?id=465256 Jakob Petsovits changed: What|Removed |Added CC||jpe...@petsovits.com --- Comment #2 from Jakob Petsovits --- Based on these logs, no backlight interface was found which means that PowerDevil would use libddcutil displays. The fact that the "BrightnessControl" action is reported as non-existent probably means that no display was added to PowerDevil's list even after querying libddcutil. I don't know why your monitor would not show up in the list. Plasma 6.1 will have a lot of improvements on the libddcutil side, including better handling of display connect/disconnect events and more informative logs. But it's not out yet. Plasma 6.0 probably still behaves substantially the same as a year ago when this was reported. You could try getting more detailed PowerDevil logs by following the instructions in the new README: https://invent.kde.org/plasma/powerdevil/-/blob/master/README.md That could at least confirm that no displays were added to the list, but I can't guarantee that the logs will provide many further insights than that. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 486422] Suspend inhibits also end up keeping the display on
https://bugs.kde.org/show_bug.cgi?id=486422 Jakob Petsovits changed: What|Removed |Added CC||jpe...@petsovits.com -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 486500] Reduced brightness after standby
https://bugs.kde.org/show_bug.cgi?id=486500 --- Comment #8 from Jakob Petsovits --- (In reply to Mitja from comment #4) > Here are the logs. I would like to note, that the reduction is higher than > 30%, because > the brightness setting is reduced from 75% to 23%. This makes a reduction of > a 70%. Sorry, yes. I should have been clear to say that the dimming action reduces brightness *to* 30% of the original value, not *by* 30%. So a reduction by 70% is expected (we just need to raise it back up after standby). -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 486500] Reduced brightness after standby
https://bugs.kde.org/show_bug.cgi?id=486500 --- Comment #7 from Jakob Petsovits --- Thanks. These are only regular logs, not verbose - did I make a mistake in the README instructions for setting the QT_LOGGING_RULES environment variable? Please double-check that this was set and powerdevil was restarted. The main thing we can learn from these logs is this line: > org.kde.powerdevil: [DDCutilDisplay]: ddca_set_non_table_vcp_value -3023 Which basically tells us that setting the brightness via DDC/CI failed. According to the libddcutil source code, this result is DDCRC_VERIFY, described as "read after VCP write failed or wrong value". I.e. the monitor was present to communicate with the system and accepted the command, but ignored it so the brightness was still unchanged. I think the theory is still the same. I'd still be interested in more detailed powerdevil logs. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 486506] Firefox (Flatpak) does not inhibit power management when playing videos
https://bugs.kde.org/show_bug.cgi?id=486506 Jakob Petsovits changed: What|Removed |Added CC||jpe...@petsovits.com -- You are receiving this mail because: You are watching all bug changes.
