[Phonon] [Bug 335729] Inhibit suspend while sound is playing
https://bugs.kde.org/show_bug.cgi?id=335729 --- Comment #9 from Jakob Petsovits --- Git commit 8fd86c5b0e6d6797bff850947b07e086544cd617 by Jakob Petsovits. Committed on 31/07/2024 at 10:37. Pushed by jpetso into branch 'Plasma/6.1'. Inhibit: Forward the correct inhibition flags to PolicyAgent The Inhibit method ignored the value of the "flags" argument and always sent InterruptSession as inhibition policy. This prevents sleep, but does not prevent idle actions such as screen locking and dimming. This commit changes the requested inhibition policies to match the documented values for "flags": * Portals "Suspend" remains PolicyAgent "InterruptSession". * Portals "Idle" becomes PolicyAgent "ChangeScreenSettings". * Portals "Logout" and "User Switch" are not supported at this time and are merely logged but otherwise ignored. PowerDevil, which implements the PolicyAgent API, uses the same policies also to represent the logind "sleep" and "idle" inhibitors, so we can trust that they behave accordingly. Related: bug 486506, bug 472541 (cherry picked from commit 1549c49f41f544cb9dad54de509f318cc5b6dc38) Co-authored-by: Jakob Petsovits M +12 -2src/inhibit.cpp https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/commit/8fd86c5b0e6d6797bff850947b07e086544cd617 -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 472541] Powerdevil idle script does not respect idle inhibition of wljoywake or caffeine
https://bugs.kde.org/show_bug.cgi?id=472541 --- Comment #13 from Jakob Petsovits --- Git commit 8fd86c5b0e6d6797bff850947b07e086544cd617 by Jakob Petsovits. Committed on 31/07/2024 at 10:37. Pushed by jpetso into branch 'Plasma/6.1'. Inhibit: Forward the correct inhibition flags to PolicyAgent The Inhibit method ignored the value of the "flags" argument and always sent InterruptSession as inhibition policy. This prevents sleep, but does not prevent idle actions such as screen locking and dimming. This commit changes the requested inhibition policies to match the documented values for "flags": * Portals "Suspend" remains PolicyAgent "InterruptSession". * Portals "Idle" becomes PolicyAgent "ChangeScreenSettings". * Portals "Logout" and "User Switch" are not supported at this time and are merely logged but otherwise ignored. PowerDevil, which implements the PolicyAgent API, uses the same policies also to represent the logind "sleep" and "idle" inhibitors, so we can trust that they behave accordingly. Related: bug 486506, bug 335729 (cherry picked from commit 1549c49f41f544cb9dad54de509f318cc5b6dc38) Co-authored-by: Jakob Petsovits M +12 -2src/inhibit.cpp https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/commit/8fd86c5b0e6d6797bff850947b07e086544cd617 -- 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 Latest Commit|https://invent.kde.org/plas |https://invent.kde.org/plas |ma/xdg-desktop-portal-kde/- |ma/xdg-desktop-portal-kde/- |/commit/1549c49f41f544cb9da |/commit/8fd86c5b0e6d6797bff |d54de509f318cc5b6dc38 |850947b07e086544cd617 --- Comment #22 from Jakob Petsovits --- Git commit 8fd86c5b0e6d6797bff850947b07e086544cd617 by Jakob Petsovits. Committed on 31/07/2024 at 10:37. Pushed by jpetso into branch 'Plasma/6.1'. Inhibit: Forward the correct inhibition flags to PolicyAgent The Inhibit method ignored the value of the "flags" argument and always sent InterruptSession as inhibition policy. This prevents sleep, but does not prevent idle actions such as screen locking and dimming. This commit changes the requested inhibition policies to match the documented values for "flags": * Portals "Suspend" remains PolicyAgent "InterruptSession". * Portals "Idle" becomes PolicyAgent "ChangeScreenSettings". * Portals "Logout" and "User Switch" are not supported at this time and are merely logged but otherwise ignored. PowerDevil, which implements the PolicyAgent API, uses the same policies also to represent the logind "sleep" and "idle" inhibitors, so we can trust that they behave accordingly. Related: bug 472541, bug 335729 (cherry picked from commit 1549c49f41f544cb9dad54de509f318cc5b6dc38) Co-authored-by: Jakob Petsovits M +12 -2src/inhibit.cpp https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/commit/8fd86c5b0e6d6797bff850947b07e086544cd617 -- You are receiving this mail because: You are watching all bug changes.
[Phonon] [Bug 335729] Inhibit suspend while sound is playing
https://bugs.kde.org/show_bug.cgi?id=335729 --- Comment #7 from Jakob Petsovits --- Git commit 1549c49f41f544cb9dad54de509f318cc5b6dc38 by Jakob Petsovits. Committed on 30/07/2024 at 11:20. Pushed by jpetso into branch 'master'. Inhibit: Forward the correct inhibition flags to PolicyAgent The Inhibit method ignored the value of the "flags" argument and always sent InterruptSession as inhibition policy. This prevents sleep, but does not prevent idle actions such as screen locking and dimming. This commit changes the requested inhibition policies to match the documented values for "flags": * Portals "Suspend" remains PolicyAgent "InterruptSession". * Portals "Idle" becomes PolicyAgent "ChangeScreenSettings". * Portals "Logout" and "User Switch" are not supported at this time and are merely logged but otherwise ignored. PowerDevil, which implements the PolicyAgent API, uses the same policies also to represent the logind "sleep" and "idle" inhibitors, so we can trust that they behave accordingly. Related: bug 486506, bug 472541 M +12 -2src/inhibit.cpp https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/commit/1549c49f41f544cb9dad54de509f318cc5b6dc38 -- 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 Latest Commit||https://invent.kde.org/plas ||ma/xdg-desktop-portal-kde/- ||/commit/1549c49f41f544cb9da ||d54de509f318cc5b6dc38 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #21 from Jakob Petsovits --- Git commit 1549c49f41f544cb9dad54de509f318cc5b6dc38 by Jakob Petsovits. Committed on 30/07/2024 at 11:20. Pushed by jpetso into branch 'master'. Inhibit: Forward the correct inhibition flags to PolicyAgent The Inhibit method ignored the value of the "flags" argument and always sent InterruptSession as inhibition policy. This prevents sleep, but does not prevent idle actions such as screen locking and dimming. This commit changes the requested inhibition policies to match the documented values for "flags": * Portals "Suspend" remains PolicyAgent "InterruptSession". * Portals "Idle" becomes PolicyAgent "ChangeScreenSettings". * Portals "Logout" and "User Switch" are not supported at this time and are merely logged but otherwise ignored. PowerDevil, which implements the PolicyAgent API, uses the same policies also to represent the logind "sleep" and "idle" inhibitors, so we can trust that they behave accordingly. Related: bug 472541, bug 335729 M +12 -2src/inhibit.cpp https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/commit/1549c49f41f544cb9dad54de509f318cc5b6dc38 -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 472541] Powerdevil idle script does not respect idle inhibition of wljoywake or caffeine
https://bugs.kde.org/show_bug.cgi?id=472541 --- Comment #11 from Jakob Petsovits --- Git commit 1549c49f41f544cb9dad54de509f318cc5b6dc38 by Jakob Petsovits. Committed on 30/07/2024 at 11:20. Pushed by jpetso into branch 'master'. Inhibit: Forward the correct inhibition flags to PolicyAgent The Inhibit method ignored the value of the "flags" argument and always sent InterruptSession as inhibition policy. This prevents sleep, but does not prevent idle actions such as screen locking and dimming. This commit changes the requested inhibition policies to match the documented values for "flags": * Portals "Suspend" remains PolicyAgent "InterruptSession". * Portals "Idle" becomes PolicyAgent "ChangeScreenSettings". * Portals "Logout" and "User Switch" are not supported at this time and are merely logged but otherwise ignored. PowerDevil, which implements the PolicyAgent API, uses the same policies also to represent the logind "sleep" and "idle" inhibitors, so we can trust that they behave accordingly. Related: bug 486506, bug 335729 M +12 -2src/inhibit.cpp https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/commit/1549c49f41f544cb9dad54de509f318cc5b6dc38 -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 489020] KWin changes monitors' internal DDC VCP values on bootup
https://bugs.kde.org/show_bug.cgi?id=489020 Jakob Petsovits changed: What|Removed |Added CC||jpe...@petsovits.com Resolution|--- |WAITINGFORINFO Status|REPORTED|NEEDSINFO --- Comment #6 from Jakob Petsovits --- (In reply to mr.yamamoto from comment #5) > To be clear, it seems as though whatever controls the values from kdes side > (which it would seem is powerdevil ddcutil?) is changing the values to > something that isn't correct, as it's not simply alternating the brightness. > What I'm doing to "fix" it, is using ddcutil, and factory resetting the > monitor, then changing the brightness to 100. The incorrect thing that is > happening, is it doesn't seem to be changing the brightness, but the > contrast and other random settings, which was not a behavior I observed > until upgrading to 6.1 What PowerDevil does is to query the monitor's capabilities using libddcutil, and if the "brightness" capability (VCP code 10) is supported then it sets the value for VCP code 10 that to whatever brightness is requested by other Plasma components. The main components that request brightness changes are the Brightness and Color applet as well as the "Dim screen" option in System Settings / Power Management. Plasma 6.1 does not set brightness on session start-up. The part that's new in Plasma 6.1 is that we're now also observing monitor connection & disconnection & sleep events through a function that was introduced recently in libddcutil 2.x. There is a chance that somehow your Wacom responds poorly to this? But I don't know what DDC commands are emitted by libddcutil to implement this functionality. Other than that, Plasma's use of DDC commands is the same as before. It would be great if you could use `ddcutil dumpvcp` to compare whether any monitor settings (a.k.a. VCP feature values) are different before and after the undesired change. Realistically though, if this comparison doesn't show an obvious mistake on our part, you may have to create a ticket on the GitHub issue tracker of upstream ddcutil. Note that as a workaround, you can disable the use of ddcutil in Plasma/PowerDevil by setting an enviroment variable POWERDEVIL_NO_DDCUTIL=1. For more details, see the PowerDevil README: https://invent.kde.org/plasma/powerdevil/-/blob/master/README.md#troubleshooting-ddcci-monitor-brightness-controls -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 472541] Powerdevil idle script does not respect idle inhibition of wljoywake or caffeine
https://bugs.kde.org/show_bug.cgi?id=472541 Jakob Petsovits changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |NOT A BUG --- Comment #10 from Jakob Petsovits --- So in Comment #8, we have an explanation for * why wljoywake won't work: it uses zwp_idle_inhibit_manager_v1 but doesn't have a Wayland surface with focus to keep inhibiting, and * why caffeine (not -ng) doesn't work: it uses xdg-screensaver, which can't work because it places incorrect assumptions on the old `org.freedesktop.ScreenSaver` interface. That seems like a good reason to close this bug report. For an inhibit method that works, consider `systemd-inhibit --what=idle`, or caffeine-ng, or anything that uses one of the inhibition D-Bus APIs correctly: `org.freedesktop.portal.Inhibit` (to be fixed by the MR above, hopefully in Plasma 6.1.4), `org.freedesktop.login1`, `org.freedesktop.PowerManagement.Inhibit`, `org.freedesktop.ScreenSaver`. -- 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 Resolution|--- |WORKSFORME Status|ASSIGNED|RESOLVED --- Comment #2 from Jakob Petsovits --- I was a little too excited about also marking this bug as fixed as a result of the above MR, but it doesn't fix this. The good news is that an InterruptSession inhibit works as intended at least on Plasma 6.1.3: * To test, I create an equivalent inhibitor which will be picked up by PowerDevil as InterruptSession: * systemd-inhibit --what=sleep --who=test --why=bug486422 sleep 3600 * Direct D-Bus calls to `org.freedesktop.portal.Inhibit` (with "Sleep" flag) or PowerDevil's own D-Bus API would behave the same. * In the Screen Locking configuration, I set a 1 minute timeout and in Power Management, turn off screen after 20 seconds when locked. * As an alternative test, I set Screen Locking to Never and in Power Management, turn off screen after 1 minute. * The screen turns off either way after the defined timeout while the system does not suspend. (In the first test, it will lock before turning off.) So I can't tell what went wrong for your user in particular, but I was able to confirm that Plasma's current implementation works as expected in this case. -- 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|REOPENED|ASSIGNED --- Comment #18 from Jakob Petsovits --- I ran dbus-monitor to see what's going on. It makes sense now and I've got a fix. The disconnect is that xdg-desktop-portals-kde receives an `Inhibit` request with flags 8 from Firefox, which according to the linked docs means inhibiting "Idle": https://docs.flatpak.org/en/latest/portal-api-reference.html#gdbus-org.freedesktop.portal.Inhibit Following that, xdg-desktop-portals-kde calls PowerDevil's `AddInhibition` with a "policies" argument of value 1, a.k.a. "InterruptSession". PowerDevil receives and registers it as requested. You'd think that this would keep the locker from firing? No, in fact, what "InterruptSession" does is to prevent sleep, not idle. The XDG portals API has a different flag for that, called "Suspend" with value 4, not 8. Hence the fix is to ask PowerDevil for the correct policy, confusingly called "ChangeScreenSettings" with value 4, not 1. We're already using this for logind "idle" inhibitors, so I'm pretty confident that it's the right pick also for portals "Idle". This also explains why the applet was showing an indicator: PowerDevil was in fact inhibiting, except not against screen locking but merely against system sleep. Here's the relevant dbus-monitor output for reference, from Firefox registering the inhibition to PowerDevil receiving it: method call time=1722263501.828060 sender=:1.262 -> destination=:1.6 serial=263 path=/org/freedesktop/portal/desktop; interface=org.freedesktop.portal.Inhibit; member=Inhibit string "org.mozilla.firefox" uint32 8 array [ dict entry( string "reason" variant string "video-playing" ) ] method call time=1722263501.828599 sender=:1.6 -> destination=org.freedesktop.DBus serial=9496 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch string "type='signal',sender='org.freedesktop.impl.portal.desktop.kde',interface='org.freedesktop.impl.portal.Request',path='/org/freedesktop/portal/desktop/request/1_262/t/3738610708'" method return time=1722263501.828618 sender=org.freedesktop.DBus -> destination=:1.6 serial=4294967295 reply_serial=9496 method call time=1722263501.828625 sender=:1.6 -> destination=org.freedesktop.DBus serial=9497 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=StartServiceByName string "org.freedesktop.impl.portal.desktop.kde" uint32 0 method return time=1722263501.828640 sender=org.freedesktop.DBus -> destination=:1.6 serial=4294967295 reply_serial=9497 uint32 2 method call time=1722263501.828871 sender=:1.6 -> destination=org.freedesktop.DBus serial=9498 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=GetNameOwner string "org.freedesktop.impl.portal.desktop.kde" method return time=1722263501.82 sender=org.freedesktop.DBus -> destination=:1.6 serial=4294967295 reply_serial=9498 string ":1.31" method return time=1722263501.829171 sender=:1.6 -> destination=:1.262 serial=9499 reply_serial=263 object path "/org/freedesktop/portal/desktop/request/1_262/t/3738610708" method call time=1722263501.829311 sender=:1.6 -> destination=:1.9 serial=9500 path=/org/freedesktop/impl/portal/PermissionStore; interface=org.freedesktop.impl.portal.PermissionStore; member=Lookup string "inhibit" string "inhibit" error time=1722263501.829910 sender=:1.9 -> destination=:1.6 error_name=org.freedesktop.portal.Error.NotFound reply_serial=9500 string "No entry for inhibit" method call time=1722263501.830200 sender=:1.6 -> destination=:1.31 serial=9501 path=/org/freedesktop/portal/desktop; interface=org.freedesktop.impl.portal.Inhibit; member=Inhibit object path "/org/freedesktop/portal/desktop/request/1_262/t/3738610708" string "org.mozilla.firefox" string "org.mozilla.firefox" uint32 8 array [ dict entry( string "reason" variant string "video-playing" ) ] method call time=1722263501.830491 sender=:1.31 -> destination=org.kde.Solid.PowerManagement serial=13663 path=/org/kde/Solid/PowerManagement/PolicyAgent; interface=org.kde.Solid.PowerManagement.PolicyAgent; member=AddInhibition uint32 1 string "org.mozilla.firefox" string "video-playing" method return time=1722263501.830515 sender=:1.31 -> destination=:1.6 serial=13664 reply_serial=9501 method call time=1722263501.830703 sender=:1.272 -> destination=org.freedesktop.DBus serial=339 path=
[Powerdevil] [Bug 490845] Change screen brightness not working
https://bugs.kde.org/show_bug.cgi?id=490845 --- Comment #2 from Jakob Petsovits --- (In reply to Rafal from comment #0) > Some sessions occur problem with changing screen brightness. First > change(click on bar or scroll up/down on tray icon) works but then any > attempts not working. Oh yeah, one more possible cause: (c) PowerDevil sends a brightness command to the monitor, but the command doesn't succeed so we remove it from the list of brightness controls. There was a recent MR at https://invent.kde.org/plasma/powerdevil/-/merge_requests/393 which improved this by delaying the command a little bit, that patch made it into 6.1.3. Given that your bug report is for 6.1.3, I'm guessing that the cause of your issue is a different one, but it's still possible that a permanently failing brightness write command will get the monitor removed from brightness controls. If this happens, you would see warning messages (likely about "ddca_set_non_table_vcp_value") in your system log, i.e. `journalctl -S today` for example. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 490845] Change screen brightness not working
https://bugs.kde.org/show_bug.cgi?id=490845
Jakob Petsovits changed:
What|Removed |Added
Resolution|--- |WAITINGFORINFO
Status|REPORTED|NEEDSINFO
CC||jpe...@petsovits.com
--- Comment #1 from Jakob Petsovits ---
(In reply to Rafal from comment #0)
> Some sessions occur problem with changing screen brightness. First
> change(click on bar or scroll up/down on tray icon) works but then any
> attempts not working.
> In journal logs i can see:
> error setting brightness via dbus
> QDBusError("org.freedesktop.DBus.Error.UnknownObject", "No such object path
> '/org/kde/Solid/PowerManagement/Actions/BrightnessControl'")
Thanks for the report and screen recording. If the BrightnessControl D-Bus
interface is missing, I can think of two possible reasons:
(a) PowerDevil crashed, which is unfortunately something that happens in 6.1.2
and 6.1.3 when waking up from inactivity and will only be fixed with 6.1.4.
Have a look with `coredumpctl --reverse` to see if a powerdevil process
recently produced a coredump after a crash. That would be Bug 490356.
(b) ddcutil lost track of the monitor, so PowerDevil removed its brightness
controls and the applet didn't recognize the disappearance of the
BrightnessControl interface. That would be Bug 482713. Have a look with
`ddcutil detect` whether your monitor is still recognized by ddcutil at all -
it happened to me recently that this would stop working until a reboot.
--
You are receiving this mail because:
You are watching all bug changes.
[Powerdevil] [Bug 484129] KDE turns down screen brightness to low percentage
https://bugs.kde.org/show_bug.cgi?id=484129 --- Comment #3 from Jakob Petsovits --- (In reply to Re Play from comment #1) > So my guess is that since version 6 this value isn't overwritten correctly > anymore. > Did something change with how the monitor brightness is being saved between 5 > and 6? A little bit, but not in a way that would persist your original brightness value at the time of upgrade. As mentioned above, Plasma doesn't store monitor brightness in the first place and that's the root of some bugs because the monitor isn't always around when Plasma wants to make a change to brightness or revert it to the previous value. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 484129] KDE turns down screen brightness to low percentage
https://bugs.kde.org/show_bug.cgi?id=484129 Jakob Petsovits changed: What|Removed |Added Status|REPORTED|NEEDSINFO Resolution|--- |WAITINGFORINFO CC||jpe...@petsovits.com --- Comment #2 from Jakob Petsovits --- (In reply to Szőts Ákos from comment #0) > In "Power saving" module the "Change screen brightness" option is off, so I > don't know where else to turn it off within KDE. I'd say it's probably "Dim automatically", which also reduces monitor brightness. Could you try out disabling that instead of all DDC brightness controls? If that's the culprit, that would make this bug report a duplicate of Bug 452492 (*). (*) The short version is that Plasma/PowerDevil doesn't (yet) store and restore brightness by itself across sleep or disconnection. A lot of work has gone into per-display brightness support, which brings us closer to getting this fixed properly. But we're not quite there yet. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 472008] Controlling monitor brightness over ddcutil sometimes unreliable
https://bugs.kde.org/show_bug.cgi?id=472008 Jakob Petsovits changed: What|Removed |Added Resolution|--- |UNMAINTAINED CC||jpe...@petsovits.com Status|REPORTED|RESOLVED --- Comment #1 from Jakob Petsovits --- (In reply to Derek Christ from comment #0) > SOFTWARE/OS VERSIONS > Operating System: Arch Linux > KDE Plasma Version: 5.27.6 > KDE Frameworks Version: 5.107.0 > Qt Version: 5.15.10 > Kernel Version: 6.4.1-arch2-1 (64-bit) I had already written up a paragraph about how the half-second delay is indeed intentional, but then I noticed that your bug report actually talks about the older Plasma 5.27 release which didn't even have an intentional delay for DDC brightness writes. Some work made it into Plasma 6.0 for reducing choppiness, and starting from 6.1 it's completely gone. > The brightness target value should be overwritten immediately, with the > actual monitor brightness following at a later point in time (when the > ddcutil communication succeeded) That's essentially how things work in recent releases, so I'll close this bug (as UNMAINTAINED because 5.27 won't get these updates anymore). I'll still include my original paragraph about Plasma 6 behavior below, for extra context. > Controlling the brightness of the monitor using ddcutil generally works but > is wonky sometimes. (Due to the nature of ddcutil) it takes a short time > until the monitor has adjusted the brightness (like half a second). > Therefore, for example changing the brightness by scrolling on the > brightness applet feels choppy as it seems it does a blocking wait until the > monitor reported the changed brightness value. The half-second delay is actually intentional behavior. DDC/CI commands will cause writes to the monitor's internal storage (EEPROM) and there is concern that for some monitors this storage will wear out over time when it's written to a lot. At which point the monitor would stop functioning. The half-second delay was introduced to minimize the amount of actual brightness changes that we need to send to the monitor, and matches the duration that Dell's Windows utility uses for the same purpose. I agree that the user experience could be better if we changed the brightness value immediately, but like everything this is a trade-off between different conflicting goals. > Also, when the monitor is dimmed to a lower brightness value and is powered > off by Plasma because of no user input , it sometimes fails to reset to the > previous brightness setting when waking up the monitor again. It just stays > at the lowest brightness setting. That's Bug 452492. Resolving this will take a bit more work, but we're closer to resolving it than half a year ago. -- 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 --- Comment #4 from Jakob Petsovits --- (In reply to Luke from comment #3) > Probably tag as more information needed. I'm unable to identify the root > cause, but the UI failure is intermittent. Sometimes the UI *does* show up > just as described in Jakob's comment. If I can't reproduce the bug myself > again in the next couple weeks I'll close the bug myself. Thanks. I'm not sure what could be causing intermittent UI failure, I haven't been seeing anything like this on my own system. Perhaps if you start `systemsettings` from the terminal, it may show some errors (or other differences) in the printed output when it fails to work compared with a problem-free instance. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 490535] Brightness Slider sometimes not affecting every monitor
https://bugs.kde.org/show_bug.cgi?id=490535 Jakob Petsovits changed: What|Removed |Added Status|REPORTED|NEEDSINFO Resolution|--- |WAITINGFORINFO --- Comment #2 from Jakob Petsovits --- (In reply to Nate Graham from comment #1) > Jakob, is there an existing bug report we could mark this as a duplicate of? I'm going to go out on a limb and hypothesize that this is one of the monitors not being detected via DDC/CI, in other words Bug 482713. We can't confirm that with the data at hand, though. Jan, when this happens again, could you check and paste the output of `ddcutil detect`? Or enable verbose logging in PowerDevil as per PowerDevil README (https://invent.kde.org/plasma/powerdevil/-/blob/master/README.md) and then see what subsequent logs are showing for DDC display detection messages, e.g. (instead of 2 displays) > [DDCutilDetector]: 1 display(s) were detected -- You are receiving this mail because: You are watching all bug changes.
[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.
[neon] [Bug 490704] Cannot mix incompatible Qt library (5.15.13) with this library (5.15.14)
https://bugs.kde.org/show_bug.cgi?id=490704 Jakob Kobberholm changed: What|Removed |Added CC||bugs.kde@jakob.kobberholm.c ||om --- Comment #8 from Jakob Kobberholm --- (In reply to Jonathan Riddell from comment #7) > Most of the package should now be fixed I can confirm after updating, VLC, KDevelop, Corectrl and QOwnNotes all launch successfully. -- 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.
