What determines permissions in /dev?

A more flexible way to manage permission on files is to use ACL.

sudo setfacl -m u:popey:rw /dev/input/eventx

If you really need to make this permanent then you can use an udev rules that set it for your event input device

add a file /etc/udev/rules.d/99-userdev-input.rules with:

KERNEL=="event*", SUBSYSTEM=="input", RUN+="/usr/bin/setfacl -m u:popey:rw $env{DEVNAME}"

you can check the ACLs permission with

getfacl /dev/input/event*

I don't know what initially sets the permissions of the character devices /dev/input/event*

but, I do know you can change those permissions with a software which is on your system by default as part of coreutils. see the command man mknod.

The permissions of my event devices are:

crw-rw---- 1 root input 13, 64 Apr 14 06:39 /dev/input/event0

here are some usage examples:

~$ sudo mknod lolwat c 4 64 
~$ sudo mknod lolwatnow c 4 64  -m 777
~$ ls -l lolwat*
crw-r--r-- 1 root root 4, 64 Apr 14 08:07 lolwat
crwxrwxrwx 1 root root 4, 64 Apr 14 08:08 lolwatnow

if you need more info about for deciding on major and minor numbers, look here

Now, you say the permissions are wrong. So something must be setting them wrong, and that thing, must run as root. mknod could be used to create an device, but mkdev could also. you may want to look at the permissions of whatever the default actions are for mkdev, and mknod.

As in my examples: /dev/input/event0 has crw-rw permissions, but the default permissions, of lolwat were set to crw-r--r--

I have some uncertainty, whether type of device dictates original permissions.You can experiment with this to find out.

Here is another link for more info about mknod

Basically, you'd need to add a file in /etc/udev/rules.d/ (you could name it something like 75-input-events.conf)

And add lines KERNEL=="eventX" , SUBSYSTEM=="input", MODE="0777" for each event into that file, where x is the number. For instance, I have events 0 through 9, so I personally would do for each one of them. Last answer on this thread suggest you could have added KERNEL==event* (i.e., with wild card),too.

In a terminal run:

sudo nano -b /etc/rc.local

Go down to the line that says "exit 0" and in a line above it type:

sudo chmod a+r /dev/input/event

Hit Ctrl+x to exit that. It will ask you if you want to save. Hit y. It will ask you what to save as. Just hit Enter.

Now, that command should start up at every boot and thus give you permissions to that folder. The /etc/rc.local file automatically has root privileges so you won't need to enter a password to do this.

My suggestion is that you install the application input-utils

sudo -i
apt-get update
apt-get install input-utils

This is a collection of utilities which are useful when working with the input layer of the Linux kernel (version 2.6 and later). Included are utilities to list the input devices known to the kernel, show the input events that are received by a device, and query or modify keyboard maps.

The command of interest is:

sudo -i 
lsinput

It dumps out all the input devices and the associated details about the device.

One can observe input events using the command, by specifing the Nth device number:

sudo -i
input-events <device number>

One can then dump out the keyboard mapping of a particular event device using the command ,by specifing the Nth device number:

sudo -i
input-kyb <device number>

With these tools one can debug a system to see if inputs generate the expected event codes and hence help sort out issues such as why keys don't work or are mapped incorrectly.

Udev is the device manager for the Linux kernel. It manages device nodes in /dev and handles all user space actions when adding or removing devices.

Evdev is a generic input event interface in the Linux kernel.It generalizes raw input events from device drivers and makes them available through character devices in the /dev/input/ directory.

Every time a change happens within the device structure, the kernel emits a uevent which gets picked up by udev. udev then follows the rules as declared in the /etc/udev/rules.d, /run/udev/rules.d and /lib/udev/rules.d directories.

Based on the information contained within the uevent, it finds the rule or rules it needs to trigger and performs the required actions.

These actions can be creating or deleting device files, but can also trigger the loading of particular firmware files into kernel memory.