Client side input processing

Fri Dec 10 09:15:00 PST 2010

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 <smspillaz at gmail.com>

> 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
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20101210/9038a370/attachment-0001.html>