hwdb: Make 3D mice work out-of-the-box

[hadess]

Applications that want to support 3D mice on Linux are expected to either use spacenavd and its library, or consume the HID output directly.

This patch makes it possible for a number of applications that use 3D mice directly to work out of the box, such as PrusaSlicer and its derivatives.

[hadess]

CC: @whot @bentiss

[poettering]

Hmm, is this really the way to go? We have native support for TakeDevice()/revoke in logind now, for hidraw devices (305272a). It appears flatpak folks are working on a portal to make hidraw devices accessible even for packaged apps. It appears to me that#s a much preferable solution for access to hidraw, over uaccess.

It's not clear to me whether we should give out uaccess at all anymore for hidraw devices, but if we should it probably should be limited to devices that are relatively far from regular input devices one might spy on. Question is: how far is a "3d mouse" (what is that even, never seen one?) away from "regular input device".

@whot what's your take on this?

[hadess]

It appears flatpak folks are working on a portal to make hidraw devices accessible even for packaged apps. It appears to me that#s a much preferable solution for access to hidraw, over uaccess.

As far as I know, this is at least 6 months away from being available to users, if it has already landed upstream, but there would still be a whole stack that needs to be hooked up, whether it's the apps, the compositor, the portal...

We can always remove this when the portal support is sufficiently mature. But it looks to be pretty far away at this stage.

It's not clear to me whether we should give out uaccess at all anymore for hidraw devices, but if we should it probably should be limited to devices that are relatively far from regular input devices one might spy on. Question is: how far is a "3d mouse" (what is that even, never seen one?)

I've linked to Wikipedia in the hwdb file to answer that question. It's a 6 degrees-of-freedom controller, usually used for 3D apps (CAD, 3D previews, etc.)

away from "regular input device".

It's to the level of joystick and other game controllers, or macro pads like the ones already tagged ID_AV_PRODUCTION_CONTROLLER. Another option would be to mark all those devices as joysticks,

[whot]

line 44 lists the allowed properties, would be nice to add this one there.

A few nitpicks, haven't compared the list for pids but I trust you there and the approach LGTM - at least until all the hidraw bits are in place.

[hadess]

I've linked to Wikipedia in the hwdb file to answer that question. It's a 6 degrees-of-freedom controller, usually used for 3D apps (CAD, 3D previews, etc.)

I've added a link to wikipedia in the commit message.

[hadess]

line 44 lists the allowed properties, would be nice to add this one there.

Done.

[hadess]

As far as I know, this is at least 6 months away from being available to users, if it has already landed upstream, but there would still be a whole stack that needs to be hooked up, whether it's the apps, the compositor, the portal...

@whot do you have an ETA/progress on the whole stack being ready for use?

[whot]

@whot do you have an ETA/progress on the whole stack being ready for use?

not really, got side-tracked with a few other things, need to figure out what the portal plans (vs wayland protocol?) are again on all this. Either way, I'd say it's not going to be in the next GNOME release unless someone picks it up in time, might make it into the one after that.

[whot]

what is the device tagged as atm? Is it already ID_INPUT_MOUSE (and handled by libinput as such?) or does it have any ID_INPUT tags at all? If we're defining a new attribute we might as well define our expectations like we did for ID_INPUT_TRACKBALL (see line 53+).

[hadess]

Shows up as a joystick with 6-axis:

P: /devices/virtual/misc/uhid/0005:256F:C63A.0012
M: 0005:256F:C63A.0012
R: 0012
U: hid
V: hid-generic
E: DEVPATH=/devices/virtual/misc/uhid/0005:256F:C63A.0012
E: SUBSYSTEM=hid
E: DRIVER=hid-generic
E: HID_ID=0005:0000256F:0000C63A
E: HID_NAME=SpaceMouse Wireless BT
E: HID_PHYS=3c:e9:f7:60:d8:48
E: HID_UNIQ=cb:a6:c9:1b:6f:7d
E: MODALIAS=hid:b0005g0001v0000256Fp0000C63A

P: /devices/virtual/misc/uhid/0005:256F:C63A.0012/hidraw/hidraw6
M: hidraw6
R: 6
U: hidraw
D: c 241:6
N: hidraw6
L: 0
E: DEVPATH=/devices/virtual/misc/uhid/0005:256F:C63A.0012/hidraw/hidraw6
E: SUBSYSTEM=hidraw
E: DEVNAME=/dev/hidraw6
E: MAJOR=241
E: MINOR=6

P: /devices/virtual/misc/uhid/0005:256F:C63A.0012/input/input38
M: input38
R: 38
U: input
E: DEVPATH=/devices/virtual/misc/uhid/0005:256F:C63A.0012/input/input38
E: SUBSYSTEM=input
E: PRODUCT=5/256f/c63a/504
E: NAME="SpaceMouse Wireless BT"
E: PHYS="3c:e9:f7:60:d8:48"
E: UNIQ="cb:a6:c9:1b:6f:7d"
E: PROP=0
E: EV=2001b
E: KEY=3 0 0 0 0
E: ABS=3f
E: MSC=10
E: LED=100
E: MODALIAS=input:b0005v256FpC63Ae0504-e0,1,3,4,11,k100,101,ra0,1,2,3,4,5,m4,l8,sfw
E: USEC_INITIALIZED=289995105945
E: ID_INPUT=1
E: ID_INPUT_JOYSTICK=1
E: ID_BUS=bluetooth
E: TAGS=:seat:
E: CURRENT_TAGS=:seat:

P: /devices/virtual/misc/uhid/0005:256F:C63A.0012/input/input38/event11
M: event11
R: 11
U: input
D: c 13:75
N: input/event11
L: 0
E: DEVPATH=/devices/virtual/misc/uhid/0005:256F:C63A.0012/input/input38/event11
E: SUBSYSTEM=input
E: DEVNAME=/dev/input/event11
E: MAJOR=13
E: MINOR=75
E: USEC_INITIALIZED=289995106217
E: ID_INPUT=1
E: ID_INPUT_JOYSTICK=1
E: ID_INPUT_WIDTH_MM=2
E: ID_INPUT_HEIGHT_MM=2
E: ID_BUS=bluetooth
E: ID_INPUT_JOYSTICK_INTEGRATION=external
E: LIBINPUT_DEVICE_GROUP=5/256f/c63a:3c:e9:f7:60:d8:48
E: TAGS=:seat:uaccess:
E: CURRENT_TAGS=:seat:uaccess:

[whot]

[note: wrote this last night but apparently didn't click the button...]

I agree with @hadess that uaccess right now seems like the most sensible approach, we're too far away from relying on the hidraw stack being in place.

3D mice (at least the ones I've seen) are not super useful as regular devices, the space navigator is almost closer to a pointing stick than a mouse. I'd say ppl use those in addition to regular devices.

Having said that, this could be an interesting addition in libinput as a separate input device similar to how we made tablets separate. Not sure there's much demand for it though if everything wants to use hidraw.