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. _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
