I think media players and other applications should have a unified interface (DBus maybe?) to request enabling and disabling screen locking.
I'm sorry by my very bad english. 2010/12/10 Sam Spilsbury <[email protected]> > On Fri, Dec 10, 2010 at 11:53 PM, Marty Jack <[email protected]> wrote: > > > > > > On 12/10/2010 10:38 AM, Sam Spilsbury wrote: > >> On Fri, Dec 10, 2010 at 10:21 PM, Marty Jack <[email protected]> > wrote: > >>> There have been hints that client side input processing should be the > norm in Wayland. This makes a lot of sense if client side drawing is the > norm. > >>> > >>> This is a Big Decision with quite a lot of implications and it needs > some design thought. > >>> > >>> Let's take a look at what input processing happens now in the X server > >>> - DPMS gets activated when there isn't any input for a time period > >>> - Screensaver gets activated when there isn't any input for a time > period > >>> - Input device button remapping > >>> - Input device coordinate acceleration > >>> - Keyboard scan code to Unicode character plus modifiers, conditioned > on a complex keyboard map > >>> - Keyboard autorepeat, including per-key configuration (this may be > overkill now) > >>> - Accessibility features (StickyKeys, SlowKeys, MouseKeys, BounceKeys, > etc.) > >>> - I am confident I have overlooked something > >>> > >>> For one thing, it means that all toolkits have to agree, and they all > have to have code that implements the same semantics. Including, for > example, the Wayland equivalent of FLTK, if such a thing were to exist, or > an application that uses Wayland directly, like maybe a game. > >>> > >>> This makes the XSetting problem worse. Now, not only do we have "My > GTK theme is Daisies, please" stored there, but we have all of this > input-side configuration that absolutely has to be honored if keymaps or > autorepeat or accessibility is going to work everywhere. So if this is > going to be done, we need a good system-wide XSetting replacement. I wonder > if shared memory isn't the way to go, if the drawing is done with shared > memory transport. > >>> > >>> I don't think we want every client to be running the equivalent of > setxkbmap and xkbcomp every time a client starts so it can do keyboard > mapping. > >>> > >>> Concerning system wide inactivity timers: > >>> > >>> Right now there are two measures that I know of concerning system wide > inactivity. One is measured by "was there any activity on the input > devices" and controls DPMS and Screensaver. Sometimes it gets this wrong, > such as when you are watching a movie, and there has been a workaround that > disables the screensaver that things like movie players can use. > >>> > >>> Another is measured by "was there a CPU load above a certain threshold" > that is used by the power manager to implement "take this power action if > the system is idle for this period". This can be wrong also, I had someone > ask how to keep their system from hibernating while it was doing a long file > transfer, that apparently didn't cause enough load to trigger the threshold. > Also this requires the power manager to wake up often to take the load > sample, which is counterproductive. > >>> > >>> It occurs to me that the kernel is is the best position to measure > inactivity, if we were to rearchitect this a little. > >>> > >> > >> Client side input processing is problematic if you want to do any kind > >> of meaningful input redirection on the side of the compositor. If the > >> compositor cannot get all of the events first then this means that it > >> cannot enforce certain window management policies. > >> > >> Regards, > >> > >> Sam > >> > >>> _______________________________________________ > >>> wayland-devel mailing list > >>> [email protected] > >>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel > >>> > >> > >> > >> > > > > Another item I should have brought up is how the screensaver timeout is > used. In this day and age of LCDs it is far less useful as a means to keep > the screen from burning in, and is most often used to cause a screen locking > application to get control. > > > > There is an opportunity to do this right as well. If I remember my > Orange Book correctly there is a certification need to reliably (as in, > provably minimize failure potentials) prevent access to a session after some > time period without reauthentication. We have some application developers > such as xscreensaver who (rightly) point out that a full toolkit is a large > failure surface to have exposed. > > > > So if we have the correct mechanisms to get a lock screen started in > conjunction with whatever part of the system does logins and new sessions > and switching users, that would be a good step. > > > As a slightly unrelated note, wasn't it decided to put screen locking > as part of the function of the system compositor? This way there would > be no way to bypass it. > > Kind Regards, > > > > > > > -- > Sam Spilsbury > _______________________________________________ > wayland-devel mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > -- Vinícius dos Santos Oliveira Linux user #481186 Member of COMPE - Laboratório de Computação Pervasiva. Instituto da Computação at Universidade Federal de Alagoas Maceió, Alagoas, Brazil "*The man who has no imagination has no wings*" -Muhammad Ali "*Freedom is the oxygen of the soul*" -Moshe Dayan "*Without freedom, no one really has a name*" -Milton Acorda
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
