--nextPart2940928.Zzyq9CcmDD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Tuesday 11 October 2011 17:34:10 Oswald Buddenhagen wrote: > On Tue, Oct 11, 2011 at 03:55:15PM +0200, Thomas L=C3=BCbking wrote: > > Am Tue, 11 Oct 2011 15:33:39 +0200 schrieb Torgny Nyblom : > > > Does this mean that I will be focred to use a screensaver with > > > password unlock? If so why is that not a vaild usecase? It's what= I > > > use at home all the time. > >=20 > > So you want to do that again why? >=20 > "because it's pretty"? > on a more serious note, now do you handle the lock grace time? this is actually not affected by the changes. Dim Display and turning o= ff the=20 screen are decoupled from the screen locking. >=20 > On Tue, Oct 11, 2011 at 04:00:17PM +0200, Martin Gr=C3=A4=C3=9Flin wr= ote: > > yes if you have a terminal open and if it is the top most of stacki= ng > > order it is possible to start another window manager. >=20 > [in fact ... oh, scratch that, thomas already answered] >=20 > > I think there is hardly anyone here on the list who is as experienc= ed > > as I am with situations where you don't have a window manager runni= ng > > ;-) >=20 > sorry, but that's an utter nonsense argument from a security pov. you= > are basically arguing for security by obscurity. Yes, sorry that comment was not meant seriously. >=20 > > KWin has currently one reproducable crash listed in bko. >=20 > irrelevant. there will always be new crashes, also outside kwin's > control. irrelevant for all implementations - also the existing ones. If we want= to be=20 secure against crashes introduced by dependencies we have to write some= thing=20 which does not link anything except Xlib. Of course KWin is a more comp= lex=20 application than others, but given what we need in a screen locker the=20= difference becomes marginal IMHO. >=20 > > I myself have never run into a situation where KWin did not restart= > > [...] >=20 > even if it restarts, you still have a non-trivial racing window. > additionally, it probably allows a waiting app (some popup) to grab > input and thus make the subsequent re-lock fail. ok, this is a concern I have not yet considered. Any ideas how we could= handle=20 such a situation? >=20 > the correct architecture, as far as i'm concerned: >=20 > 1) ideal solution: > - everything wayland > - user switching and consequently desktop locking are handled by kdm,= > which acts as the top-level wayland proxy server. the new process > structure within kdm is to be determined yet. > - no kwin involvment at all. kwin effect plugins may be used for some= > bling. agree on this ideal solution which fails at point one >=20 > 2) suboptimal solution (kicks in when no wayland-enabled kdm runs): > - the saver engine (which currently resides in krunner for historical= > reasons) is made stand-alone > - the lock engine is re-integrated into the saver engine, thus removi= ng > the now obsolete process separation (it was only meant to isolate t= he > locker from kdesktop/krunner crashes) > - if an X based compositing kwin is running: > - kwin is instructed to take the locker window and do something mag= ic > with it. same for the unlock dialog, plasma, etc. > - the residence and implementation (qwidget, plasma, qml) of the > unlocker dialog is orthogonal to kwin integration and can thus st= ay > where it is; the general architecture of the plasma overlay can b= e > retained and extended as needed > - if kwin crashes, there is only a short unredirection flash Having the locker outside of the compositor brings back the issues whic= h I=20 wanted to solve in the first place: * windows can get on top of the screen locker * screen is not correctly blanked * how to tell KWin about a screen locker window in a secure way? > - if a wayland based kwin is running: > - input handling is now a native task of the compositor, and a > crashing compositor takes the whole desktop down anyway, so it is= > reasonable to fully integrate the locker into kwin * that is one of the reasons why the lock screen work was started: havi= ng a=20 solution for both X and Wayland > - but for the same reason it may make sense to extract the core > compositor from the bigger kwin > - whether code sharing with the X based solution happens via source= > sharing and some #ifdefs, a small shared library with some virtua= ls, > or not at all, remains to be seen >=20 > > If you want to discuss about the screen saver animations please sta= rt > > a new thread and preferable not on kcd but on workspace relevant > > mailing lists such as kwin or plasma-devel. >=20 > in fact, kcd *is* the relevant list. you can dispute that if you agre= e > to assume full responsibility for kscreensaver-bugs-null@kde.org. well kcd is not the place anymore where the workspace development happe= ns.=20 That's what I meant. Cheers Martin --nextPart2940928.Zzyq9CcmDD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAk6UbzEACgkQqVXwidMiVrosngCfWMELpvcWvxS4dVC9bUPvVqX6 4yQAn2dz9Xpd0hETfKnmTEc5BUQG4acw =LbhT -----END PGP SIGNATURE----- --nextPart2940928.Zzyq9CcmDD--