/dev/input/mouse0 only readable by root?

The 2GB model image has a bug, /dev/input/mouse0 should be readable by user applications.

Now they have to run games as root.

hello tinspin,

could you please share the list details (i.e. $ ls -la ) and have comparison results of the Nano and its 2GB model.

It says “crw-rw---- 1 root input 13, XX nov 4 …” where XX is some sequential number, I don’t have a 4GB model.

hello tinspin,

may I know which JetPack release you’re working with,
you may check $ cat /etc/nv_tegra_release for release info,

I downloaded it today. It says R32 4.4 from Oct 16.

hello tinspin,

could you please also share your use-case, is there any failure messages for reference.

No, you need to have the streams in /dev/input as


See: Try my 3D MMO prototype

I “work around” (more like patch things up as well as I can) the issue by using the window mouse events as fallback, but in a 3D game you need the mouse to send events even when outside/at the border!

The reason you want the keyboard input to be user readable too is that you need that in order to make the game engine read input in a separate thread. Since we have 4 cores lets use them for other stuff than wasting 100% of one core on the compositor: Compton Compositor takes up 100% of one core - #3 by DaneLLL

This is working exactly as it should work. Nobody else is intended to own the mouse. However, notice that this is group “input”. To use the mouse without being root one can be a member of “input”. You won’t typically find anyone is a member of “input” though, and the udev system is used to tie input devices to X. My question is this: What is the motivation for asking the question? There is likely some subtle point which could be answered if the source of the problem is known, and root ownership of the “/dev” entry won’t be the actual problem.

I don’t know how it can be clearer than that, download the software and try to run it as root and not as root, you wont be asking questions after that.

Bascially: how can I get mouse movements outside of the window AND at the border of a window so that I can rotate infinitely in a 3D world? The same problem most products that have financed Nvidia and the computers in the first place have needed since DOOM, this makes this the oldest 3D problem to have at 27 years old now.

But as I usually say, if you don’t need root you’re probably not doing anything meaningful anyhow. I mean ports <1024 need root and now getting mouse and keypresses in another thread need root too. Not on Raspberry though because they understand the problem.

I don’t know what the fix is, but the window manager itself masks events or allows them to fall through. When an event is consumed it is masked and further software will never see the event. For example, if you stack three text terminals on top of each other, and run the command “ls”, the focused terminal will see the event, and the others will not…this is because the window manager itself did not allow “ls” to fall through to other windows. When the mouse is outside of the window, then the window manager stops that window from seeing events, and this is intended behavior.

There are applications which have modified event masks to allow the mouse to be seen from outside of the window being focused. The best demonstration of that is the “xeyes” program. This program basically is a pair of eyes which always look towards where the mouse is at, and is probably a good example to study if you want to see how the event masks are customized.

Keep in mind that this event customization is not a customization of the mouse driver, and those applications do not directly read the mouse events. Those mouse events are presented to X, and it is the X event code which is used to modify the behavior.

I think I know why this is a problem… on pi your user is pi by default and it seems the pi user is hardcoded to be part of the input thing…

On jetson you create a new account… and it does not get added to the input thing! There is the bug! But running with sudo solves this one so I digress!