wayland screen locker and security in general

[Bill Spitzak]

On 04/06/2011 03:00 AM, Joakim Sindholt wrote:
> On Wed, 2011-04-06 at 11:42 +0200, Michal Suchanek wrote:
>> 2011/4/5 Vinícius dos Santos Oliveira<vini.ipsmaker at gmail.com>:
>>
>>>> How will apps like mplayer/vlc/browsers-playing-videos tell the compositor
>>>> that they are "busy" drawing and that the lock should NOT be engaged even
>>>> though there hasn't been any keyboard/mouse activity for long stretches?  As
>>>> compared to "default" apps that just paint "im bored" over and over again,
>>>> where the idle lock should get switched on...
>>>
>>> Take a look at
>>> http://lists.freedesktop.org/archives/xdg/2009-April/010317.html
>>>
>>
>> So is dbus absolutely required part of wayland then?
>>
>> Thanks
>>
>> Michal
>
> No, but as it is a standard desktop component for IPC it seems fitting
> to use it. The specification is intentionally vague on the subject.

I would hope that all communication that affects the compositor goes 
through the same channel, ie the Wayland connection. Therefore I hope 
that email was to list the desired *messages*, not to imply that a 
client has to talk both to Wayland and to dbus!

Wayland probably should support arbitrary communication, by allowing the 
client and compositor to both set arbitrary "attributes" on objects they 
own. Changing the attributes or removing them cause events. Destruction 
of the object (such as when mplayer crashes, as given in the example) 
will also cause events so the screen will resume locking if the 
"inhibit" attribute was set on the window.

The attributes have a name, which may be a C string, or perhaps another 
Wayland object similar to the X "atoms".

I very much recommend the data be as simple as possible: the Wayland 
protocol treats all attribute values as arrays of bytes, although the 
api will place read data in aligned locations so the client can treat it 
as arrays of other types. There is no type info at all. It is also 
possible that zero-length arrays and "the attribute does not exist" are 
indistinguishable.

Clients and compositors must *NEVER* require any attribute to be set for 
the windows to work. They can only "improve" how the compositor works. 
They should also ignore unknown attributes, except possibly produce 
warnings if it looks like the name was mistyped.