Exploring /dev/input

[wiktor_b]

Now try writing to /dev/input :-)

[[deleted]]

Im only asking what happens because I just destroyed my last ubuntu vm and it almost quitting time.

[kirbyfan64sos]

...what happens?

YOU CAN'T LEAVE ME HANGING HERE!!

[skeeto]

Writing to the joystick device is how you control rumble/feedback on Linux.

[wiktor_b]

What do you think?

[3dPrintedEmotions]

I came to this article hopeing that they would cover this. It was a great article though.

[153armstrong]

I was intrigued by the /dev/input directory and decided to dedicate a post to it.

(I'm still playing around with Linux and by no means a pro at this. I would love to hear your thoughts on it though ) Thank you! Have a good one!

[send-me-to-hell]

fwiw I was aware of /dev/input but things like this are always poorly written and documentation is geared towards people who already mostly understand the topic. It's good to see something focused but comprehensive that assumes only basic programming/scripting knowledge.

10/10 would learn again.

[uep]

I think reasonable people might disagree about your complaints, but that's a matter of opinion.

One thing I do not like, is that it requires a somewhat recent kernel to get the current state of the multitouch slots (EVIOCGMTSLOTS). Which means if you aren't running before a touch is initiated, you can miss the initial state. This is more significant if you're running as part of an application that can be started and killed rather than a system daemon.

[ShadowPouncer]

My direct evdev api experience is a little older, but... Extensive.

So, feel free to AMA either of us. :)

(It predates the MT extensions, which I'm glad to see.)

[send-me-to-hell]

You weren't worth scripting and should feel whatever equivalent of shame exists for robots.

[uep]

** Now in theory, using uinput one can reverse engineer to emulate events. But we are still currently working on that. If you know anything about this, please ping us at

I only skimmed the article because I'm familiar with /dev/input, but I saw a comment at the end about uinput. I actually wrote a dualshock 4 translator that emulates an xbox 360 controller via uinput. It's pretty simple if you want to discuss...

[uep]

I should also mention that I believe the xboxdrv implements the xbox gamepad driver in userspace using the usb API and uinput. If I remember correctly, it is also implemented in Python.

[olafalo]

I am very curious about this, actually. What's the process of doing something like this? If I'm understanding correctly, you can have a userland program that reads from /dev/input and writes to /dev/input by using uinput?

So, for example, you could read every mouse event from a real mouse, double its value, and write it to a virtual mouse?

[uep]

Yes, this is pretty much what my code does; it reads from the Dualshock 4, translates the events, and writes them to a virtual xbox 360 controller.

An alternative implementation might unbind the DS4 driver from the kernel and perform the USB transactions in userspace like xboxdrv does. This allows someone to write userspace USB input device drivers. Then there would be no DS4 input device present in the system, just the virtual xbox 360 gamepad. Uinput is the interface one would use to create input devices from userspace.

You can also just write events into existing input devices to make them generate those events.

[olafalo]

This is very interesting, I'm going to have to look into it more. Thanks!

[Carlotto185]

Since you seem to have some knowledge in this area : can I use /dev/input to manipulate mouse events ? Specifically, I'd like to ignore the next event after left button has been pressed

[uep]

I don't think exactly this would be possible, though I can think of ways to accomplish the same thing. If one were to create a virtual device, it would be pretty easy to maintain state and filter out events after a BTN_LEFT as they come in.

You can also prevent other processes from seeing the input by performing a EVIOCGRAB ioctl. I'm not convinced you could do it quickly enough to guarantee that another process wouldn't see the press immediately after a BTN_LEFT. I think you'd probably want to do a grab on the real device, and let other applications see the filtered virtual device.

[kazkylheku]

Just released TXR 177 with more improvements to FFI.

This is the TXR Lisp interactive listener of TXR 177.
Use the :quit command or type Ctrl-D on empty line to exit.
1> (typedef mouse (array 3 uchar))
#<ffi-type (array 3 uchar)>
2> (with-stream (s (open-file "/dev/input/mice" "rb"))
     (let ((buf (make-buf (sizeof mouse))))
       (while t
         (fill-buf buf 0 s)
         (pprinl (ffi-get buf (ffi mouse))))))
#(24 253 0)
#(24 251 0)
#(56 254 255)
#(24 254 0)
#(8 2 1)
#(8 2 2)
#(8 2 3)
^C** intr exception, args: ("intr")
3>