[kwin] [Bug 470185] Maximized windows not covering entire screen in some circumstances

2023-06-10 Thread Aaron Kelley
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

2023-05-26 Thread Aaron Kelley
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

2023-05-26 Thread Aaron Kelley
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

2023-05-26 Thread Aaron Kelley
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

2023-05-24 Thread Aaron Kelley
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

2023-05-23 Thread Aaron Kelley
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

2023-05-19 Thread Aaron Kelley
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

2023-05-19 Thread Aaron Kelley
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

2023-05-18 Thread Aaron Kelley
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.