[kwin] [Bug 491916] Monitor can't understand signal after closing or minimizing an adaptive sync application
https://bugs.kde.org/show_bug.cgi?id=491916 --- Comment #7 from Wyatt Childers --- (In reply to Wyatt Childers from comment #6) > (In reply to Zamundaaa from comment #5) > > Yes, you can use kscreen-doctor for that > > Thanks; tested it out, that works flawlessly as a workaround! > > If someone else comes across this, just change your game's launch options to: > > %command% ; > > Then edit the file to contain the resolutions things should be at (no need > to toggle to something else first): > > #!/usr/bin/bash > kscreen-doctor output.HDMI-A-1.mode.3840x2160@120 > kscreen-doctor output.HDMI-A-2.mode.3840x2160@120 > > The script will run after the game exits and there might be a brief flicker > (in this case on both monitors) but all will be well. Upon extended testing, this did not work consistently and would sometimes result in a screen "flipping" every couple of seconds between what was supposed to be shown and a black screen. HOWEVER, I switched to a DisplayPort cable and that has worked without a problem ... so that's my new recommendation for anyone stumbling in here. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 491916] Monitor can't understand signal after closing or minimizing an adaptive sync application
https://bugs.kde.org/show_bug.cgi?id=491916 --- Comment #6 from Wyatt Childers --- (In reply to Zamundaaa from comment #5) > Yes, you can use kscreen-doctor for that Thanks; tested it out, that works flawlessly as a workaround! If someone else comes across this, just change your game's launch options to: %command% ; Then edit the file to contain the resolutions things should be at (no need to toggle to something else first): #!/usr/bin/bash kscreen-doctor output.HDMI-A-1.mode.3840x2160@120 kscreen-doctor output.HDMI-A-2.mode.3840x2160@120 The script will run after the game exits and there might be a brief flicker (in this case on both monitors) but all will be well. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 491916] Monitor can't understand signal after closing or minimizing an adaptive sync application
https://bugs.kde.org/show_bug.cgi?id=491916 --- Comment #4 from Wyatt Childers --- @Zamundaaa is there any kind of kwin command line I can use to tell it to change the resolution after I close an application? I'd like to wrap the application that's problematic in a bash script that just automatically sets the refresh rate to 60 and then back to 120 after the application closes so I don't have to keep doing it manually. It's a rather irritating process. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 492174] New: Adaptive Sync is deactivated when the window goes out of focus
https://bugs.kde.org/show_bug.cgi?id=492174 Bug ID: 492174 Summary: Adaptive Sync is deactivated when the window goes out of focus Classification: Plasma Product: kwin Version: 6.1.4 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwin-bugs-n...@kde.org Reporter: kdebugs.81do7@haxing.ninja Target Milestone: --- SUMMARY When in a multi-monitor setup (using automatic adaptive sync), if a full screen window goes out of focus, adaptive sync is disabled even if it remains an otherwise exclusive full screen application STEPS TO REPRODUCE 1. Put a window into full screen, ensure adaptive sync is on 2. Change the currently focused window to a window on a different monitor OBSERVED RESULT Adaptive sync is disabled for the full screen application EXPECTED RESULT Adaptive sync stays on for the full screen window SOFTWARE/OS VERSIONS Operating System: Fedora Linux 40 KDE Plasma Version: 6.1.4 KDE Frameworks Version: 6.5.0 Qt Version: 6.7.2 Kernel Version: 6.10.6-200.fc40.x86_64 (64-bit) Graphics Platform: Wayland Processors: 32 × AMD Ryzen 9 7950X 16-Core Processor Memory: 61.9 GiB of RAM Graphics Processor: AMD Radeon RX 7900 XTX Manufacturer: ASUS ADDITIONAL INFORMATION This is made slightly more annoying than "just not benefiting from adaptive sync" as (at least on my machine) there is a disruptive flicker to black whenever adaptive sync is toggled on/off. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 491916] Monitor can't understand signal after closing or minimizing an adaptive sync application
https://bugs.kde.org/show_bug.cgi?id=491916 --- Comment #3 from Wyatt Childers --- Cross-linking to the upstream issue filed: https://gitlab.freedesktop.org/drm/amd/-/issues/3572. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 491916] Monitor can't understand signal after closing or minimizing an adaptive sync application
https://bugs.kde.org/show_bug.cgi?id=491916 --- Comment #2 from Wyatt Childers --- (In reply to Zamundaaa from comment #1) > > I think what's happening here is that the application adjusts the refresh > > rate to something like 93fps just before adaptive sync is switched off. > > Then kwin is still trying to run at 93 fps (but without adaptive sync) and > > the monitor goes "I don't know what to do with this." > Sounds like a reasonable explanation, but KWin doesn't really change the > refresh rate with vrr, the driver does that behind the scenes for us; KWin > only decides whether or not it's allowed to do that. > Please report this at https://gitlab.freedesktop.org/drm/amd/-/issues I'll do that, though I'll note, it might be worth kwin "resubmitting" the refresh rate after shutting off adaptive sync to work around buggy drivers (if that's something it can do). -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 491916] New: Monitor can't understand signal after closing or minimizing an adaptive sync application
https://bugs.kde.org/show_bug.cgi?id=491916 Bug ID: 491916 Summary: Monitor can't understand signal after closing or minimizing an adaptive sync application Classification: Plasma Product: kwin Version: 6.1.4 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwin-bugs-n...@kde.org Reporter: kdebugs.81do7@haxing.ninja Target Milestone: --- SUMMARY Applications that put the monitor into adaptive sync mode when using "Automatic" adaptive sync for a particular display can cause the monitor to be unable to interpret the signal. STEPS TO REPRODUCE 1. Open an application in full screen with adaptive sync on 2. Close the application OBSERVED RESULT The application sometimes causes the monitor to report that the signal coming from the computer is unsupported. EXPECTED RESULT The monitor continues to receive a supported signal. SOFTWARE/OS VERSIONS Operating System: Fedora Linux 40 KDE Plasma Version: 6.1.4 KDE Frameworks Version: 6.5.0 Qt Version: 6.7.2 Kernel Version: 6.10.4-200.fc40.x86_64 (64-bit) Graphics Platform: Wayland Processors: 32 × AMD Ryzen 9 7950X 16-Core Processor Memory: 61.9 GiB of RAM Graphics Processor: AMD Radeon RX 7900 XTX Manufacturer: ASUS ADDITIONAL INFORMATION I think what's happening here is that the application adjusts the refresh rate to something like 93fps just before adaptive sync is switched off. Then kwin is still trying to run at 93 fps (but without adaptive sync) and the monitor goes "I don't know what to do with this." I can (as a work around) fix this by changing the monitor refresh rate in settings using my second monitor (e.g. set the refresh rate to 60 from 120; it's then okay to change it back to 120, but changing it to a different value is all that's required to get things to "sync back up" and for my monitor to understand the input again). -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 418433] App inhibitions should list what exactly they are inhibiting
https://bugs.kde.org/show_bug.cgi?id=418433 Wyatt Childers changed: What|Removed |Added CC||kdebugs.81do7@haxing.ninja --- Comment #9 from Wyatt Childers --- *** Bug 487118 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 487118] The Power Management applet displays incorrect description of effects of org.freedesktop.portal.Inhibit
https://bugs.kde.org/show_bug.cgi?id=487118 Wyatt Childers changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from Wyatt Childers --- (In reply to Nate Graham from comment #6) > You were right all along. But that bug was actually just fixed today. See > Bug 486506. > > With that fixed, I'm not sure if there's anything else to do for this issue > specifically, or if all that's left of it is covered by Bug 418433. Great! Let's assume Bug 418433 will take care of any remaining discrepancies. *** This bug has been marked as a duplicate of bug 418433 *** -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 487118] The Power Management applet displays incorrect description of effects of org.freedesktop.portal.Inhibit
https://bugs.kde.org/show_bug.cgi?id=487118 --- Comment #5 from Wyatt Childers --- (In reply to Emil from comment #4) > (In reply to Wyatt Childers from comment #3) > > (In reply to Emil from comment #1) > > > Is this not a bug in kscreenlocker? > > > > > > If I'm not mistaken the logic which correctly detects the inhibition in > > > the > > > battery monitor is here: > > > > > > https://invent.kde.org/plasma/powerdevil/-/blob/master/applets/ > > > batterymonitor/plugin/powermanagementcontrol.cpp > > > > > > But kscreensaver fails to detect that the screen has to be locked: > > > > > > https://invent.kde.org/plasma/kscreenlocker/-/blob/master/ > > > powermanagement_inhibition.cpp > > > > Does the applet depend on kscreenlocker somehow? > > No, but if I understand the bug report correctly (and how I experience it) > the applet does correctly indicate that screen locking *should* be blocked. > Which means it's a bug in kscreenlocker that should also block with > org.freedesktop.portal.Inhibit Nate Graham was quite adamant in the Bug 485376 that the power management behavior is right but the applet is wrong. I don't agree with him (https://bugs.kde.org/show_bug.cgi?id=485376#c15), but none the less I filed this bug to request that Plasma at least be consistent by displaying what it's doing. So no, this is not the bug you're looking for. You may want to leave a comment in Bug 485376. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 487118] The Power Management applet displays incorrect description of effects of org.freedesktop.portal.Inhibit
https://bugs.kde.org/show_bug.cgi?id=487118 --- Comment #3 from Wyatt Childers --- (In reply to Emil from comment #1) > Is this not a bug in kscreenlocker? > > If I'm not mistaken the logic which correctly detects the inhibition in the > battery monitor is here: > > https://invent.kde.org/plasma/powerdevil/-/blob/master/applets/ > batterymonitor/plugin/powermanagementcontrol.cpp > > But kscreensaver fails to detect that the screen has to be locked: > > https://invent.kde.org/plasma/kscreenlocker/-/blob/master/ > powermanagement_inhibition.cpp Does the applet depend on kscreenlocker somehow? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 451744] Implement toggle for "Sticky corners", preventing mouse cursor moving between monitors in corners
https://bugs.kde.org/show_bug.cgi?id=451744 --- Comment #11 from Wyatt Childers --- (In reply to miranda from comment #10) > (In reply to Wyatt Childers from comment #9) > > I was about to file a bug because it was driving me nuts that I sometimes > > couldn't move my mouse across my screens. > > > > I'm not sure where the best place is to discuss the "default" behavior here. > > However, this seems to me like an off by default accessibility option not > > run of the mill default behavior. If Windows does this by default ... that's > > nice for Windows but as a long time Linux user this behavior was shocking > > and frustrating. > > If it's about moving the mouse across edges, not shared corners, then you're > looking for #416570 and not this ticket. Good to know... It's both really. The edges were the worst part but the corners were also getting me (two firefox windows maximized, you go to move over to the first tab on the screen to the right, and you're "blocked" by an invisible wall). -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 451744] Implement toggle for "Sticky corners", preventing mouse cursor moving between monitors in corners
https://bugs.kde.org/show_bug.cgi?id=451744 Wyatt Childers changed: What|Removed |Added CC||kdebugs.81do7@haxing.ninja --- Comment #9 from Wyatt Childers --- I was about to file a bug because it was driving me nuts that I sometimes couldn't move my mouse across my screens. I'm not sure where the best place is to discuss the "default" behavior here. However, this seems to me like an off by default accessibility option not run of the mill default behavior. If Windows does this by default ... that's nice for Windows but as a long time Linux user this behavior was shocking and frustrating. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 487168] KWin 1.5x UI Scaling + 2256x1504 results in garbage pixels at the bottom of the screen
https://bugs.kde.org/show_bug.cgi?id=487168 --- Comment #2 from Wyatt Childers --- Created attachment 169587 --> https://bugs.kde.org/attachment.cgi?id=169587&action=edit a short video of the glitch on the lock screen This is an interesting one as it shows the glitch occurring with pixels that seemingly have nothing to do with anything. This isn't limited to just happening on the lock screen, but it demonstrates how weird and distracting this case be. Sometimes things move like this, sometimes they don't. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 463017] Moonlight's (SDL) power inhibit doesn't prevent screen sleep
https://bugs.kde.org/show_bug.cgi?id=463017 Wyatt Childers changed: What|Removed |Added Resolution|--- |DUPLICATE Status|REPORTED|RESOLVED --- Comment #1 from Wyatt Childers --- *** This bug has been marked as a duplicate of bug 485376 *** -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 485376] org.freedesktop.portal.Inhibit used by Flatpaked apps does not actually prevent screen locking / sleeping
https://bugs.kde.org/show_bug.cgi?id=485376 --- Comment #16 from Wyatt Childers --- *** Bug 463017 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 487168] KWin 1.5x UI Scaling + 2256x1504 results in garbage pixels at the bottom of the screen
https://bugs.kde.org/show_bug.cgi?id=487168 Wyatt Childers changed: What|Removed |Added CC||kdebugs.81do7@haxing.ninja -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 487168] KWin 1.5x UI Scaling + 2256x1504 results in garbage pixels at the bottom of the screen
https://bugs.kde.org/show_bug.cgi?id=487168 --- Comment #1 from Wyatt Childers --- Created attachment 169586 --> https://bugs.kde.org/attachment.cgi?id=169586&action=edit app icons when unlocked -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 487168] New: KWin 1.5x UI Scaling + 2256x1504 results in garbage pixels at the bottom of the screen
https://bugs.kde.org/show_bug.cgi?id=487168 Bug ID: 487168 Summary: KWin 1.5x UI Scaling + 2256x1504 results in garbage pixels at the bottom of the screen Classification: Plasma Product: kwin Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: core Assignee: kwin-bugs-n...@kde.org Reporter: kdebugs.81do7@haxing.ninja Target Milestone: --- Created attachment 169585 --> https://bugs.kde.org/attachment.cgi?id=169585&action=edit pixels on the lock screen that don't belong SUMMARY On my Framework 13" I've noticed the bottom row of pixels is occasionally "garbage" like it isn't properly being used by either Plasma or Kwin. This effect carries over to the lock screen where some of the blue outline from the Icon Only task Manager can still be seen (see the attached screen shots). REPRODUCTION I believe to reproduce this you need a 2256x1504 (such as the one used by the framework, and a 1.5x scaling factor). When I turned off scaling, I could no longer see the buggy pixels. Enabling scaling again lead me to see the bottom row of pixels from the 1.0x scale factor (tiny status icons) at the bottom of the lock screen. SOFTWARE/OS VERSIONS Operating System: Fedora Linux 40 KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.1.0 Qt Version: 6.7.0 Kernel Version: 6.5.6-300.fc39.x86_64 (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 7840U w/ Radeon 780M Graphics Memory: 14.9 GiB of RAM Graphics Processor: AMD Radeon Graphics Manufacturer: Framework Product Name: Laptop 13 (AMD Ryzen 7040Series) System Version: A7 ADDITIONAL INFORMATION This is similar to Bug 460896 but I believe it's different (related to KWin's scaling). -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 485376] org.freedesktop.portal.Inhibit used by Flatpaked apps does not actually prevent screen locking / sleeping
https://bugs.kde.org/show_bug.cgi?id=485376 --- Comment #15 from Wyatt Childers --- I in looking at this a little closer do think this is actually the real bug though (not the display). https://github.com/flatpak/xdg-desktop-portal/commit/f57ed505719f7371496c1b0b843d46e160bd6253 > This lets sandboxed apps inhibit session status changes, such as suspend or > idle. This is the API that lets movie players prevent the screensaver from > kicking in halfway through the movie. org.freedesktop.portal.Inhibit was pretty clearly intended to affect the Screen Saver -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 487118] The Power Management applet displays incorrect description of effects of org.freedesktop.portal.Inhibit
https://bugs.kde.org/show_bug.cgi?id=487118 Wyatt Childers changed: What|Removed |Added Summary|The Power Management applet |The Power Management applet |displays|displays incorrect ||description of effects of ||org.freedesktop.portal.Inhi ||bit -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 487118] The Power Management applet displays
https://bugs.kde.org/show_bug.cgi?id=487118 Wyatt Childers changed: What|Removed |Added CC||kdebugs.81do7@haxing.ninja -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 485376] org.freedesktop.portal.Inhibit used by Flatpaked apps does not actually prevent screen locking / sleeping
https://bugs.kde.org/show_bug.cgi?id=485376 --- Comment #14 from Wyatt Childers --- Bug 487118 filed. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 487118] New: The Power Management applet displays
https://bugs.kde.org/show_bug.cgi?id=487118 Bug ID: 487118 Summary: The Power Management applet displays Classification: Plasma Product: Powerdevil Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: kdebugs.81do7@haxing.ninja CC: m...@ratijas.tk, natalie_clar...@yahoo.de Target Milestone: --- SUMMARY The Plasma Power Management applet incorrectly displays that sleep and screen locking are disabled when org.freedesktop.portal.Inhibit is used. STEPS TO REPRODUCE 1. Run an affected application like Firefox or Moonlight that send only org.freedesktop.portal.Inhibit and not org.freedesktop.ScreenSaver OBSERVED RESULT The UI reports that sleep and screen locking is blocked. EXPECTED RESULT The UI reports that sleep is blocked/the description of what's blocked is accurate (as Plasma does not block screen locking without org.freedesktop.ScreenSaver). SOFTWARE/OS VERSIONS Operating System: Fedora Linux 40 KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.0 Kernel Version: 6.8.9-300.fc40.x86_64 (64-bit) Graphics Platform: Wayland Processors: 32 × AMD Ryzen 9 7950X 16-Core Processor Memory: 61.9 GiB of RAM Graphics Processor: AMD Radeon RX 6700 XT Manufacturer: ASUS ADDITIONAL INFORMATION See Bug 485376 for some prior conversation. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 485376] org.freedesktop.portal.Inhibit used by Flatpaked apps does not actually prevent screen locking / sleeping
https://bugs.kde.org/show_bug.cgi?id=485376 --- Comment #12 from Wyatt Childers --- (In reply to Nate Graham from comment #9) > If adding a permission in the Flatpak packaging fixes the bug that power > management isn't inhibited correctly, then the bug is caused by incorrect > Flatpak packaging. > > There may also be an opportunity to clean something up on our side such that > when that permission is missing, the Power & Battery widget won't even show > the false inhibition notice in the first place. That would be a separate > issue. I'll leave it up to Natalie and Jakob as to whether they think that's > worth doing. The latter part is what I'm referring to. I likely would have figured this out in Bug 433452 (way back in 2021) if Plasma was actually telling the truth about the situation. Instead, Plasma said that it was doing something that it clearly wasn't and we've had annoying packaging bugs in the ecosystem for AT LEAST 3 YEARS. This is FAR from the first time I've been incredibly frustrated with KDE's power management reporting and documentation. I had to do all the grunt work several years ago communicating with the Plex team to get Plex to work with Plasma's power management https://forums.plex.tv/t/linux-flatpak-player-doesnt-inhibit-power-management/804528. > What you describe next is a different issue: Bug 328987. It is but it also isn't because SDL (powering moonlight under the hood) is actively trying to stop the screen saver from working. Plasma is reporting that it's succeeding at that, and it fails anyways. The SDL code is seemingly even capable of using org.freedesktop.ScreenSaver but seemingly neglects to use that code path if Inhibit succeeds: https://github.com/libsdl-org/SDL/blob/17965117824d82afd0f6692c8871510f942270f7/src/core/linux/SDL_dbus.c#L367 https://github.com/libsdl-org/SDL/blob/17965117824d82afd0f6692c8871510f942270f7/src/core/linux/SDL_dbus.c#L460 Multiple major developers are clearly genuinely being confused about what signal they need to be sending for the behavior they want. How Plasma responds to Inhibit, both in the UI and power management side is surely entirely within its control. This is no different to me than if Dolphin said it deleted a file but the file is still in the directory. I'm grateful for all the work various people in this community do, but can we please accept there's a *real* bug here and that the Plasma UI should not actively lie about the behavior of its own power management system? -- You are receiving this mail because: You are watching all bug changes.
[xdg-desktop-portal-kde] [Bug 485376] org.freedesktop.portal.Inhibit used by Flatpaked apps does not actually prevent screen locking / sleeping
https://bugs.kde.org/show_bug.cgi?id=485376 --- Comment #8 from Wyatt Childers --- Also, this is not just a Firefox thing, this affects other things like Moonlight. It's been a very frustrating experience trying to play a game with a controller and then having the screen shut off because the controller doesn't count as activity and the "Moonlight is currently blocking sleep and screen locking (Playing a game)" message in KDE's UI is a lie. -- You are receiving this mail because: You are watching all bug changes.
[xdg-desktop-portal-kde] [Bug 485376] org.freedesktop.portal.Inhibit used by Flatpaked apps does not actually prevent screen locking / sleeping
https://bugs.kde.org/show_bug.cgi?id=485376 --- Comment #7 from Wyatt Childers --- (In reply to Nate Graham from comment #4) > That makes this a packaging bug in Firefox's Flatpak manifest. Can you > report this upstream, or submit a patch? See > https://github.com/flathub/org.mozilla.firefox.BaseApp/pulls I disagree with this perspective. > - The battery and brightness applet displays a message, that firefox prevents > screen lock > - The screen locks anyway If KDE says in its UI "Firefox Web Browser is currently blocking sleep and screen locking (video-playing)" (**and it does**), it /should be/ suppressing power management. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 433452] Power management ignores sleep and screen locking suppression
https://bugs.kde.org/show_bug.cgi?id=433452 --- Comment #11 from Wyatt Childers --- Too add extra context, I see this with firefox and moonlight. Maybe it's just anything coming from a flatpak is reported in the UI but doesn't actually affect anything. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 433627] Battery and Brightness doesn't report all power suppressions
https://bugs.kde.org/show_bug.cgi?id=433627 --- Comment #7 from Wyatt Childers --- (In reply to TraceyC from comment #6) > It's been a while since there was any update on this. Has the issue been > resolved, or is it still a problem? I no longer use Elisa; I do not know if this is still a problem. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 433452] Power management ignores sleep and screen locking suppression
https://bugs.kde.org/show_bug.cgi?id=433452 --- Comment #10 from Wyatt Childers --- (In reply to TraceyC from comment #9) > Thank you for the bug report. It's been a while since this was last updated. > Did you file the issue with the Elisa project? Has the issue been fixed or > is there still a problem? Yes, on an almost daily basis. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 465361] Make active color scheme change when global theme changes
https://bugs.kde.org/show_bug.cgi?id=465361 --- Comment #2 from Wyatt Childers --- I would also like to see this. Konsole stands out as one of the few apps that doesn't switch all of its theming. The simplest conceptual way to do this (I think) would be to have the "Appearance" -> "Color scheme & font" page allow selection of a "light" and "dark" theme color scheme. If someone wants to use the same color scheme for both, they can just pick the same color scheme for both (since there's already this concept of named color schemes). -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 465361] Make active color scheme change when global theme changes
https://bugs.kde.org/show_bug.cgi?id=465361 Wyatt Childers changed: What|Removed |Added CC||kdebugs.81do7@haxing.ninja -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 343690] Missing windows tabbing
https://bugs.kde.org/show_bug.cgi?id=343690 --- Comment #37 from Wyatt Childers --- (In reply to Maximilian Böhm from comment #36) > Concept for tabbing mixed SSD and CSD windows: You initiate window merging > via shortcut or taskbar option, then select a second (and third…) window. > Plasma windows without CSD get regularly tabbed, CSD windows get an extra > title bar to be tabbed. The title bar disappears after dissolving the window > tabbing. I agree, I don't see why this would be undesirable at all... In fact I think this is exactly how tiling window managers go about resolving this issue. -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 473221] Add Kagi to the default search engines
https://bugs.kde.org/show_bug.cgi?id=473221 --- Comment #8 from Wyatt Childers --- Just to respond to the comments raised... > I'm not passing any judgment on Kagi and I don't have anything against paid > products, but I'm worrying about what will happen if a user uses this entry > without having paid for a kagi.com account. I don't think it would result in > a very good UX. My concern is preventing problems stemming from that. I'd ask yourself what UX _would be_ acceptable. Kagi shows a login page, if you sign into your account, it continues the search. I don't know how you could get better UX for what the product is, or why that would be user hostile or confusing. In a sense, I think it's the predominance of Google and its decades long dominance of the search industry that's created an unfair expectation. > Having some providers preferred or not thus doesn't make a difference for > default setups. This isn't about being preferred, it's about being _included at all_. The current status quo is if you're a user of Kagi, you must be technically proficient enough to understand URLs and how to add the URL to KDE's search system. ... I'm not going to continue the fight; I ultimately don't think it's worth it at this point. You guys do great work, and it's not my intent to badger you guys into doing something you don't want to do ... but I will "go on the record" and say, I think you're getting this one wrong. -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 473297] New: Ask Jeeves Provider is Broken
https://bugs.kde.org/show_bug.cgi?id=473297 Bug ID: 473297 Summary: Ask Jeeves Provider is Broken Classification: Plasma Product: krunner Version: 5.27.7 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: webshortcuts Assignee: plasma-b...@kde.org Reporter: kdebugs.81do7@haxing.ninja CC: alexander.loh...@gmx.de, natalie_clar...@yahoo.de Target Milestone: --- SUMMARY Currently using "ask: test" results in reaching a broken page: https://www.ask.com/main/askJeeves.asp?origin=0&qSource=4&site_name=Jeeves&metasearch=yes&ask=test It should be: https://www.ask.com/web?q=test -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 473221] Add Kagi to the default search engines
https://bugs.kde.org/show_bug.cgi?id=473221 --- Comment #4 from Wyatt Childers --- (In reply to Alexander Lohnau from comment #3) > All the other search engines are freely available. IMHO we should not add a > paid to the ones we ship by default. > > This again raises the question if we should have a sharing feature for > engines. Then the few people who have a paid account there can easily add it > to KRunner/other KDE components making use of webshortcuts. I realize KDE's user base is (in the scope of things) very small and is unlikely to have a much of an impact, but an unwillingness to add a search provider (that IMO is in many ways is more closely aligned with free software ethos than say, Google) feels very much like picking winners. https://kde.org/for/activists/ - "We actually care about data privacy and digital well-being, and we fight for them." https://help.kagi.com/kagi/getting-started/faqs.html#what-is-kagi - "Kagi is currently Kagi Search, a fast, private search engine", "Kagi is a company created with the mission to humanize the web. Our goal is amplify the web of human knowledge, creativity and self-expression and provide the user tools to fight against the web of greed, ad-tech and user tracking." I really don't think this needs to be controversial. If people don't want to use it, they won't. It's easier on folks that do (or may want to use it but haven't heard of it) if it's "just there" though. IMO FOSS ethics are not anti-paid software, there's no conflict on interest here, particularly when *no* search provider shipped in KDE's defaults is actually a FOSS option. -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 473221] Add Kagi to the default search engines
https://bugs.kde.org/show_bug.cgi?id=473221 --- Comment #2 from Wyatt Childers --- (In reply to Nate Graham from comment #1) > Isn't kagi.com a paid search engine? As such, it wouldn't work for people > who haven't paid for it, right? Yes, and yes. That said, (assuming you're going with that being a bad thing); I don't know that that should exclude it from being listed, it shouldn't be the default but I think it's fine to be listed. The "free" (as in beer) search engines arguably aren't truly free, you just pay with your privacy rather than directly dollars. Some like the amazon web search options are also clearly biased towards selling things at one (major) retailer. -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 473221] New: Add Kagi to the default search engines
https://bugs.kde.org/show_bug.cgi?id=473221 Bug ID: 473221 Summary: Add Kagi to the default search engines Classification: Plasma Product: krunner Version: 5.27.7 Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: webshortcuts Assignee: plasma-b...@kde.org Reporter: kdebugs.81do7@haxing.ninja CC: alexander.loh...@gmx.de, natalie_clar...@yahoo.de Target Milestone: --- SUMMARY Kagi is an up and coming independent search engine https://help.kagi.com/kagi/company/. It would be nice to have this in the default search providers. I propose, "kg" for the shortcut, and "https://kagi.com/search?q=\{@}"; for the shortcut URL. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 432053] Nvidia Wayland - High CPU Usage
https://bugs.kde.org/show_bug.cgi?id=432053 --- Comment #8 from Wyatt Childers --- (In reply to Nate Graham from comment #5) > >- kms_swrast_dri.so (repeated x 5 times) at 99.3% CPU > > swrast or "software rasterizer" is a fallback when drivers are unable to be > loaded properly. This indicates a setup issue. Use of the right driver will > make a big difference. > > Wyatt, can you see if this fixes the issue for you too? So Nate, I don't have this card anymore, I gave it to a friend... who also has this problem... I sent him the NEEDSINFO/this bug, but he hasn't really followed up on this. I think it would be useful if there were steps shared about how to identify the issue and how this setup issue might happen. As it stands, working Nvidia Proprietary Fedora drivers under Fedora KDE X11 result in this issue under Fedora KDE Wayland (on at least the two systems this card has been used in). -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 449163] Plasma panel visually freezes after some time under Wayland
https://bugs.kde.org/show_bug.cgi?id=449163 Wyatt Childers changed: What|Removed |Added CC|kdebugs.81do7@haxing.ninja | -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 343690] Missing windows tabbing
https://bugs.kde.org/show_bug.cgi?id=343690 Wyatt Childers changed: What|Removed |Added CC||kdebugs.81do7@haxing.ninja --- Comment #31 from Wyatt Childers --- I'd like to advocate that this feature could pair very well with the new Kwin tiling. There could be a default, or optional setting, where if you shift drag a window over another window, they automatically tab together. Similarly, a shift drag from the tab would pull the window out of the tab group, and allow it to be made an independent window or allow it to be dragged into another tab group. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 468129] Display window icon from app's .desktop file if no icon was set by the window
https://bugs.kde.org/show_bug.cgi?id=468129 --- Comment #7 from Wyatt Childers --- (In reply to Nicolas Fella from comment #6) > Nate, I'm afraid you are mistaken. > > On Wayland there is no concept of a window icon. The icon you see for > Wayland apps *always* comes from the desktop file. Now why are some icons > missing? This happens when the desktop file name reported by the app doesn't > match the actual desktop file on disk. Plasma has some extra code that tries > to fix up these broken apps that kwin doesn't have, which is why some apps > have icons in Plasma but not in KWin Perhaps that logic could be moved into one of the KDE frameworks, and then shared between Plasma and Kwin so things are always consistent? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 468129] Flatpak window icons are wrong
https://bugs.kde.org/show_bug.cgi?id=468129 --- Comment #4 from Wyatt Childers --- (In reply to Nate Graham from comment #3) > The issue is that KWin is a window manager and gets its window icons from > the window. So the window has to *have* an icon for KWin to display. The > Task Manager, on the other hand looks in the app's desktop file to get the > icon. KWin theoretically could do this too, so you're not wrong that it's an > ideological stance on the part of the KWin developers. The thing is, always > using the .desktop file icon would mean that if the window did set its own > icon, KWin would discard it, ignoring the wishes of the developer. KWin > could do it only when the window doesn't set its own window icon, maybe. But > this could seem random to the user. I think it would be completely sensible to fallback to the desktop file when the application has not set an icon. If a window sets an icon that's great, and sure it should be used. However, if a window fails to set an icon, I think it's far more shocking that a "wayland" or "x11" icon is used, meanwhile KDE (as a whole) clearly sees a much more optimal answer provided by the desktop file. i.e., I'd argue the rule should be: 1. Use what the window set 2. Use what the desktop set 3. Use a fallback icon for Wayland/X11 (as a last resort) #2 is always going to be far more user relevant than #3. In terms of UX, I think the most compelling use case is that, as it stands, if this bug is exhibited by a handful of currently open applications the icon only task switcher is rendered borderline useless. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 468129] Flatpak window icons are wrong
https://bugs.kde.org/show_bug.cgi?id=468129 --- Comment #2 from Wyatt Childers --- (In reply to Nate Graham from comment #1) > On Wayland, these are unfortunately application bugs. You'll need to report > them to the apps themselves. Perhaps this is an ideological stance on the Kwin side, but it seems quite contrary to what seems like "common sense" (i.e., that if Plasma can figure out the application icon, Kwin could figure out the icon)? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 468129] New: Flatpak window icons are wrong
https://bugs.kde.org/show_bug.cgi?id=468129 Bug ID: 468129 Summary: Flatpak window icons are wrong Classification: Plasma Product: kwin Version: 5.27.3 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: core Assignee: kwin-bugs-n...@kde.org Reporter: kdebugs.81do7@haxing.ninja Target Milestone: --- SUMMARY The flatpak icon is displayed incorrectly on window frames (however it's displayed correctly in the Plasma Shell Task Manager widgets. STEPS TO REPRODUCE 1. Install a flatpak like Rhythmbox 2. Open Rhythmbox OBSERVED RESULT Plasma Shell's Task Manager widget shows the Rhythmbox icon. EXPECTED RESULT The Rhythmbox window shows a generic Wayland application icon. SOFTWARE/OS VERSIONS Operating System: Fedora Linux 37 KDE Plasma Version: 5.27.3 KDE Frameworks Version: 5.104.0 Qt Version: 5.15.8 Kernel Version: 6.2.8-200.fc37.x86_64 (64-bit) Graphics Platform: Wayland Processors: 32 × AMD Ryzen 9 7950X 16-Core Processor Memory: 61.9 GiB of RAM Graphics Processor: AMD Radeon RX 6700 XT Manufacturer: ASUS ADDITIONAL INFORMATION This also happens with things like Slack or Discord, except they display the generic X11 application icon. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 463356] Audio indicators are displayed for some flatpaks that aren't running audio
https://bugs.kde.org/show_bug.cgi?id=463356 --- Comment #6 from Wyatt Childers --- Yeah I'm still seeing this as well, with the Signal flatpak showing an audio indicator with Plex -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 466028] Upgrading to KDE 5.27 resulted in older version of desktop
https://bugs.kde.org/show_bug.cgi?id=466028 --- Comment #4 from Wyatt Childers --- (In reply to Nate Graham from comment #3) > Thanks for the offer. Unfortunately it doesn't really help as the old state > is inherently non-determinstic. That's why stuff was so bad before, > especially with 3+ screens or a frequently-changing screen arrangement. The odd thing is, I was/am on a desktop, and never had any issues with the old way doing anything surprising; i.e., for me anyways it was very deterministic. Maybe this isn't the case, but because of that, it seems like the migration script should be able to handle this equally as well, no? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 466028] Upgrading to KDE 5.27 resulted in older version of desktop
https://bugs.kde.org/show_bug.cgi?id=466028 --- Comment #2 from Wyatt Childers --- (In reply to Nate Graham from comment #1) > So in Plasma 5.27, we moved to a totally new multi-monitor system, which > also entailed changing how monitors are bound to desktops. We added > migration code to make it as seamless as possible, but unfortunately, due to > how broken the previous system was, it's not possible for the migration code > to handle everything perfectly, especially if the previous config data was > in a weird or inconsistent state. Evidently in your case the migration code > did not do the right thing. Sorry about that. > > Can you find your missing desktop in the Manage Desktop and Panels window? > > You access it by entering edit mode on the desktop and clicking on the > "Manage Desktop and Panels" button in the toolbar that pops down from the > top of the screen. Aha! I had no idea about this fancy "Manage Desktop and Panels" system; that's very neat! Yes, I was able to find it there; thank you! I'm not sure if there's anything we could do to make the migration code better (for other fokls)? I *might* have the old state in a restic/could pull out some information (though I don't know where all of this is stored). -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 463353] Hang in KIconTheme update
https://bugs.kde.org/show_bug.cgi?id=463353 --- Comment #33 from Wyatt Childers --- Cross posting here that if you're seeing this problem and your IO scheduler is "bfq", as a workaround you can switch to "kyber", "none", or "mq-deadline". This should resolve most of the issue until you have 5.103 in your distro (and possibly some other issues you may be experiencing). Pop!_OS uses kyber, and I've seen much better results with it than "mq-deadline" personally; none was also very promising in my testing but I've opted for following what Pop!_OS did. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 466031] New: Custom tiling is applied across virtual desktops
https://bugs.kde.org/show_bug.cgi?id=466031 Bug ID: 466031 Summary: Custom tiling is applied across virtual desktops Classification: Plasma Product: kwin Version: 5.27.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Custom Tiling Assignee: kwin-bugs-n...@kde.org Reporter: kdebugs.81do7@haxing.ninja CC: notm...@gmail.com Target Milestone: --- SUMMARY The new tiling feature is really cool, but current it has a major flaw in that it applies the same tiling rules to all virtual desktops. STEPS TO REPRODUCE 1. Arrange some windows on Virtual Desktop 1 with custom tiling 2. Arrange some windows on Virtual Desktop 2 with custom tiling and a different layout OBSERVED RESULT Virtual Desktop 1's layout is affected by the changes made to Virtual Desktop 2. EXPECTED RESULT Virtual Desktop 1 is unaffected by the changes made to Virtual Desktop 2. SOFTWARE/OS VERSIONS Operating System: Fedora Linux 37 KDE Plasma Version: 5.27.0 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 Kernel Version: 6.1.11-200.fc37.x86_64 (64-bit) Graphics Platform: Wayland Processors: 32 × AMD Ryzen 9 7950X 16-Core Processor Memory: 62.0 GiB of RAM Graphics Processor: AMD Radeon RX 6700 XT Manufacturer: ASUS ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 466030] Dolphin is repainting the file list incorrectly and very slowly
https://bugs.kde.org/show_bug.cgi?id=466030 --- Comment #1 from Wyatt Childers --- Created attachment 156459 --> https://bugs.kde.org/attachment.cgi?id=156459&action=edit Video of problem -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 466030] New: Dolphin is repainting the file list incorrectly and very slowly
https://bugs.kde.org/show_bug.cgi?id=466030 Bug ID: 466030 Summary: Dolphin is repainting the file list incorrectly and very slowly Classification: Applications Product: dolphin Version: 22.12.2 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: major Priority: NOR Component: general Assignee: dolphin-bugs-n...@kde.org Reporter: kdebugs.81do7@haxing.ninja CC: kfm-de...@kde.org Target Milestone: --- SUMMARY After updating to 22.12.2, Dolphin now repairs the "list" view very slowly, and in some cases not at all. STEPS TO REPRODUCE 1. Open a directory like "/usr/share/plasma/shells/org.kde.plasma.desktop/contents/configuration/" 2. Click "panelconfiguration" OBSERVED RESULT Some items stick around from the "configuration" directory when displaying "panelconfiguration". EXPECTED RESULT Only items in "panelconfiguration" are displayed. SOFTWARE/OS VERSIONS Operating System: Fedora Linux 37 KDE Plasma Version: 5.27.0 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 Kernel Version: 6.1.11-200.fc37.x86_64 (64-bit) Graphics Platform: Wayland Processors: 32 × AMD Ryzen 9 7950X 16-Core Processor Memory: 62.0 GiB of RAM Graphics Processor: AMD Radeon RX 6700 XT Manufacturer: ASUS ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 466028] Upgrading to KDE 5.27 resulted in older version of desktop
https://bugs.kde.org/show_bug.cgi?id=466028 Wyatt Childers changed: What|Removed |Added Platform|Other |Fedora RPMs -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 466028] New: Upgrading to KDE 5.27 resulted in older version of desktop
https://bugs.kde.org/show_bug.cgi?id=466028 Bug ID: 466028 Summary: Upgrading to KDE 5.27 resulted in older version of desktop Classification: Plasma Product: plasmashell Version: 5.27.0 Platform: Other OS: Linux Status: REPORTED Severity: critical Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: kdebugs.81do7@haxing.ninja CC: k...@davidedmundson.co.uk Target Milestone: 1.0 SUMMARY When I updated my computer to 5.27, it reset my plasma layout to a layout I haven't had for months. Basically all my panel customizations since then have been reverted. SOFTWARE/OS VERSIONS Operating System: Fedora Linux 37 KDE Plasma Version: 5.27.0 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 Kernel Version: 6.1.11-200.fc37.x86_64 (64-bit) Graphics Platform: Wayland Processors: 32 × AMD Ryzen 9 7950X 16-Core Processor Memory: 62.0 GiB of RAM Graphics Processor: AMD Radeon RX 6700 XT Manufacturer: ASUS ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 463353] Hang in KIconTheme update
https://bugs.kde.org/show_bug.cgi?id=463353 --- Comment #28 from Wyatt Childers --- So, as an update to this, I've filed an upstream kernel bug against btrfs (https://bugzilla.kernel.org/show_bug.cgi?id=216961). As the original reporter (and someone who has observed several other hangs related to with btrfs), I believe at least a major factor is a regression in Kernel 6.0 with btrfs's scheduling. I think ideally, kwin shouldn't directly do much of anything that blocks on IO (as slower drives and bugs of this nature can severely impact user experience), so this should still be fixed. However, it definitely seems to be exacerbated by the severity of extremely long periods of disk sleep for "trivial" IO operations. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 463353] Kwin freezes while the system is updated
https://bugs.kde.org/show_bug.cgi?id=463353 --- Comment #10 from Wyatt Childers --- @Ross and @yiz...@kulodgei.com are you both using btrfs as well, or different file systems? I've notice an increase in "wonky" IO scheduler behavior lately in general, use btrfs almost exclusively, and wonder if that's related. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 463353] Kwin freezes while the system is updated
https://bugs.kde.org/show_bug.cgi?id=463353 --- Comment #9 from Wyatt Childers --- I updated the title to better reflect the issue is not limited to just flatpaks. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 463353] Kwin freezes while the system is updated
https://bugs.kde.org/show_bug.cgi?id=463353 Wyatt Childers changed: What|Removed |Added Summary|Kwin freezes while flatpaks |Kwin freezes while the |are updated |system is updated -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 463353] Kwin freezes while flatpaks are updated
https://bugs.kde.org/show_bug.cgi?id=463353 --- Comment #8 from Wyatt Childers --- I don't use Konsole, so it's not that (Alacritty + Tmux). I also observed this during the "verify" stage of some standard DNF updates, but only some updates. I _think_ mesa and/or the kernel was included in that update, but I can't recall specifically... I'll try to do better on the next occurrence figuring out which package is being updated. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 463353] Kwin freezes while flatpaks are updated
https://bugs.kde.org/show_bug.cgi?id=463353 --- Comment #5 from Wyatt Childers --- I think I should further clarify on second thought. To my latter theory, kwin would be trying to write/read something from disk itself and waiting on that... It seems quite a bit less likely that's the case, as even a slow hard drive would then be able to recreate these conditions/impact user input. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 463353] Kwin freezes while flatpaks are updated
https://bugs.kde.org/show_bug.cgi?id=463353 --- Comment #4 from Wyatt Childers --- I will say I did botch the expected result, though I think "kwin should continue to respond to user input" is inferable. My personal theory is that when flatpak updates the runtimes, if one of the apps dependent on the runtime is running (maybe even if not?) Kwin gets into a situation where it's blocked waiting on something from the flatpak app (perhaps even Xwayland running in the sandbox) to respond (i.e. an operation which normally would be almost instant, that waiting on is normally totally fine, but during this update is blocked waiting on some part of the update). My other theory is that perhaps the btrfs kernel IO scheduler is doing something funny. I've had some tests that normally run at subsecond take over a minute when lots of other tests running IO operations are occurring because the ioscheduler was just not queuing their operations. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 463353] Kwin freezes while flatpaks are updated
https://bugs.kde.org/show_bug.cgi?id=463353 Wyatt Childers changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|NOT A BUG |--- Ever confirmed|0 |1 --- Comment #3 from Wyatt Childers --- That's completely bogus. The computer is not even remotely under load. "Processors: 32 × AMD Ryzen 9 7950X 16-Core Processor" This is not a "performance issue" it's a complete lockup of the window manager which doesn't happen when I run literally thousands of tests on the same computer pegging all cores at 100%. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 463356] New: Audio indicators are displayed for some flatpaks that aren't running audio
https://bugs.kde.org/show_bug.cgi?id=463356 Bug ID: 463356 Summary: Audio indicators are displayed for some flatpaks that aren't running audio Classification: Plasma Product: plasmashell Version: 5.26.4 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Task Manager and Icons-Only Task Manager Assignee: plasma-b...@kde.org Reporter: kdebugs.81do7@haxing.ninja Target Milestone: 1.0 SUMMARY Some flatpak apps erroneously share audio indicator and volume adjustment with a flatpak playing music. STEPS TO REPRODUCE 1. Open (as flatpaks) Rhythmbox, Slack, Telegram, and Signal 2. Play some music on Rhythmbox OBSERVED RESULT Rhythmbox, Slack, and Signal show audio indicators and share a volume slider. EXPECTED RESULT Only Rhythmbox shows an audio indicator and volume slider. SOFTWARE/OS VERSIONS Operating System: Fedora Linux 37 KDE Plasma Version: 5.26.4 KDE Frameworks Version: 5.101.0 Qt Version: 5.15.7 Kernel Version: 6.0.12-300.fc37.x86_64 (64-bit) Graphics Platform: Wayland Processors: 32 × AMD Ryzen 9 7950X 16-Core Processor Memory: 62.0 GiB of RAM Graphics Processor: AMD Radeon RX 6700 XT Manufacturer: ASUS ADDITIONAL INFORMATION The track skipping and pause options are interestingly not shared. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 463353] New: Kwin freezes while flatpaks are updated
https://bugs.kde.org/show_bug.cgi?id=463353 Bug ID: 463353 Summary: Kwin freezes while flatpaks are updated Classification: Plasma Product: kwin Version: 5.26.4 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: major Priority: NOR Component: wayland-generic Assignee: kwin-bugs-n...@kde.org Reporter: kdebugs.81do7@haxing.ninja Target Milestone: --- SUMMARY Today while updating several flatpaks via discover, I noticed Kwin freezing (i.e., windows would not switch via keyboard shortcuts, the mouse wouldn't move, etc). This happened at various points in the update, and once it was completed everything went back to normal STEPS TO REPRODUCE 1. Update flatpaks via discover 2. Attempt to move mouse while updates process OBSERVED RESULT Kwin stops responding to user input. EXPECTED RESULT Kwin becomes unresponsive to user input. SOFTWARE/OS VERSIONS Operating System: Fedora Linux 37 KDE Plasma Version: 5.26.4 KDE Frameworks Version: 5.101.0 Qt Version: 5.15.7 Kernel Version: 6.0.12-300.fc37.x86_64 (64-bit) Graphics Platform: Wayland Processors: 32 × AMD Ryzen 9 7950X 16-Core Processor Memory: 62.0 GiB of RAM Graphics Processor: AMD Radeon RX 6700 XT Manufacturer: ASUS ADDITIONAL INFORMATION This was during a FreeDesktop SDK update, so this was a "heavier" flatpak update than normal, and I *think* it was ultimately this update occurring (likely while having flatpaks running -- including Discord, Telegram, Todoist, Rhythmbox, and Slack) that caused the issue. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 463017] New: Moonlight's (SDL) power inhibit doesn't prevent screen sleep
https://bugs.kde.org/show_bug.cgi?id=463017 Bug ID: 463017 Summary: Moonlight's (SDL) power inhibit doesn't prevent screen sleep Classification: Plasma Product: Powerdevil Version: 5.26.4 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: kdebugs.81do7@haxing.ninja CC: m...@ratijas.tk Target Milestone: --- SUMMARY Moonlight while playing a game sends inhibition signals to prevent monitor sleep (which is reported by power management in the status tray), however, if playing a game with a controller, monitors go to sleep. STEPS TO REPRODUCE 1. Open moonlight 2. Play a game on a remote PC using a controller OBSERVED RESULT The monitors go to sleep as if no activity has been detected. EXPECTED RESULT The monitors stay on. SOFTWARE/OS VERSIONS Operating System: Fedora Linux 37 KDE Plasma Version: 5.26.4 KDE Frameworks Version: 5.100.0 Qt Version: 5.15.7 Kernel Version: 6.0.11-300.fc37.x86_64 (64-bit) Graphics Platform: Wayland Processors: 32 × AMD Ryzen 9 7950X 16-Core Processor Memory: 62.0 GiB of RAM Graphics Processor: AMD Radeon RX 6700 XT Manufacturer: ASUS ADDITIONAL INFORMATION I *think* this started with 5.26, but I can't be sure. Moonlight requires two computers, so this might be hard to test. It's probably better to do whatever they're doing which appears to be power inhibition via SDL https://github.com/moonlight-stream/moonlight-qt/blob/411998d4e39f11ce6d3d8fc60657b699b19d5dd1/app/streaming/session.cpp#L1575 -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 462722] New: Add support for search "keywords" for each search plugin
https://bugs.kde.org/show_bug.cgi?id=462722 Bug ID: 462722 Summary: Add support for search "keywords" for each search plugin Classification: Plasma Product: krunner Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: kdebugs.81do7@haxing.ninja CC: alexander.loh...@gmx.de Target Milestone: --- SUMMARY Firefox has a feature where a keyword can be assigned to different search engines. Over in bug 340283 there's a lot of debate about search order, however, I think the user often knows what kind of thing they're searching for. I think some of the need to "get result priority right" would be alleviated, and it would be generally useful, if the user could say something like "%w firefox" to prioritize open Firefox windows (i.e., open windows), and "%a firefox" to prioritize launching Firefox (i.e., app launchers). The Firefox search settings, behavior, and default keywords could be used as an inspiration for a potential UI/UX for this. -- You are receiving this mail because: You are watching all bug changes.
[yakuake] [Bug 462456] New: Clipboard is not read
https://bugs.kde.org/show_bug.cgi?id=462456 Bug ID: 462456 Summary: Clipboard is not read Classification: Applications Product: yakuake Version: 22.08.3 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: h...@kde.org Reporter: kdebugs.81do7@haxing.ninja Target Milestone: --- SUMMARY There's a bug somewhere where Yakuake (or some other underlying component) stops reading updates to the clipboard until some text inside of Yakuake is copied. I wish I had reproduction steps but effectively what happens is "something" and then I can copy text a million times in emacs, other applications like Firefox and Telegram will see the text update, but when I paste in Yakuake it's an old clipboard entry. If you select some text in Yakuake and copy it that seems to "reset" things. You can then go back to emacs, and copy the desired text where upon returning to Yakuake it will paste successfully. It's exceptionally strange, and it's similar to some other weird clipboard things I've seen on KDE over the years, though this is the only one I've seen in recent memory (perhaps since switching to Wayland I think a year or so ago). SOFTWARE/OS VERSIONS Operating System: Fedora Linux 37 KDE Plasma Version: 5.26.3 KDE Frameworks Version: 5.100.0 Qt Version: 5.15.7 Kernel Version: 6.0.9-300.fc37.x86_64 (64-bit) Graphics Platform: Wayland Processors: 32 × AMD Ryzen 9 7950X 16-Core Processor Memory: 62.0 GiB of RAM Graphics Processor: AMD Radeon RX 6700 XT Manufacturer: ASUS -- You are receiving this mail because: You are watching all bug changes.
[xdg-desktop-portal-kde] [Bug 462283] xdg-desktop-portal-kde notification produces sound
https://bugs.kde.org/show_bug.cgi?id=462283 --- Comment #3 from Wyatt Childers --- A workaround was given by a Telegram contributor here: https://github.com/telegramdesktop/tdesktop/issues/25469#issuecomment-1329483514 sudo sed -i 's/org.freedesktop.impl.portal.Notification;//' /usr/share/xdg-desktop-portal/portals/kde.portal systemctl --user restart xdg-desktop-portal This requires xdg-desktop-portal-gtk to be installed. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 457672] Spotify notifications plays error sound
https://bugs.kde.org/show_bug.cgi?id=457672 Wyatt Childers changed: What|Removed |Added CC||kdebugs.81do7@haxing.ninja --- Comment #2 from Wyatt Childers --- I don't want to presume, but I'd consider this a duplicate of 462283 (I've posted a workaround given by a Telegram contributor there). -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 462357] Notification Sound Behavior Changed
https://bugs.kde.org/show_bug.cgi?id=462357 Wyatt Childers changed: What|Removed |Added Resolution|--- |DUPLICATE Status|REPORTED|RESOLVED --- Comment #3 from Wyatt Childers --- This is probably better handled in the respective bugs: https://bugs.kde.org/show_bug.cgi?id=462278 and https://bugs.kde.org/show_bug.cgi?id=462283 *** This bug has been marked as a duplicate of bug 462283 *** -- You are receiving this mail because: You are watching all bug changes.
[xdg-desktop-portal-kde] [Bug 462283] xdg-desktop-portal-kde notification produces sound
https://bugs.kde.org/show_bug.cgi?id=462283 --- Comment #2 from Wyatt Childers --- *** Bug 462357 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[xdg-desktop-portal-kde] [Bug 462283] xdg-desktop-portal-kde notification produces sound
https://bugs.kde.org/show_bug.cgi?id=462283 Wyatt Childers changed: What|Removed |Added CC||kdebugs.81do7@haxing.ninja -- You are receiving this mail because: You are watching all bug changes.
[xdg-desktop-portal-kde] [Bug 462278] Actions in Notification portal totally broken
https://bugs.kde.org/show_bug.cgi?id=462278 Wyatt Childers changed: What|Removed |Added CC||kdebugs.81do7@haxing.ninja -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 462357] Notification Sound Behavior Changed
https://bugs.kde.org/show_bug.cgi?id=462357 --- Comment #2 from Wyatt Childers --- (In reply to Nicolas Fella from comment #1) > Nothing changed here, notifications through the Flatpak portal always had > that sound. The only thing that may have changed is that Telegram started > using the portal, but that's just speculation from me Thanks, that's helpful; I've opened an issue on the Telegram side: https://github.com/telegramdesktop/tdesktop/issues/25469 -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 462357] New: Notification Sound Behavior Changed
https://bugs.kde.org/show_bug.cgi?id=462357 Bug ID: 462357 Summary: Notification Sound Behavior Changed Classification: I don't know Product: kde Version: unspecified Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: unassigned-b...@kde.org Reporter: kdebugs.81do7@haxing.ninja Target Milestone: --- SUMMARY Something seems to have changed with notification handling, or perhaps the way flatpak is sending notifications. After upgrading to Fedora 37 (from 36) I've been noticing my Telegram flatpak playing Oxygen-Sys-Special.ogg sounds (which are quite annoying). STEPS TO REPRODUCE 1. Install Fedora 37 & the Telegram Flatpak 2. Ensure desktop notifications are enabled (in Settings -> Notificiations and Sounds) 3. Receive a message OBSERVED RESULT Oxygen-Sys-Special.ogg plays. EXPECTED RESULT No sound plays. SOFTWARE/OS VERSIONS Operating System: Fedora Linux 37 KDE Plasma Version: 5.26.3 KDE Frameworks Version: 5.100.0 Qt Version: 5.15.7 Kernel Version: 6.0.9-300.fc37.x86_64 (64-bit) Graphics Platform: Wayland Processors: 32 × AMD Ryzen 9 7950X 16-Core Processor Memory: 62.0 GiB of RAM Graphics Processor: AMD Radeon RX 6700 XT Manufacturer: ASUS ADDITIONAL INFORMATION This seems related to: Bug 457672 and additionally there's some context here related to that here https://invent.kde.org/frameworks/frameworkintegration/-/merge_requests/13 -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 459759] Unable to rearrange Latte Dock Items
https://bugs.kde.org/show_bug.cgi?id=459759 --- Comment #3 from Wyatt Childers --- (In reply to Wyatt Childers from comment #1) > Curiously the thunderbird launcher can't be right clicked on any longer as > well. I wonder if it has somehow become "invalid" and that relates to this > as well as bug 453007? Okay this is likely unrelated. I managed to work around this issue by manually editing the config file (which lists the launchers pretty simply). Adding 459761 for the Thunderbird issue. -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 459761] Thunderbird can't be interacted with
https://bugs.kde.org/show_bug.cgi?id=459761 Wyatt Childers changed: What|Removed |Added Platform|Other |Fedora RPMs -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 459761] New: Thunderbird can't be interacted with
https://bugs.kde.org/show_bug.cgi?id=459761 Bug ID: 459761 Summary: Thunderbird can't be interacted with Classification: Plasma Product: lattedock Version: 0.10.8 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: application Assignee: mvourla...@gmail.com Reporter: kdebugs.81do7@haxing.ninja Target Milestone: --- SUMMARY Thunderbird can be launched via latte dock, however it has no right click menu available (right clicking does absolutely nothing). STEPS TO REPRODUCE 1. Open Thunderbird 2. Right click on Thunderbird in latte dock OBSERVED RESULT Nothing happens EXPECTED RESULT The right click menu appears SOFTWARE/OS VERSIONS Operating System: Fedora Linux 36 KDE Plasma Version: 5.25.5 KDE Frameworks Version: 5.98.0 Qt Version: 5.15.5 Kernel Version: 5.19.11-200.fc36.x86_64 (64-bit) Graphics Platform: Wayland Processors: 32 × AMD Ryzen 9 3950X 16-Core Processor Memory: 62.7 GiB of RAM Graphics Processor: AMD Radeon RX 6700 XT Manufacturer: Gigabyte Technology Co., Ltd. Product Name: AX370-Gaming 5 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 459759] Unable to rearrange Latte Dock Items
https://bugs.kde.org/show_bug.cgi?id=459759 --- Comment #2 from Wyatt Childers --- Oops, I meant bug 459760. -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 459759] Unable to rearrange Latte Dock Items
https://bugs.kde.org/show_bug.cgi?id=459759 --- Comment #1 from Wyatt Childers --- Curiously the thunderbird launcher can't be right clicked on any longer as well. I wonder if it has somehow become "invalid" and that relates to this as well as bug 453007? -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 459760] New: Latte dock closes unexpectedly when editing the dock
https://bugs.kde.org/show_bug.cgi?id=459760 Bug ID: 459760 Summary: Latte dock closes unexpectedly when editing the dock Classification: Plasma Product: lattedock Version: 0.10.8 Platform: Other OS: Linux Status: REPORTED Severity: major Priority: NOR Component: application Assignee: mvourla...@gmail.com Reporter: kdebugs.81do7@haxing.ninja Target Milestone: --- SUMMARY When editing the latte dock the dock closes unexpected with "xdg_surface@78: error -1: invalid window geometry size (539x0)." STEPS TO REPRODUCE 1. Open latte-dock 2. Right click, select "edit" OBSERVED RESULT The dock exits with: "xdg_surface@78: error -1: invalid window geometry size (539x0)." EXPECTED RESULT The dock enters edit mode SOFTWARE/OS VERSIONS Operating System: Fedora Linux 36 KDE Plasma Version: 5.25.5 KDE Frameworks Version: 5.98.0 Qt Version: 5.15.5 Kernel Version: 5.19.11-200.fc36.x86_64 (64-bit) Graphics Platform: Wayland Processors: 32 × AMD Ryzen 9 3950X 16-Core Processor Memory: 62.7 GiB of RAM Graphics Processor: AMD Radeon RX 6700 XT Manufacturer: Gigabyte Technology Co., Ltd. Product Name: AX370-Gaming 5 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 459759] New: Unable to rearrange Latte Dock Items
https://bugs.kde.org/show_bug.cgi?id=459759 Bug ID: 459759 Summary: Unable to rearrange Latte Dock Items Classification: Plasma Product: lattedock Version: 0.10.8 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: major Priority: NOR Component: application Assignee: mvourla...@gmail.com Reporter: kdebugs.81do7@haxing.ninja Target Milestone: --- Created attachment 152480 --> https://bugs.kde.org/attachment.cgi?id=152480&action=edit Observed result screen shot SUMMARY I can no longer rearrange pinned items in my dock. The "drag and drop" "drop" never finishes STEPS TO REPRODUCE 1. Pin a few items 2. Attempt to drag an item on the right to the left OBSERVED RESULT The dock gets stuck in a hover state. EXPECTED RESULT The item changes position. SOFTWARE/OS VERSIONS Operating System: Fedora Linux 36 KDE Plasma Version: 5.25.5 KDE Frameworks Version: 5.98.0 Qt Version: 5.15.5 Kernel Version: 5.19.11-200.fc36.x86_64 (64-bit) Graphics Platform: Wayland Processors: 32 × AMD Ryzen 9 3950X 16-Core Processor Memory: 62.7 GiB of RAM Graphics Processor: AMD Radeon RX 6700 XT Manufacturer: Gigabyte Technology Co., Ltd. Product Name: AX370-Gaming 5 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 421011] /org/freedesktop/PowerManagement/Inhibit shouldn't prevent locking screen
https://bugs.kde.org/show_bug.cgi?id=421011 Wyatt Childers changed: What|Removed |Added Status|REPORTED|CONFIRMED CC||dark...@nearce.com Ever confirmed|0 |1 --- Comment #3 from Wyatt Childers --- (In reply to Guo Yunhe from comment #0) > SUMMARY > --- > > Video players invoke /org/freedesktop/ScreenSaver/Inhibit to prevent screen > dimming and locking > > Music players invoke /org/freedesktop/PowerManagement/Inhibit to prevent > system sleeping but screen dimming and locking should still work. However, > this isn't the case in KDE/Plasma. Can some information on where these specs live? It looks like this was supposed to be fixed back in 2018: https://github.com/KDE/powerdevil/commit/152400c1b6880506ee1395011686c2b191f419a0 It looks like this may be manifesting in a very weird way. I currently get "nothing" (literally no name/text) "is currently blocking sleep and screen locking (Playing)" from Rythmbox. -- You are receiving this mail because: You are watching all bug changes.
[Elisa] [Bug 399249] Add support for scrobbling to last.fm
https://bugs.kde.org/show_bug.cgi?id=399249 --- Comment #11 from Wyatt Childers --- (In reply to Gerald Cox from comment #10) > Rescrobbled works perfect as a workaround. There is also mpris-scrobbler, > but at the moment it has a few bugs that have just been languishing with no > apparent interest to address, so I would recommend rescrobbled. I suppose > the question is whether the direction is to relegate such things as > scrobbling functionality to MPRIS apps. If so, that should be noted here > and this ticket closed. I'm not fundamentally opposed to a generic KDE/Plasma MPRIS scrobbler instead of something builtin to Elisa. However, MPRIS is used for a lot of things beyond music, so there would need to be some way to distinguish Elisa music from say, a random video in Firefox. Maybe that's just a configuration dialog that lets certain players be ignored, or maybe there's enough metadata in MPRIS to determine whether something is music or not? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 432059] Yakuake Window Position Is Wrong
https://bugs.kde.org/show_bug.cgi?id=432059 Wyatt Childers changed: What|Removed |Added Summary|Nvidia Wayland - Yakuake|Yakuake Window Position Is |Window Position Is Wrong|Wrong -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 432059] Nvidia Wayland - Yakuake Window Position Is Wrong
https://bugs.kde.org/show_bug.cgi?id=432059 Wyatt Childers changed: What|Removed |Added Status|NEEDSINFO |REPORTED Resolution|WAITINGFORINFO |--- -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 432059] Nvidia Wayland - Yakuake Window Position Is Wrong
https://bugs.kde.org/show_bug.cgi?id=432059 --- Comment #7 from Wyatt Childers --- I should additionally note, I'm on AMD hardware now... so I can't comment as to if there's any remaining nvidia specific issue. I don't see this appear at the top left of the screen, and haven't for a while, but it's still not "in the right spot." -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 432059] Nvidia Wayland - Yakuake Window Position Is Wrong
https://bugs.kde.org/show_bug.cgi?id=432059 --- Comment #6 from Wyatt Childers --- (In reply to David Edmundson from comment #4) > I can not reproduce this anymore. It does require some changes in yakuake > which have landed. Given it is window positioning it is unlikely to be > nvidia related. Can you confirm this works with a newer yakuake? Can you give some context as to when those changes "have landed"? What release version are they expected in? I'm running Yakuake 21.12.2 and still see the window appear at centered vertically of my screen, rather than at the top of my screen. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 450973] Failed Offline Update error
https://bugs.kde.org/show_bug.cgi?id=450973 Wyatt Childers changed: What|Removed |Added CC||dark...@nearce.com --- Comment #1 from Wyatt Childers --- Created attachment 147770 --> https://bugs.kde.org/attachment.cgi?id=147770&action=edit failed update notification I can confirm this (see the attachment). This has repeatedly appeared and the repair button/open discover do nothing to resolve it. I believe Bug 451753 is also a duplicate. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 451796] New: Feature Request: Hold Shift to Launch Multiple Apps from Application Dashboard
https://bugs.kde.org/show_bug.cgi?id=451796 Bug ID: 451796 Summary: Feature Request: Hold Shift to Launch Multiple Apps from Application Dashboard Product: plasmashell Version: 5.24.3 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: dark...@nearce.com CC: k...@davidedmundson.co.uk Target Milestone: 1.0 As a user, I'd like to be able to launch multiple applications from the application dashboard without opening the application dashboard multiple times. An intuitive way to do this (to me) would be to hold shift during clicking the launchers to "keep" the Application Dashboard up. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 451579] Feature Request - Brightness Control of External Monitors via Monitor Control Command Set
https://bugs.kde.org/show_bug.cgi?id=451579 Wyatt Childers changed: What|Removed |Added Resolution|--- |NOT A BUG Status|REPORTED|RESOLVED --- Comment #2 from Wyatt Childers --- Well I'll be, I rebooted just to see, but I still don't have any monitor brightness controls I can see anywhere. Perhaps Fedora isn't building their package with WITH_DDCUTIL. I've been using Fedora since roughly when it looks like this was implemented. I'll take that up with them... Thanks for implementing it, my bad :) -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 451579] New: Feature Request - Brightness Control of External Monitors via Monitor Control Command Set
https://bugs.kde.org/show_bug.cgi?id=451579 Bug ID: 451579 Summary: Feature Request - Brightness Control of External Monitors via Monitor Control Command Set Product: Powerdevil Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: dark...@nearce.com Target Milestone: --- Currently external monitor birghtness is not handled. This is a feature request to add software support for external monitors brightness via MCCS. An example program that already does this/might be a good "underpinning" with more information on the spec/communication is ddcutil (https://www.ddcutil.com/). As an example, I can use the following ddcutil commands to set both monitor's brightness to 100%: $> sudo ddcutil setvcp -d 1 10 100 $> sudo ddcutil setvcp -d 2 10 100 Or 50%: $> sudo ddcutil setvcp -d 1 10 50 $> sudo ddcutil setvcp -d 2 10 50 As some extra background as for "why" my office has a lot of light in the morning/when it's snowy outside vs very dark at night, so I regularly need to adjust monitor brightness throughout the day. It's much more convient to do that with software. I think adding keyboard controlled/GUI slider based brightness integration would be a really nice feature for KDE to have for external monitors. It would be ideal to eventually be able to have some presets, maybe have a "default brightness curve" for the day, etc. However, the first step with any of that would be IMO, exposing basic brightness controls for the monitors. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 429211] [X11] Digital clock/whole panel sometimes stops updating until there is user interaction with Plasma
https://bugs.kde.org/show_bug.cgi?id=429211 Wyatt Childers changed: What|Removed |Added CC|dark...@nearce.com | -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 449163] Plasma panel visually freezes after some time under Wayland
https://bugs.kde.org/show_bug.cgi?id=449163 Wyatt Childers changed: What|Removed |Added CC||dark...@nearce.com -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 429211] Digital clock/whole panel sometimes stops updating until there is user interaction with Plasma
https://bugs.kde.org/show_bug.cgi?id=429211 --- Comment #28 from Wyatt Childers --- (In reply to Prajna Sariputra from comment #27) > (In reply to Wyatt Childers from comment #24) > > This started happening for me, or at least something close to one of the > > duplicate bugs within the last week or so. Everything was fine, and now it's > > regularly breaking. Nothing fixes the problem other than restarting the > > session (i.e., user interaction with plasma is not sufficient to get the > > clock or notification area to start updating again). > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2048151 > > Was there by any chance an update to qt5-qtwayland that you installed before > the issue occurred for you? That was what triggered the problem for me on > Arch, and downgrading that package fixed it in my case, so that might be > worth a try. For Arch the problematic package is `qt5-wayland > 5.15.2+kde+r44-1` and newer, looking through the sources the Fedora 35 > equivalent to that is `qt5-qtwayland 5.15.2-17.fc35`. On the 23rd (which roughly lines up): Upgrade qt5-qtwayland-5.15.2-17.fc35.x86_64 @updates Upgraded qt5-qtwayland-5.15.2-15.fc35.x86_64 @@System There isn't even a version bump there though, so that seems unlikely. I don't really have a way to rollback/downgrade (I'm not aware of any source for the old package). That said, it looks like they did "pull fixes" which maybe weren't fixes: https://src.fedoraproject.org/rpms/qt5-qtwayland/commits/f35 Namely: - Build 16 (https://src.fedoraproject.org/rpms/qt5-qtwayland/c/7500ad163e15e45219177b30dc1523aff14803eb?branch=f35) - Build 17 (https://src.fedoraproject.org/rpms/qt5-qtwayland/c/770c4ae5bb6d2bb7d2e4659d0fa1c822a005fe8e?branch=f35) It looks like there's a build 18 in the works to try to fix the issue (https://src.fedoraproject.org/rpms/qt5-qtwayland/c/d87aaf116e415d92178345ef5f84b2bc98e5ddd7?branch=f35). -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 429211] Digital clock/whole panel sometimes stops updating until there is user interaction with Plasma
https://bugs.kde.org/show_bug.cgi?id=429211 --- Comment #26 from Wyatt Childers --- > I should add explicitly here, this affects Latte dock as well, this isn't > exclusive to plasmashell. Also it seems putting the computer to sleep then coming back seems to bring latte dock at least back into a functional state. I'm not sure what the implications of that are for debugging this. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 429211] Digital clock/whole panel sometimes stops updating until there is user interaction with Plasma
https://bugs.kde.org/show_bug.cgi?id=429211 --- Comment #25 from Wyatt Childers --- (In reply to Wyatt Childers from comment #24) > This started happening for me, or at least something close to one of the > duplicate bugs within the last week or so. Everything was fine, and now it's > regularly breaking. Nothing fixes the problem other than restarting the > session (i.e., user interaction with plasma is not sufficient to get the > clock or notification area to start updating again). > > https://bugzilla.redhat.com/show_bug.cgi?id=2048151 I should add explicitly here, this affects Latte dock as well, this isn't exclusive to plasmashell. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 429211] Digital clock/whole panel sometimes stops updating until there is user interaction with Plasma
https://bugs.kde.org/show_bug.cgi?id=429211 Wyatt Childers changed: What|Removed |Added CC||dark...@nearce.com --- Comment #24 from Wyatt Childers --- This started happening for me, or at least something close to one of the duplicate bugs within the last week or so. Everything was fine, and now it's regularly breaking. Nothing fixes the problem other than restarting the session (i.e., user interaction with plasma is not sufficient to get the clock or notification area to start updating again). https://bugzilla.redhat.com/show_bug.cgi?id=2048151 -- You are receiving this mail because: You are watching all bug changes.
[Elisa] [Bug 427186] feature request: smart playlist
https://bugs.kde.org/show_bug.cgi?id=427186 Wyatt Childers changed: What|Removed |Added CC||dark...@nearce.com -- You are receiving this mail because: You are watching all bug changes.
[Elisa] [Bug 399249] Add support for scrobbling to last.fm
https://bugs.kde.org/show_bug.cgi?id=399249 Wyatt Childers changed: What|Removed |Added CC||dark...@nearce.com -- You are receiving this mail because: You are watching all bug changes.