From: "Zephaniah E. Hull" <warp@aehallh.com>
To: Dmitry Torokhov <dtor@insightbb.com>
Cc: linux-input@ATREY.KARLIN.MFF.CUNI.CZ, devel@laptop.org
Subject: Enabling/disabling input events.
Date: Wed, 25 Apr 2007 13:24:54 -0400 [thread overview]
Message-ID: <20070425172454.GD4831@aehallh.com> (raw)
[-- 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
next reply other threads:[~2007-04-25 17:24 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-25 17:24 Zephaniah E. Hull [this message]
2007-04-28 13:05 ` Enabling/disabling input events Dmitry Torokhov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070425172454.GD4831@aehallh.com \
--to=warp@aehallh.com \
--cc=devel@laptop.org \
--cc=dtor@insightbb.com \
--cc=linux-input@ATREY.KARLIN.MFF.CUNI.CZ \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).