Equivalent of /dev/input/mice for keyboards

Equivalent of /dev/input/mice for keyboards

[Alessio Sangalli]

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...

Thank you
Alessio

Re: Equivalent of /dev/input/mice for keyboards

[Dmitry Torokhov]

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

Re: Equivalent of /dev/input/mice for keyboards

[Alessio Sangalli]

Dmitry Torokhov wrote:

> 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.

Yes I appreciate your comments, I get your point.

What I would personally like to experiment with is:
- enabling this driver would automatically disable the other event
devices and the console, so it is the only source of input events for
the system
- to me it's also an exercise the helps the understanding of the input
layer and the kernel in general.

In my free time, I'd like to do the implementation, having in mind you
are not interested in merging it into the kernel. Would you spare some
hints on how you would proceed?

bye
as

Re: Equivalent of /dev/input/mice for keyboards

[Dmitry Torokhov]

On Mon, Jan 12, 2009 at 01:14:43PM -0800, Alessio Sangalli wrote:
> Dmitry Torokhov wrote:
> 
> > 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.
> 
> Yes I appreciate your comments, I get your point.
> 
> What I would personally like to experiment with is:
> - enabling this driver would automatically disable the other event
> devices and the console, so it is the only source of input events for
> the system
> - to me it's also an exercise the helps the understanding of the input
> layer and the kernel in general.
> 
> In my free time, I'd like to do the implementation, having in mind you
> are not interested in merging it into the kernel. Would you spare some
> hints on how you would proceed?
> 

I would take /dev/input/evdev.c as a base but instead of creating a new
character device in connect() method I would route all events into a
single device created upon module load (also see
drivers/input/mousedev.c). That should be really it.

-- 
Dmitry

Re: Equivalent of /dev/input/mice for keyboards

[Alessio Sangalli]

Dmitry Torokhov wrote:

> I would take /dev/input/evdev.c as a base but instead of creating a new
> character device in connect() method I would route all events into a
> single device created upon module load (also see
> drivers/input/mousedev.c). That should be really it.

Hi, I've spent a few hours trying to get it right. I am able to
"connect" the devices correclty but when it's time to open the devices I
get a file "No such device" error. The code is at:

http://pastebin.ca/1308960

and I think the problem is around evall_open (line 129). Probably just a
look of an experienced developer can give me some small indication what
to do to solve the issue.

Thank you
Alessio

Re: Equivalent of /dev/input/mice for keyboards

[Dmitry Torokhov]

On Wednesday 14 January 2009 23:56:33 Alessio Sangalli wrote:
> Dmitry Torokhov wrote:
> > I would take /dev/input/evdev.c as a base but instead of creating a new
> > character device in connect() method I would route all events into a
> > single device created upon module load (also see
> > drivers/input/mousedev.c). That should be really it.
>
> Hi, I've spent a few hours trying to get it right. I am able to
> "connect" the devices correclty but when it's time to open the devices I
> get a file "No such device" error. The code is at:
>
> http://pastebin.ca/1308960
>
> and I think the problem is around evall_open (line 129). Probably just a
> look of an experienced developer can give me some small indication what
> to do to solve the issue.
>

The way character devices are created by input core is tied very much
into existing handlers and is not very easy to plug into. I would
recommend creating a character device manually via misc_register() -
see how it is done in mousedev.c for psaux_mouse.

Also, I'd recommend getting rig of ioctl, write and grab code, they
don't make sense in context of multiplexor device and clutter the
code way too much.

Hope this helps.

-- 
Dmitry