wayland screen locker and security in general
spitzak at gmail.com
Wed Apr 6 10:12:51 PDT 2011
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
>> So is dbus absolutely required part of wayland then?
> 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
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.
More information about the wayland-devel