Client side input processing

[Sam Spilsbury]

On Fri, Dec 10, 2010 at 10:21 PM, Marty Jack <martyj19 at comcast.net> 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
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>



-- 
Sam Spilsbury