Wayland protocols

[Martin Gräßlin]

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>:
> > On Thursday 14 August 2014 21:05:01 Marco Martin wrote:
> >> On Thursday 14 August 2014, Pier Luigi wrote:
> >> > Hi,
> >> > 
> >> > Just pushed some initial draft of the Wayland protocols on Github [1]
> >> > 
> >> > I need people with knowledge of KF5 and plasmashell to comment it and
> >> > suggest improvements.
> >> 
> >> just some quick comments after taking a quick glance at
> >> https://github.com/plfiorini/protocols/blob/master/shell.xml
> >> 
> >> since i'm just getting into it now, those question are mostly to
> >> understand
> >> it better myself ;)
> >> 
> >> * set_position
> >> since often is needed to set position and size, maybe a set_geometry that
> >> does all in one go?
> >> 
> >> * set_grab_surface
> >> just little clarification: "The surface set by this request will receive
> >> a
> >> fake pointer" what exactly is its use case?
> >> 
> >> * set_desktop_role/set_config_role etc
> >> maybe set_surface_role(output, surface, enum role) ?
> >> 
> >> * prepare_lock_surfaces: why a separate step from lock()?
> >> 
> >> * quit: would that be equivalent to logging out?
> > 
> > some more thoughts:
> > * set_overlay_role: should we make the name more explicit:
> > set_on_screen_display_role?
> 
> I like set_overlay_role (well the overlay enum value for
> set_surface_role now), less verbose but still understandable.
> 
> > * 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)

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.

> 
> > * add_trusted_client: I kind of don't understand how that's supposed to
> > work. Where's the fd coming from and how does the shell user know about
> > it?
> It's the fd of a socket to the Wayland server open by the client that
> need to be trusted.
> 
> This comes from Weston having the screenshooter interface and a screenshot
> tool. The idea was to forbid clients not in the whitelist to use that
> interface and thus avoid malicious programs to capture your screen.
> A shell would open the screenshooter program when it needs to do a
> screenshot and add it to the whitelist.
> 
> This can probably go away although I don't know how ksnapshot will
> work on Wayland.

ah well - I know there was a discussion about handling such clients. Not to 
myself: read those mails ;-) In general I'm not a fan of whitelists as that 
makes everything just more complex - we allow ksnapshot, but what about krita?

My suggestion would be to keep that as a questionmark till the XDC where I 
could get some briefing by the people working on it ;-)

Cheers
Martin
-------------- 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/20140818/ebb032a7/attachment.sig>