From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Alessio Sangalli <alesan@manoweb.com>
Cc: linux-input@vger.kernel.org
Subject: Re: Equivalent of /dev/input/mice for keyboards
Date: Sun, 11 Jan 2009 23:32:46 -0800 [thread overview]
Message-ID: <20090111232539.ZZRA012@mailhub.coreip.homeip.net> (raw)
In-Reply-To: <495EA371.8050304@manoweb.com>
Hi Alessio,
On Fri, Jan 02, 2009 at 03:29:53PM -0800, Alessio Sangalli wrote:
> Hi, I have developed a PS/2 driver for a new ARM-based hardware.
>
> I have used the serio subsystem and I can test with input-event or
> similar programs that the keyboard and mouse I have connected work well.
>
> Now, this platform, being an embedded ARM board, does not have a
> "console" that can be attached to the keyboard. I only connect with
> serial port or telnet. And here I am getting confused: I can read one
> device at a time by opening /dev/input/event*.
>
> I would like to write my userspace application so that it gets all the
> input from the various keyboards (can be up to two PS/2 keyboards + USB
> ones) and process it. The struct input_event is very convenient but what
> I am doing now is to open all the event* devices and select() them. This
> wouldn't probably work if I connect/disconnect a device on the fly. It
> would be much easier if I had a device similar to input/mice that
> automatically does the muxing for me...
>
I am very hesitant adding such multiplexing device to the kernel. While
it is pretty easy to write one we had only pain from them. There are all
kinds of quirks, grabs, and workarounds because people are using
/dev/input/mice and console but at the same time want to use event
devices for some of the hardware.
I suppose we could make it depend on CONFIG_EMBEDDED and default to no
and have a big warning in the description that it is only supposed to be
used on embedded boards...
Doing select on event devices in userspace should actually work equally
well and you can either listen to netlink hotplug events or poll
/proc/bus/input/devices to detect when you need to add new device to the
mix. I would prefer this userspace solution.
--
Dmitry
next prev parent reply other threads:[~2009-01-12 7:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-02 23:29 Equivalent of /dev/input/mice for keyboards Alessio Sangalli
2009-01-12 7:32 ` Dmitry Torokhov [this message]
2009-01-12 21:14 ` Alessio Sangalli
2009-01-13 5:53 ` Dmitry Torokhov
2009-01-15 7:56 ` Alessio Sangalli
2009-01-15 8:33 ` 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=20090111232539.ZZRA012@mailhub.coreip.homeip.net \
--to=dmitry.torokhov@gmail.com \
--cc=alesan@manoweb.com \
--cc=linux-input@vger.kernel.org \
/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).