Bug 384920 - Main Screen setting only partially used in kscreenlocker
Summary: Main Screen setting only partially used in kscreenlocker
Status: VERIFIED REMIND
Alias: None
Product: kscreenlocker
Classification: Plasma
Component: greeter (show other bugs)
Version: unspecified
Platform: Neon Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-09-21 07:59 UTC by Christian Ohrfandl
Modified: 2017-09-30 19:53 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
System setting for default monitor/view (800.76 KB, image/png)
2017-09-21 07:59 UTC, Christian Ohrfandl
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Ohrfandl 2017-09-21 07:59:26 UTC
Created attachment 107927 [details]
System setting for default monitor/view

Distro: KDE Neon Developer Edition Git-Unstable from 19th August 2017.
Plasma: 5.10.9
KDE Frameworks: 5.39.0

When two (possibly multiple) monitors are attached, the setting of a main display that is not the main display chosen by either BIOS or the OS in general but rather set by the user in the system settings (see attached image), kscreensaver only uses the the chosen monitor/view, when the user is signed in and the screen gets locked (this behaviour can be tested by seing which password input field gets the focus).

However, when starting the OS and when signing the user off - and therefore, the ksreenlocker is shown - kscreenlockers seems to order the monitors according to either BIOS- or default OS setting. IMO this behaviour is inconsistent. Is there a way to globally set a default monitor?
Comment 1 Martin Flöser 2017-09-21 15:35:57 UTC
The "primary display" is only meant for where the panel goes. It doesn't have much meaning, especially not for kscreenlocker.

Which screen gets the active password field is pretty much random.
Comment 2 Christian Ohrfandl 2017-09-21 15:40:47 UTC
(In reply to Martin Flöser from comment #1)
> Which screen gets the active password field is pretty much random.

Which would be OK, but should be consistent for a logged out- user and locked state