The Linux Input Subsystem userspace API documentation answers your questions. In general, all files in /dev/input/
are provided by event handlers that distribute device events to userspace.
What are /dev/input/mouse0 and /dev/input/mice?
From the introduction (important parts highlighted by me)
1.3.1.3. mousedev
mousedev is a hack to make legacy programs that use mouse input work. It takes events from either mice or
digitizers/tablets and makes a PS/2-style (a la /dev/psaux) mouse
device available to the userland.
Mousedev devices in /dev/input (as shown above) are:
crw-r--r-- 1 root root 13, 32 Mar 28 22:45 mouse0
crw-r--r-- 1 root root 13, 33 Mar 29 00:41 mouse1
crw-r--r-- 1 root root 13, 34 Mar 29 00:41 mouse2
crw-r--r-- 1 root root 13, 35 Apr 1 10:50 mouse3 ...
...
crw-r--r-- 1 root root 13, 62 Apr 1 10:50 mouse30
crw-r--r-- 1 root root 13, 63 Apr 1 10:50 mice
Each mouse
device is assigned to a single mouse or digitizer, except the last one
- mice. This single character device is shared by all mice and digitizers, and even if none are connected, the device is present.
This is useful for hotplugging USB mice, so that older programs that
do not handle hotplug can open the device even when no mice are
present.
[...]
Mousedev will generate either PS/2, ImPS/2 (Microsoft IntelliMouse) or ExplorerPS/2 (IntelliMouse Explorer) protocols, depending on what the program reading the data wishes. You can set GPM and X to any of these. You’ll need ImPS/2 if you want to make use of a wheel on a USB mouse and ExplorerPS/2 if you want to use extra (up to 5) buttons.
...this could also be reason why you don't see mouse wheel events. Since it is "a hack" for legacy programs, you shouldn't use it if you don't have to.
How can I read all mouse information [...]?
Use the corresponding /dev/input/eventX
file which is provided by evdev (the event handler, not to be confused with the xorg-driver evdev). That's what your second code snippet obviously does.
...but what about the priority problem?
There is no priority problem. According to 2.2. Event codes:
SYN_REPORT:
Used to synchronize and separate events into packets of
input data changes occurring at the same moment in time. For example,
motion of a mouse may set the REL_X and REL_Y values for one motion,
then emit a SYN_REPORT. The next motion will emit more REL_X and REL_Y
values and send another SYN_REPORT.
Because all consecutive events until a SYN_REPORT
event can be considered to have happened at the same time, the order in which they are reported doesn't matter.
For example (using this program I found on github):
time:1528290186.256449 type:EV_REL code:REL_X value:-1
time:1528290186.256449 type:EV_REL code:REL_Y value:1
time:1528290186.256449 type:EV_SYN code:SYN_REPORT value:0
time:1528290186.264460 type:EV_REL code:REL_Y value:1
time:1528290186.264460 type:EV_REL code:REL_WHEEL value:-1
time:1528290186.264460 type:EV_SYN code:SYN_REPORT value:0
As you can see, not only are concurrent events separated by SYN_REPORT
events, they also have the same time stamp.
By the way, you can also use evtest
to see the events generated by a device. You can find its source code here if you are interested in how it works.
Best Answer
You may use the tool
lsinput
that you can get installing the packageinput-utils
.