Gfilui

I'm working with a mouse USB driver and I really don't know how to difference and use information send by /dev/input/mouse0 and /dev/input/mice

After few search on Google, I've found a few code about using /dev/input/mice

int fd, bytes;
unsigned char data[4];

const char *pDevice = "/dev/input/mice";

// Open Mouse
fd = open(pDevice, O_RDWR);
if(fd == -1)

 printf("ERROR Opening %sn", pDevice);
 return -1;


int left, middle, right;
signed char x, y;

// Read Mouse
bytes = read(fd, data, sizeof(data));

if(bytes > 0)

 left = data[0] & 0x1;
 right = data[0] & 0x2;
 middle = data[0] & 0x4;

 x = data[1];
 y = data[2];
 printf("x=%d, y=%d, left=%d, middle=%d, right=%dn", x, y, left, middle, right);

 if(left)
 return left;
 if(right)
 return right;
 if(middle)
 return middle;


return 0;

This program works but didn't get any information about the wheel scroll

I was able to found a program which use /dev/input/event0

int fd;
struct input_event ev
const char* pFile = "/dev/input/event0";

fd = open(pFile, O_RDONLY);
if(fd == -1)

 printf("ERROR Opening %sn", pFile);
 return -1;


read(fd, &ev, sizeof(ev));
std::cout << "type : " << ev.type << " code : " << ev.code << " value : " << ev.value << std::endl;

close(fd);

return 0;

But there is a problem for diagonal movement because this file saved only 1 coordinate at same time, and X coordinate have priority on Y; so it's pretty annoying when you want to move your mouse on Y axis

However, I don't find any code to use /dev/input/mouse0, so what information are saved in this file?

So my questions are :
1. What information are saved in /dev/input/mouse0?
2. How can I read all mouse information without opening 2 files, and without priority problem (whell scrolling + X/Y axis movement)?

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.