Skip to contentSkip to conversation

Equivalent of /dev/input/mice for keyboards

DISCUSSION Alessio Sangalli 2 participants 6 messages Jan 2, 2009 – Jan 15, 2009 HID

lore
Share & tools
lore
#0 lore raw

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

#1 lore raw

Hi Alessio,

Quoted 10 lines · 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*.

Quoted 8 lines

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.

Signature · 1 line
Dmitry
#2 lore raw
Quoted 5 lines · Dmitry Torokhov

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

#3 lore raw
Quoted 17 lines · Alessio Sangalli
Quoted 5 lines · Dmitry Torokhov

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.

Quoted 4 lines

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.

Signature · 1 line
Dmitry
#4 lore raw
Quoted 4 lines · Dmitry Torokhov

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

#5 lore raw
Quoted 10 lines · On Wednesday 14 January 2009 23:56:33 Alessio Sangalli wrote:
Quoted 4 lines · Dmitry Torokhov

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:

Quoted 6 lines

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.

Signature · 1 line
Dmitry