[plasmashell] [Bug 427838] Plasma lock screen brightens wallpaper with Breeze AlphaBlack when it should be darkened
https://bugs.kde.org/show_bug.cgi?id=427838 --- Comment #2 from Danni H --- Currently working around this by modifying a copy of the Breeze Dark theme. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 427838] Plasma lock screen brightens wallpaper with Breeze AlphaBlack when it should be darkened
https://bugs.kde.org/show_bug.cgi?id=427838 --- Comment #1 from Danni H --- Created attachment 132451 --> https://bugs.kde.org/attachment.cgi?id=132451=edit Expected lock screen wallpaper darkening -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 427838] New: Plasma lock screen brightens wallpaper with Breeze AlphaBlack when it should be darkened
https://bugs.kde.org/show_bug.cgi?id=427838 Bug ID: 427838 Summary: Plasma lock screen brightens wallpaper with Breeze AlphaBlack when it should be darkened Product: plasmashell Version: 5.20.0 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Lock/logout Assignee: plasma-b...@kde.org Reporter: dannihf...@fastmail.fm Target Milestone: 1.0 Created attachment 132450 --> https://bugs.kde.org/attachment.cgi?id=132450=edit Screen locker with Breeze AlphaBlack style SUMMARY I am using a theme from the KDE Store so I can make my panel purple: https://store.kde.org/p/1084931/ Recently, my lock screen has been tinting the wallpaper to be bright, making the text hard to read, when it should be tinting it dark, since Breeze AlphaBlack is a dark theme. STEPS TO REPRODUCE 1. Install Breeze AlphaBlack from Get New Plasma Styles 2. Lock the screen 3. Move the mouse OBSERVED RESULT The background is brightened to an uncomfortable level, making it hard to read the text. EXPECTED RESULT The background should be darkened. Linux/KDE Plasma: Arch Linux rolling release (available in About System) KDE Plasma Version: 5.20.0 KDE Frameworks Version: 5.75.0 Qt Version: 5.15.1, xcb windowing system ADDITIONAL INFORMATION See attachments -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 356711] XembedSNIProxy prevents KWin from unredirecting fullscreen SDL2 apps
https://bugs.kde.org/show_bug.cgi?id=356711 --- Comment #11 from Danni H --- > Don't be antagonistic. My bad. I shouldn't have let my frustration get to me. I'm happy that there is awareness of these issues among the KWin developers. > xwininfo -tree -root would be the most useful, I can't see why our z-stack > would be rasied when a game is in focus. This issue seems to be fixed but regardless I have attached the output of xwininfo while running hexchat and GZDoom, with GZDoom fullscreen and in the foreground. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 356711] XembedSNIProxy prevents KWin from unredirecting fullscreen SDL2 apps
https://bugs.kde.org/show_bug.cgi?id=356711 --- Comment #10 from Danni H --- Created attachment 124789 --> https://bugs.kde.org/attachment.cgi?id=124789=edit xwininfo output -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 356711] XembedSNIProxy prevents KWin from unredirecting fullscreen SDL2 apps
https://bugs.kde.org/show_bug.cgi?id=356711 --- Comment #7 from Danni H --- Hi, Some information on unredirection I found in a KWin fork that's focused on low latency and removing tearing and stuttering: https://github.com/tildearrow/kwin-lowlatency/blob/Plasma/5.15/unredirect.md I would strongly recommend getting in touch with the author of this repository so that the KWin experience can be improved for everyone. This is especially important given the rise of Variable Refresh Rate tech that will require fixes to how KWin handles its timing. GNOME ahead of KDE with high-refresh rate monitors, smoother, less lag and stutter: https://www.reddit.com/r/kde/comments/brsmqc/gnome_still_handles_highrefresh_rate_monitors/ Will the developers understand the severity of sync issues in KWin, or will they be left to rot like all the other bugs in the KDE Bugzilla? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 356711] XembedSNIProxy prevents KWin from unredirecting fullscreen SDL2 apps
https://bugs.kde.org/show_bug.cgi?id=356711 --- Comment #6 from Danni H --- Hi, This is indeed a pretty old bug and the behavior of KWin has changed since I filed this issue. It no longer automatically suspends compositing for topmost fullscreen windows (which I personally consider a regression, but that's for another issue). Instead the application requests that compositing is disabled. So even if some other window might otherwise interfere, KWin will still turn off effects until the application is closed, even if it opens in a window rather than fullscreen. I would still like to do a bit of testing with this. Namely, whether other windows can interfere with the graphics driver's ability to present the application using flip mode instead of blit mode - on the proprietary nVidia drivers the application must be topmost fullscreen with compositing disabled for this to happen. There is a helpful "API indicator" option that shows the current presentation mode. I'll let you know what I find. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 356711] XembedSNIProxy prevents KWin from unredirecting fullscreen SDL2 apps
https://bugs.kde.org/show_bug.cgi?id=356711 Danni H changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REPORTED --- Comment #4 from Danni H --- I was not aware that removing NEEDSINFO had to be done manually by the reporter. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 356711] XembedSNIProxy prevents KWin from unredirecting fullscreen SDL2 apps
https://bugs.kde.org/show_bug.cgi?id=356711 --- Comment #2 from Danni H <dannihf...@fastmail.fm> --- Hi, a few points of clarification (forgive me if this isn't new information): The cause of the bug is most likely XEmbedSNIProxy, not KWin. Also, more specifically, the issue isn't "slowdown" but microstutter. If I have compositing running then it's impossible for me to get a smooth 60 FPS without microstutter (usually at least a couple dropped frames a second), likely because the contents have to go through both nVidia's VSync and KWin's VSync, which are not perfectly synchronized with each other. If I want a smooth display, I have to run games full-screen and unredirected. My hope is that in the future, Wayland, new nVidia drivers and/or a new version of KWin will finally solve microstutter in windowed applications. However, I do not know where I would file such a bug because I do not know where the fault lies in the current graphics stack. For now I would at least like to be able to run applications full-screen without microstutter. I need unredirection for that. To answer your questions: - Dropbox is the only X icon in the tray. - The icon was not repainting to my knowledge. It was not animating, and KWin's Show Paint effect did not reveal any painting related to this icon. - Disabling compositing resolves microstutter but I don't want to Alt + Shift + F12 or make a KWin rule for every game I play. My understanding is that SDL2 only does unredirected fullscreen when there are no windows on top. Is there some sort of stray X window that XembedSNIProxy has that is sticking to the top, or is somehow trying to paint itself above everything else? This is my best guess as to what's going on. My current workaround is to prevent xembedsniproxy from running at login. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 356711] New: XembedSNIProxy prevents KWin from unredirecting fullscreen SDL2 apps
https://bugs.kde.org/show_bug.cgi?id=356711 Bug ID: 356711 Summary: XembedSNIProxy prevents KWin from unredirecting fullscreen SDL2 apps Product: plasmashell Version: 5.5.0 Platform: Archlinux Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: XembedSNIProxy Assignee: plasma-b...@kde.org Reporter: dannihf...@fastmail.fm I was trying to figure out why I was getting microstutters in some games after upgrading to 5.5. I then toggled compositing a few times and at some point I managed to get a black square to appear where Dropbox usually is in the system tray. That I was in a fullscreen game and this window was trying to draw itself above the game seemed suspicious. I killed xembedsniproxy and sure enough the problem was resolved. Reproducible: Always Steps to Reproduce: 1. Ensure KWin is set to "Suspend compositor for full screen windows" 2. Ensure xembedsniproxy is running 3. Open an SDL2 app in fullscreen mode (example: latest version of Quakespasm) 4. Notice lots of microstuttering regardless of whether the in-game vsync is enabled or disabled 5. Kill xembedsniproxy 6. Reopen the same SDL2 app and notice that it runs smoothly now. Actual Results: Lots of microstutter, running without in-game vsync gives uneven framerate and no tearing Expected Results: In-game vsync off should give tearing, in-game vsync on should be butter smooth I tried forcing xembedsniproxy to Keep Below in the KWin rules but no dice. -- You are receiving this mail because: You are watching all bug changes.
