How to implement OSD overlay in Wayland/Weston

[Greg V]

Nov 19, 2019 3:39:48 PM Simon Ser :
 
> On Tuesday, November 19, 2019 1:37 PM, Pekka Paalanen wrote:
> 
> 
>> On Tue, 19 Nov 2019 12:19:35 +0000
>> Simon Ser contact at emersion.fr wrote:
>> 
>> 
>>> On Tuesday, November 19, 2019 1:08 PM, Pekka Paalanen ppaalanen at gmail.com wrote:
>>> 
>>> 
>>>> On Tue, 19 Nov 2019 12:55:31 +0100
>>>> Guillermo Rodriguez guillerodriguez.dev at gmail.com wrote:
>>>> 
>>>> 
>>>>> Hi,
>>>>> El mar., 19 nov. 2019 a las 12:38, Sebastian Krzyszkowiak
>>>>> (dos at dosowisko.net) escribió:
>>>>> 
>>>>> 
>>>>>> On 11/19/19, Pekka Paalanen ppaalanen at gmail.com wrote:
>>>>>> 
>>>>>> 
>>>>>>> yes. I'm not aware of any Wayland extension that would allow clients to
>>>>>>> dictate always-on-top behaviour on the desktop. It has an obvious
>>>>>>> attack vector (malicious or misbehaving app setting always-on-top
>>>>>>> without user's consent) and a simple corner case (how do you stack
>>>>>>> multiple always-on-top windows).
>>>>>>> OSD as a concept seems like a desktop component, not a normal app.
>>>>>>> Hence I would expect such a client to use a domain-specific or custom
>>>>>>> protocol extension to set always-on-top. If your use case is not a
>>>>>>> generic desktop but some special environment, then a domain-specific
>>>>>>> protocol extension would be a way to go. For generic desktop
>>>>>>> environments you'd integrate with the particular DE specifically, e.g.
>>>>>>> a gnome-shell plugin or something.
>>>>>>> That is, if the OSD really is an independent separate program and not a
>>>>>>> part of some fullscreen application.
>>>>>>> 
>>>>>> 
>>>>>> Sounds like something layer-shell protocol solves portably already.
>>>>>> 
>>>>> 
>>>>> That sounds interesting. Is that supported by Weston?
>>>>> 
>>>> 
>>>> No. Not yet at least.
>>>> 
>>> 
>>> layer-shell's goal is to provide a way to create portable desktop
>>> components, so it indeed seems like it's a nice fit for this use-case.
>>> Note that for security reasons access to layer-shell could be
>>> restricted, so layer-shell shouldn't be used by regular clients.
>>> 
>> 
>> Yeah, if it can be implemented without messing up the normal shell
>> functions or needing consideration in shell plugins, that might be even
>> upstreamable into Weston.
>> 
> 
> That would be nice. CC'ing myfreeweb.
 
I haven't used Weston in almost a year now, due to discovering Wayfire :)
 
I wrote an implementation of layer-shell for Weston back then, but it's 1) not really compliant, only sort of working 2) written in C++ so not upstreamable. But feel free to look at it, might be useful as a "how to do this in Weston" example.
 
https://github.com/myfreeweb/weston-extra-dip/blob/master/layer-shell.cpp
 
On the positive side, it was integrated with my capability based access control plugin (in the same repo), so maybe that's some extra inspiration.
 
Basically my idea of how access control should work is that sets of capabilities are attached to clients, and the "desktop environment" process launched by the compositor gets all capabilities, and it can spawn clients (sockets) that have any subset of its capabilities. You could get by without the spawn-with-subset thing of course, but I think it's cool because e.g. the DE's launcher now gets to decide which apps can get privileged access, and it can see that some system-installed app is a special widget that the user wants to overlay, and decide to spawn it on a socket with the layer-shell overlay capability. Also an interesting observation: capabilities can be very granular, you can only require the capability for the overlay layer (probably top too) but not bottom, so desktop widgets like conky would not require privileges.