René J.V. Bertin posted on Tue, 28 Feb 2017 23:16:42 +0100 as excerpted:
> Please allow me a few follow-up questions
>
> Given that apparently the KDE4 screensaving/locking mechanism is too old
> to work correctly with whatever component is now too new:
>
> 1) can I prevent locking entirely, including at suspend/wake? I thought
> I'd seen an option that controls this in systemsettings but cannot seem
> to find it anymore. I tried a wrapper script that filters out
> --immediateLock but it seems that approach has been made impossible.
It is/was possible, as back in kde4 I did it. But that's some time ago
so my memory of the details is fading, and I am and was running gentoo,
which typically gives the end-user-admin rather more choice in package
feature-related-dependencies and other configuration than most distros,
so the degree to which my rather odd config then if I do remember it
correctly applies to your situation now, isn't known.
What I do remember is that the kde4 and kde5 screen-locking mechanisms
are quite different. I don't run or indeed have installed a *DM
graphical login manager of any kind, preferring to do a text-based login
and (effectively) run startx with a kde x-session setup to run.
Without kdm or similar installed, kde4/plasma4 didn't have a greeter
available and I had to be careful not to lock the screen, etc, because
there was no way to unlock it as I had no greeter.
Plasma5, by contrast, appears to have its own screen-unlock greeter, and
the lack of *dm doesn't matter for it -- I can lock the screen and
hitting a key or wiggling the mouse will bring up the unlock dialog just
fine. (Tho it can be noted that earlier 5.x versions, I'm running live-
git of frameworks/plasma/apps now and the problem is fixed, appeared to
have some sort of issue with the radeon freedomware drivers, such that
some combination of screen blanking/powerdown/locking, I never quite
figured out exactly which, would cause X to go unresponsive.)
So back on kde4 I *had* to ensure that the screenlocker didn't trigger,
because that meant killing X and the existing kde4 session (via the
kernel's magic-srq-K or switching VTs and killing it from there) in
ordered to get back to a situation where I could run startx and start a
new one, since I couldn't get back into the old one.
So yes, it's definitely /possible/, as that's the only way it would work
in kde4, for me.
Of course I also have policykit and friends options turned off and the
associated plumbing not even installed, which means suspend/hibernate via
KDE gui doesn't work as it can't get authorization. However, I've never
had problems triggering them via my own scripts and (appropriately
configured) sudo, and resuming doesn't return me to a screenlock, either.
In terms of kde config, IIRC the main thing was setting the screen saver
stuff not to lock, and turning off the (manual) lock option display where
possible, or simply staying away from it where I couldn't figure out how
to turn it off, since I knew locking would effective mean killing the kde
session, and I could do that more effectively by simply logging out of
the session and returning to a text console prompt.
> 2) can KF5 kscreenlocker function outside of a Plasma5 session?
> kscreenlocker_greet complains about loading a wallpaper (probably just a
> warning), but it doesn't display an unlocking dialog which for all
> practical purposes is the same as a dysfunctional dialog. This is true
> also when I run KWin5 (kwin_x11), as if it also doesn't work properly
> for some related reason.
I /believe/ the kf5 screenlocker is plasma5 specific, for the reason
described above (it's now a plasma5 desktop component and expects to work
as such, not using the *dm greeter component as in kde4).
But I'm not a dev, just a user, and that's only my /belief/.
> Which begs the question:
> 3) suppose something like this happens on a Plasma5 desktop, what
> backdoors are there to unlock the session without killing it, from a
> virtual console?
Any such backdoors would be considered security bugs, and thus
exterminated. (To the extent possible with X, of course.)
One of the problems with X is that it simply wasn't designed to be run in
an untrusted user environment, the reason any X-based app can see the
input to any other, including passwords, etc, and enforcing input grabs
to truly enforce authentication before X-session unlocking has always
been a security challenge as a result. Wayland, however, is designed to
be far more security aware, and eliminates these sorts of issues to a
large degree, to the point that the problems are actually then in
allowing such cross-application input spying where actually desired.
Basically, the compositor, kwin-wayland in plasma's case, is the only
application allowed to spy on the input of other wayland apps' input
streams, which means the compositor is the only app that can do global
wayland hotkeys, for instance. Unless of course it specifically passes
on that information to some other component, and from the development
discussion I've read, kwin-wayland is by design extremely particular
about which other apps it will pass that information on to, for security
reasons. IOW, expect the number of global hotkey apps available on
wayland to be far smaller than the number of corresponding apps for X,
and expect restrictions on the ones that can be run with specific
compositors, as well. All for security reasons.
Because a primary focus of plasma5 is porting to wayland, with current
status being runnable but with various quirks still being polished out so
it's not yet recommended for ordinary users, expect later plasma5
versions to work with both xorg and wayland, of course with the latter
supporting wayland's rather better security environment and other modern
protocol benefits, tho likely at the cost of somewhat limited flexibility
on both sides as compatibility with the earlier X environment is
maintained. Presumably with plasma6 (entirely my own predictions as a
user, tho I am following git commits), if the wayland transition
continues native wayland will likely be the primary focus, tho X may well
still be supported, possibly as legacy, and projecting further out,
perhaps plasma7 will be native-wayland-only, tho still with the
possibility of running rootless X-nested sessions for legacy X apps.
.....
Meanwhile, somewhat OT usage note FYI: "Begs the question", with a
question following, despite being arguably logical current usage (which I
fully support and use myself, tho usually with a note indicating I'm
doing it deliberately, so don't take this wrong), is considered by many
to be improper usage.
The term has a long history, tracing back thru Latin (petitio principii,
asking for the starting point, assuming the premise) and Greek (asking
for the initial thing), where it originally referred to (more or less)
circular logic. To "beg the question" meant that the original question
or proposition of logic was not supported by what followed, since that
ultimately simply resulted in either a restatement of the original
question/proposition instead of answering/supporting/proving it (directly
circular logic), or assumed the truth of a second question/proposition
that hadn't been adequately demonstrated itself (not directly circular,
more complex).
The term in that usage form continues to be seen today, particularly in
the legal and logic communities, where it can often be spotted standing
alone (without a following question) in reply to some often convoluted
logic, pointing out that it doesn't support or prove the original
proposal at all, but rather only leads back to it or a related proposal
that hasn't been demonstrated to be true.
However, that original and still somewhat common in some communities
usage has been overtaken in the wider general population by the more
popular "That begs the question: New question following from old" usage,
as seen above. Certainly, this usage seems logical enough to me, as
"strongly suggests as a followup", or "begs that the question be asked",
a more literal read of the individual words themselves. But it's not the
original/historical meaning, and some people will certainly look down on
you if you use it in this way, despite its current general popularity
used this way.
Rule of thumb: As I've touched on in passing above, if "begs the
question" can stand alone, without a following question, that's likely to
be the historical meaning as still used in philosophy, logic, and legal.
If "begs the question" must be followed by a question to make sense, it's
likely to be the arguably now more common in general but still quite
controversial meaning.
Which is why I usually footnote (or explain in parentheses) usage (either
way) of my own, with something like: "(Yes, I'm familiar with the meaning
related to circular logic, but deliberately choose to use and support
this now more popular usage myself.)" The idea being that while they may
still disagree with my usage, it's quite obvious that I actually know the
usage they consider "proper", and that I made the choice to use it in
this way entirely deliberately. Then I usually include references:
https://en.wikipedia.org/wiki/Begging_the_question
http://begthequestion.info/
https://public.wsu.edu/~brians/errors/begs.html
I actually subscribe to the language-log feed, having discovered it
myself while looking up another phrase (toe the line, /not/ tow the line,
which I had thought), and found their approach and many of the articles
and discussion to my liking. Their article on "begs the question" is
both historically detailed and reasonable, with a nice discussion
following, tho as detailed above I've chosen for my own personal usage
something a bit different than their recommendation in point #4:
http://languagelog.ldc.upenn.edu/nll/?p=2290
And finally, the related google, with its many many more links:
https://www.google.com/search?q=begs+the+question
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
