[kwin] [Bug 470185] Maximized windows not covering entire screen in some circumstances
https://bugs.kde.org/show_bug.cgi?id=470185 --- Comment #7 from Aaron Kelley <09_strays_fli...@icloud.com> --- > ...on Wayland? On Wayland it seems to maximize and properly cover the entire screen. > ...if you make your panel always visible? If the panel is always visible (and on the bottom), I get a one-pixel space between the top of the panel and the bottom of a maximized window. > ...if you add `export PLASMA_USE_QT_SCALING=1` to the > `~/.config/plasma-workspace/env/envs.sh` file (creating it if it doesn't > exist) and then reboot? This didn't seem to make any difference, I can still see the issue. -- You are receiving this mail because: You are watching all bug changes.
[plasma-pa] [Bug 391578] Have kded or plasmashell handle volume-related keyboard shortcuts so they don't stop working when all Audio Volume applet/widget instances are removed
https://bugs.kde.org/show_bug.cgi?id=391578 Aaron Kelley <09_strays_fli...@icloud.com> changed: What|Removed |Added CC||09_strays_fli...@icloud.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 470185] Maximized windows not covering entire screen in some circumstances
https://bugs.kde.org/show_bug.cgi?id=470185 --- Comment #5 from Aaron Kelley <09_strays_fli...@icloud.com> --- Poking around a bit more. If I take the bottom panel out of autohide, I get a one-pixel space ABOVE the panel and BELOW the maximized window. If I move the panel to the right side of the screen, there is no space between a maximized window and the panel but there is still a one-pixel space at the bottom of the screen that the maximized window does not cover. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 470185] Maximized windows not covering entire screen in some circumstances
https://bugs.kde.org/show_bug.cgi?id=470185
--- Comment #4 from Aaron Kelley <09_strays_fli...@icloud.com> ---
I set scaling to 200% through Settings → Display and Monitor → Display
Configuration → Global scale. It does not look like the PLASMA_USE_QT_SCALING
environment variable is set to anything ("echo $PLASMA_USE_QT_SCALING" returns
nothing) and I definitely never explicitly set it.
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 470185] Maximized windows not covering entire screen in some circumstances
https://bugs.kde.org/show_bug.cgi?id=470185 Aaron Kelley <09_strays_fli...@icloud.com> changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REPORTED --- Comment #2 from Aaron Kelley <09_strays_fli...@icloud.com> --- It is X11. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 470185] New: Maximized windows not covering entire screen in some circumstances
https://bugs.kde.org/show_bug.cgi?id=470185 Bug ID: 470185 Summary: Maximized windows not covering entire screen in some circumstances Classification: Plasma Product: kwin Version: 5.27.5 Platform: Kubuntu OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwin-bugs-n...@kde.org Reporter: 09_strays_fli...@icloud.com Target Milestone: --- Created attachment 159215 --> https://bugs.kde.org/attachment.cgi?id=159215&action=edit Screen shot demonstrating the issue. Look at the bottom row of pixels. It is a web page in Firefox, "behind" Dolphin. STEPS TO REPRODUCE 1. 4K display, 200% DPI scaling. 2. Bottom panel set to "auto hide". 3. Launch Dolphin application and maximize the window. OBSERVED RESULT Dolphin covers the entire screen... minus the bottom row of pixels. (See screen shot, attached.) EXPECTED RESULT Dolphin should cover the entire screen. Note that snapping a window to the left or right half of the screen (i.e. Super+left arrow) does result in it covering that bottom row of pixelsproperly. Also, this issue appears to be specific to Qt applications? Dolphin, Kate, Konsole, and VLC will leave a row of pixels at the bottom. Firefox, Thunderbird, Visual Studio Code and Google Earth do not. SOFTWARE/OS VERSIONS Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.106.0 Qt Version: 5.15.8 -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 469951] With fingerprint login, odd behaviors if you do not perform a scan promptly
https://bugs.kde.org/show_bug.cgi?id=469951 --- Comment #3 from Aaron Kelley <09_strays_fli...@icloud.com> --- (As a note for anyone who may look into this. libpam-fprintd documentation suggests that setting "-1" for an "unlimited" timeout is allowed, but that is *also broken* in the current release. If you set it to -1, you will get the default 30 second timeout window. I'm soon going to be rattling around on their end to get that fixed. There is already a PR that solves it but it has been sitting for five months without any merge or activity.) -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 469951] With fingerprint login, odd behaviors if you do not perform a scan promptly
https://bugs.kde.org/show_bug.cgi?id=469951 --- Comment #2 from Aaron Kelley <09_strays_fli...@icloud.com> --- I would suggest that kscreenlocker should just go with whatever timeout PAM is configured to use. Since PAM is used in more places than just kscreenlocker, it isn't really KDE/Plasma's job to "set" the value there, just let the user do it if they so choose. If a user hits an issue like mine where the fingerprint reader timeout is an issue, raising the timeout would effectively solve it. As it stands, (at least for me) setting a long timeout doesn't seem to fix the problem. kscreenlocker does not wait for it to expire before giving up on PAM fingerprint authentication. This is illustrated by my test case described earlier; set the timeout to 99 seconds (...or higher, but that currently requires patching fprintd...) and kscreenlocker will end the PAM authentication session after ≈90 seconds. I haven't had a chance to dig into the kscreenlocker code yet to see exactly what is going on here. I've only looked at the libpam-fprintd side of things so far. -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 469951] New: With fingerprint login, odd behaviors if you do not perform a scan promptly
https://bugs.kde.org/show_bug.cgi?id=469951 Bug ID: 469951 Summary: With fingerprint login, odd behaviors if you do not perform a scan promptly Classification: Plasma Product: kscreenlocker Version: git-stable-Plasma/5.27 Platform: Kubuntu OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: 09_strays_fli...@icloud.com Target Milestone: --- I recently moved from Plasma 5.24.7 to Plasma 5.27.5 and have observed a change in behavior in how fingerprint unlock from the lock screen works. For me, this has made the experience of getting past the lock screen more annoying. Note that here I am referring to getting past the lock screen (kscreenlocker), not the initial login screen (sddm). Plasma 5.24 behavior: I am presented with a password prompt and not prompted to do a fingerprint scan until I hit "enter". Entering a blank password is fine, it will then prompt me to scan my finger and log me in after a successful scan. Plasma 5.27 behavior: The system immediately prompts for a fingerprint scan if I press any key or move the mouse. I don't have to hit "enter" at the password prompt to get it to ask for a scan. This *seems* like an improvement since I can get into the system more quickly. The problem comes from the fact that it is easy to disturb the lock screen and have it prompt for a scan when I'm not actually ready to log in yet. I'm just using a laptop with a USB mouse attached, and if I have the screen locked and pick the system up to move it to a different location, kscreenlocker will think that I'm ready to do a fingerprint scan. A few minutes later when I'm actually ready to do a scan, it has already errored out. So, we have some issues. STEPS TO REPRODUCE 1. Set PAM fingerprint timeout to 30 seconds. (/etc/pam/common-auth) 2. Lock the KDE Plasma session. 3. Move the mouse. kscreenlocker system prompts for a fingerprint scan. 4. Wait 30 seconds. OBSERVED RESULT The scan times out and results in the error message "Verification failed". The proceed, I have to hit enter at the empty password box, watch the shake/failure animation, and then wait a few seconds before it will allow me to try again. So in the end, it takes *longer* than it took with Plasma 5.24. EXPECTED RESULT ...I wasn't even ready to scan yet. Wait until I take explicit action before starting a scan, or, automatically retry the scan after failure. = I tried increasing the fingerprint scan timeout to get around this issue. If kscreenlocker would just sit and wait patiently until I am really ready to do a fingerprint scan, then there would be no problem. It turns out that there's a bug in libpam-fprintd that prevents setting the timeout higher than 99 seconds, but I got around that by applying this unmerged patch. See: - https://gitlab.freedesktop.org/libfprint/fprintd/-/issues/147 - https://gitlab.freedesktop.org/libfprint/fprintd/-/merge_requests/195 Regardless, increasing the timeout does not help me solve this problem. STEPS TO REPRODUCE 1. Set PAM fingerprint timeout to 99 seconds. (/etc/pam/common-auth) 2. Lock the KDE Plasma session. 3. Move the mouse once. kscreenlocker prompts for a fingerprint scan. 4. Wait 99 seconds. OBSERVED RESULT kscreenlocker appears to give up on PAM fingerprint authentication approximately 88 seconds after issuing the fingerprint scan prompt. I got this from tracing through entries in auth.log with libpam-fprintd "debug" mode turned on, and observing the steps that it is going through in the libpam-fprintd code. In libpam-fprintd, the poll is interrupted early and it gets back an error "verify-unknown-error". (This is not the case with, for example, a sudo password prompt; it will wait as long as I have configured for a fingerprint scan.) At this point, fingerprint authentication is broken. Despite kscreenlocker issuing another request for me to scan my finger, the only way forward is to enter my password. EXPECTED RESULT kscreenlocker should wait indefinitely for a fingerprint scan. The timeout is configured by PAM. = Alternatively, is there a way to configure kscreenlocker to just not try to do a fingerprint scan until I hit "enter" at the password prompt, like it did in Plasma 5.24? SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu 23.04, Linux kernel 6.2 KDE Plasma Version: Plasma 5.27.5 KDE Frameworks Version: 5.104.0 Qt Version: 5.15.8 -- You are receiving this mail because: You are watching all bug changes.
