uinput example doesn't work under ubuntu 14.04

[LuisDiazUgena]

Hi!

I've been able to install uinput by following comments on this issue [https://github.com/tuomasjjrasanen/python-uinput/issues/3] and I wanted to try the library.

After a copy&paste on a new file, I've started (or at least I think so) uinput kernel module (I've tried with modprobe uinput, modprobe -i uinput and sudo modprobe -i uinput.

When I run the file with the keyboard example a error appears:

~/Keyboard emulator/python script/$ python keyboard-emulator.py Traceback (most recent call last): File "keyboard-emulator.py", line 4, in with uinput.Device([uinput.KEY_E, uinput.KEY_H,uinput.KEY_L, uinput.KEY_O]) as device: File "/usr/local/lib/python2.7/dist-packages/uinput/init.py", line 175, in init self.uinput_fd = _libsuinput.suinput_open() File "/usr/local/lib/python2.7/dist-packages/uinput/__init.py", line 70, in _open_error_handler raise OSError(code, msg) OSError: [Errno 13] Failed to open the uinput device: Permission denied

If I use sudo, there is no error, but there is also no visible input. I think there is maybe some issue with terminal, so I've added a 5 seconds delay and moved to a text editor but still nothing.

I've tried also the mouse example, but the same errors appears.

What should I do?

Thanks!

[tuomasjjrasanen]

The error OSError: [Errno 13] Failed to open the uinput device: Permission denied is expected, because by default, /dev/uinput is normally readable/writable only by root. So in order to use uinput, you either have to be root, or you have to change the group and/or permissions of /dev/uinput.

But the case where you run the example with sudo with no visible effects is more interesting. There's couple of ways to debug the issue:

1. Switch to any virtual terminal (Ctrl + Alt + F3 for example) and login. Run sudo python keyboard.py there. Does anything get printed?

2. Install evtest package. Edit keyboard.py and increase the sleep time to say 15secs or more. Run sudo python keyboard.py and then in another terminal run sudo evtest. It should list python-uinput as one of the devices (probably the last in the list). Select it and wait until the sleep expires in keyboard.py. evtest should print something like this:

   Event: time 1443032198.289810, type 1 (EV_KEY), code 35 (KEY_H), value 1 Event: time 1443032198.289810, type 1 (EV_KEY), code 35 (KEY_H), value 0 Event: time 1443032198.289810, -------------- EV_SYN ------------ Event: time 1443032198.289889, type 1 (EV_KEY), code 18 (KEY_E), value 1 Event: time 1443032198.289889, type 1 (EV_KEY), code 18 (KEY_E), value 0 Event: time 1443032198.289889, -------------- EV_SYN ------------ Event: time 1443032198.289931, type 1 (EV_KEY), code 38 (KEY_L), value 1 Event: time 1443032198.289931, type 1 (EV_KEY), code 38 (KEY_L), value 0 Event: time 1443032198.289931, -------------- EV_SYN ------------ Event: time 1443032198.289960, type 1 (EV_KEY), code 38 (KEY_L), value 1 Event: time 1443032198.289960, type 1 (EV_KEY), code 38 (KEY_L), value 0 Event: time 1443032198.289960, -------------- EV_SYN ------------ Event: time 1443032198.289983, type 1 (EV_KEY), code 24 (KEY_O), value 1 Event: time 1443032198.289983, type 1 (EV_KEY), code 24 (KEY_O), value 0 Event: time 1443032198.289983, -------------- EV_SYN ------------ Event: time 1443032198.290018, -------------- EV_SYN ------------

[LuisDiazUgena]

Hi!!

Thanks for your help.

With the first way, I still got nothing. I've runned with sudo and root user, but still nothing shows.

Using the second way, still nothing. There is no python-uinput in the list.

[Guha01Gubin]

I have the exact same problem, except my program is in c. I am developing a virtual keyboard program in Ubuntu 14.04, and the device just cannot get built simply because I do not have root privileges for uinput.

[tuomasjjrasanen]

@Guha01Gubin Like I explained earlier, /dev/uinput is readable and writable only by root by default. You should either run it as root, or modify /dev/uinput mode bits and/or owner/group.

[MEnthoven]

Hi, I have the same problem as @LuisDiazUgena.

For me it shows:

Input driver version is 1.0.1 Input device ID: bus 0x0 vendor 0x0 product 0x0 version 0x0 Input device name: "python-uinput" Supported events: Event type 0 (EV_SYN) Event type 1 (EV_KEY) Event code 18 (KEY_E) Event code 24 (KEY_O) Event code 35 (KEY_H) Event code 38 (KEY_L) Properties: Testing ... (interrupt to exit) Event: time 1470245126.875007, type 1 (EV_KEY), code 35 (KEY_H), value 1 Event: time 1470245126.875007, type 1 (EV_KEY), code 35 (KEY_H), value 0 Event: time 1470245126.875007, -------------- EV_SYN ------------ Event: time 1470245126.875077, type 1 (EV_KEY), code 18 (KEY_E), value 1 Event: time 1470245126.875077, type 1 (EV_KEY), code 18 (KEY_E), value 0 Event: time 1470245126.875077, -------------- EV_SYN ------------ Event: time 1470245126.875128, type 1 (EV_KEY), code 38 (KEY_L), value 1 Event: time 1470245126.875128, type 1 (EV_KEY), code 38 (KEY_L), value 0 Event: time 1470245126.875128, -------------- EV_SYN ------------ Event: time 1470245126.875177, type 1 (EV_KEY), code 38 (KEY_L), value 1 Event: time 1470245126.875177, type 1 (EV_KEY), code 38 (KEY_L), value 0 Event: time 1470245126.875177, -------------- EV_SYN ------------ Event: time 1470245126.875223, type 1 (EV_KEY), code 24 (KEY_O), value 1 Event: time 1470245126.875223, type 1 (EV_KEY), code 24 (KEY_O), value 0 Event: time 1470245126.875223, -------------- EV_SYN ------------ expected 16 bytes, got -1

evtest: error reading: No such device

What can i do to fix this?

If its of any interest, I have used VNC and SSH and OS is Raspian Jessie

[viczar]

I had this problem in Arch, had this exact problem with the keyboard example and solved it by adding a time.sleep(1) before sending the inputs

[HiggsWRX]

@vagol942 thank you! I am under arch and I was having the same problem. Your suggestion fixed it.

[viczar]

@HiggsWRX I'm glad. This is interesting, I thought it might be something related to my machine, but it seems the Device creation involves a non blocking process; thus the program continues before the input file has fully initialized.

[marcosps]

It worked in my machine (Fedora 25), but I first needed to load uinput module, so udev can successfully found uinput module in misc class(aka /sys/class/misc/uinput).

[hajungong007]

hi I do this sudo addgroup uinput sudo adduser $USER uinput and restart the machine

[multimeric]

I had this problem in Arch, had this exact problem with the keyboard example and solved it by adding a time.sleep(1) before sending the inputs

This also worked for me, and I'm on a vanilla Ubuntu setup. It seems like we need a way to wait for the device to be created. Does this need to be fixed upstream in https://github.com/tuomasjjrasanen/libsuinput?

[robin-a-meade]

Expanding on @hajungong007 's solution to the "Permission denied" error, here's my complete solution for Fedora 30:

Create a group designated for users that can read/write to /dev/uinput. The particular name doesn't matter.

sudo groupadd uinput

Add users to ths new group. Start with yourself:

sudo usermod -a G uinput "$USER"

Permissions before:

$ ls -ld /dev/uinput
crw-------. 1 root root 10, 223 Oct  5 17:52 /dev/uinput

Change group ownership and permissions on /dev/uinput:

sudo chmod g+rw /dev/uinput
sudo chgrp uinput /dev/uinput

Permissions after:

$ ls -ld /dev/uinput
crw-rw----. 1 root uinput 10, 223 Oct  5 17:56 /dev/uinput

[njourdane]

I had a similar problem on Arch, solved it by enabling uinput with modprobe:

sudo modprobe uinput
sudo python keyboard.py

[sa1d]

I would like to mention about two things. Firstly, the part in @robin-a-meade 's comment

Add users to ths new group. Start with yourself:

sudo usermod -a G uinput "$USER"

should be (there is a dash missing)

sudo usermod -a -G uinput "$USER"

After that everything works, considering time.sleep(1) is inserted -per other comments- after the uinput.Device creation, i guess it needs some time for initialization.

The second thing is, after a reboot, permissions and group ownership on /dev/uinput resets. You may have to run chmod and chgrp commands at startup with a cronjob hoping /dev/uinput is already created by the kernel driver by the time cronjob runs. With the recommendations above combined, the old example is still working without any problem.