Client side input processing

[Sam Spilsbury]

On Fri, Dec 10, 2010 at 11:53 PM, Marty Jack <martyj19 at comcast.net> wrote:
>
>
> On 12/10/2010 10:38 AM, Sam Spilsbury wrote:
>> 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
>>>
>>
>>
>>
>
> 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