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