Wayland protocols

[Martin Gräßlin]

On Tuesday 19 August 2014 10:51:43 Pier Luigi Fiorini wrote:
> On Monday 18 August 2014 18:22:42 Martin Gräßlin wrote:
> > On Monday 18 August 2014 17:48:03 Pier Luigi wrote:
> > > 2014-08-15 7:35 GMT+02:00 Martin Gräßlin <mgraesslin at kde.org>:
> > > > * concerning the lock/unlock: I would like to have the lock way better
> > > > integrated in KWin. That is KWin should be responsible for locking and
> > > > nobody else. My though is that KWin takes over the screen locker dbus
> > > > interface and starts the screenlocker greeter  when it's needed. It
> > > > could
> > > > pass a dedicated fd to greeter and thus would know that it's the lock
> > > > screen surface implicitly. That way we would not need a protocol at
> > > > all
> > > > and it's completely controlled by KWin.
> > > 
> > > How do you know its wl_surface?
> > > 
> > > Would be better to move lock/unlock to a separate .xml file and have
> > > ksmserver handle that imho.
> > > kwin or any other compositor would recognize the surface by its role
> > > then.
> > 
> > I had thought about it over the weekend how it could work:
> > *) ksld gets split into an own library
> > *) kwin uses this ksld library
> > *) ksld gets extended so that we can provide additional arguments to be
> > passed to the greeter
> > *) we pass the fd or socket name to the greeter
> > *) any wl_surface coming over this fd with the greeter's pid is a lock
> > screen surface
> > (maybe only providing the fullscreen protocol for this socket)
> 
> Feel like you are reinventing libwayland here.

Not reinventing, but using libwayland to have a second dedicated interface for 
the greeter process.

> 
> > What's important to me is to have the lock screen absolutely secure and
> > that includes that in KWin I do not want to trust any other process and
> > especially want to have the basics around screen locking inside KWin and
> > being controlled by KWin. As soon as the screen is supposed to be locked,
> > the input processing must stop, no matter whether the greeter is ready or
> > not. If we leave it in ksmserver there will always be a timing vector and
> > also the problem of knowing when to unlock - attacking the greeter should
> > not result in chances to unlock the screen.
> 
> The lock/unlock protocols serves exactly this purpose, here's a verbose
> description of how it works:
> 
> *) ksmserver is a Wayland client that binds kf5_shell
> *) ksmserver is asked to lock (via loginctl, plasmoid or context menu)
> *) ksmserver calls the kf5_shell.lock request
> *) kwin hides all surfaces, prevent input and maybe turn the screen off,
> this is all independent from the greeter being running or not
> *) kwin emits the prepare_lock_surfaces and ksmserver picks it up
> *) ksmserver runs the greeter which will create the surfaces
> *) ksld use set_surface_role to set the lock role on those surfaces

how does ksld know about the surfaces? They are created by the greeter 
process. If that requires to pass surface information between ksmserver and 
the greeter I'm wondering what we gain compared to letting KWin handle it 
directly.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20140819/7a71444b/attachment.sig>