Enabling/disabling input events.

Enabling/disabling input events.

[Zephaniah E. Hull]

[-- Attachment #1.1: Type: text/plain, Size: 2066 bytes --]

The current trend is for events like power buttons and lid switches to
be handled through the input subsystem.

This leaves an odd hole for cases where you wish to set the hardware
behavior of these buttons, specificly on the OLPC we have several events
that signal through the input system, which are capable of waking the
system from suspend mode.  This is not always desirable, so the
hardware leaves us a way to disable the button/switch completely, but at
the moment there is no clean kernel interface for this.

This leaves the choices of adding a separate way to control things which
are delivered by the input system, which seems somewhat silly, or adding
support to the input system for enabling/disabling specific events from
an input device.

The latter seems more useful in the long run, but it leaves the question
of how to do it.

Between a few of us, we see a few possible ways to do it off the top of
our heads:

 - Adding controls somewhere off in /sys/class/input. (How do we handle
   notification of changes?)
 - Adding some ioctls to evdev. (Again, notification of changes?)
 - Writing events from userspace for these events, with odd values.
   (Ugly, easily confuses clients listening to those events who don't
   know what the odd values mean.)
 - Adding something like a EV_CTRL type, with CTRL_ENABLE_EVENT and
   CTRL_DISABLE_EVENT events, encoding the 16bit types and codes of the
   event we're enabling/disabling in the 32bit value. (How do we check
   the current value?  Doesn't fit the existing event model.)

All of these have ups and downs, and there are probably ways we have not
thought of.

So, our basic question is should this go through the input system, and
if so how should we go about implementing it?

Thank you.
Zephaniah E. Hull.

-- 
	  1024D/E65A7801 Zephaniah E. Hull <warp@aehallh.com>
	   92ED 94E4 B1E6 3624 226D  5727 4453 008B E65A 7801
	    CCs of replies from mailing lists are requested.

<Upholder> Seen on the back of a T-Shirt: "I am a bomb technician.  If you see
           me running, try to keep up."

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 133 bytes --]

_______________________________________________
Devel mailing list
Devel@laptop.org
http://mailman.laptop.org/mailman/listinfo/devel

Re: Enabling/disabling input events.

[Dmitry Torokhov]

Hi,

On Wednesday 25 April 2007 13:24, Zephaniah E. Hull wrote:
> The current trend is for events like power buttons and lid switches to
> be handled through the input subsystem.
> 
> This leaves an odd hole for cases where you wish to set the hardware
> behavior of these buttons, specificly on the OLPC we have several events
> that signal through the input system, which are capable of waking the
> system from suspend mode.  This is not always desirable, so the
> hardware leaves us a way to disable the button/switch completely, but at
> the moment there is no clean kernel interface for this.
>

Input layer (with the exception of keyboard repeat rate) presently
does not control underlying hardware, this task is left to individual
drivers. For example atkbd is responsible for changing keyboard set,
psmouse is responsible for setting desired report rate and resolution,
control various quirks of IBM trackpoint devices, etc. etc. There are
unlimited number of knobs that may be needed for various devices that
it is impossible to come up with standard interface.

I think enabling/disabling wakeup events belongs with the rest of
knobs in PM (ACPI?) subsystem.

-- 
Dmitry