mir_demo_server* successfully start without input support as non-root, making them unusable

AFAIK, this was intentional. Mir starts best-effort. And if you're not root then you won't get access to input devices.

Though I think we probably should make that a fatal error and prevent Mir from starting...?

+1 on the fatal error idea. I fail to see the practical use of the best-effort idea, if the best effort locks you out of your machine

Alternatively we should ask racarr/RAOF if it's possible to get input working for non-root on desktop.

It's not possible to get input working for non-root without allowing everyone to snoop on your input; that's not something we can turn on by default.

We *could* install mir_demo_server_shell setuid root, though.

Probably best to just make failure to open any input fatal, though.

On the various Nexus devices input works as non-root. What's the difference? Does that need *fixing* ?

It might need fixing, depending on whether input is multi-readable or not.

If you can open the input device twice, and get events from both fds, then being able to access the input devices means you can capture input.

We nearly fixed this problem when we switched to input platform probing and dropped the android code base for input reading. With that change there is now code that throws if there is no input platform available to use. Thats the case when no input device is readable and when there is no X11 connection.
A server with insufficient permission to read input could still be stuck when a joystick is connected. Then, because udev rules make that device readable for users and we do start up. This might be a feature for kiosk use cases...

Confirmed this bug is still happening. And it's not as easy as exiting if there are zero input drivers. Because the input driver loads (just does not respond to any input):

[2016-03-01 17:17:06.258314] mirserver: Selected input driver: mir:evdev-input (version: 0.20.1)

@duflu: Hum I get an exception "no input platforms found" as mir::evdev-input is not allowed to open any input device in /dev/input. Is it possible that you have a device that can be opened for reading as a user?

We could also add an automatic shutdown when we have input platforms that claim to work but no input devices available.. This would cover the case that udevd has devices tagged as input, that the server might be able to read from, but which libinput rejects due to lack of support.

The current startup probing only asks udev and tries to open the results.

Comment #9: Maybe I got a bit further with permissions because I was logged in on VT1 first.

Still happening...

Syncing task from Mir.