Everything works now and no, the hat difference doesn't seem to be an
issue.  It registers the direction pad as 4 buttons, but everything
seems to work fine.

Thanks for all the help!

Chris

On Fri, Feb 9, 2024 at 6:47 AM Benjamin Tissoires
[off-list ref] wrote:

[Adding back the linux-input ML]

On Wed, Feb 7, 2024 at 6:34 AM Taco Jerkface [off-list ref] wrote:

quoted

On Tue, Feb 6, 2024 at 8:11 AM Benjamin Tissoires
[off-list ref] wrote:

quoted

On Tue, Feb 6, 2024 at 6:25 AM Taco Jerkface [off-list ref] wrote:

quoted

Thanks!

quoted

1. (easiest) tune your udev rule to also give user access to the
hidraw subsystem on this device. SDL should be able to read it
directly, and handle it properly, but this won't solve for future
users

This udev rule does in fact "fix" the problem

KERNELS=="*:045E:0B22.*", MODE="0666"

Right :)

Well you could restrict it further by using the recommendations from SDL:
https://github.com/libsdl-org/SDL/blob/main/src/hidapi/udev/69-hid.rules

# HIDAPI/hidraw
KERNEL=="hidraw*", ATTRS{idVendor}=="045E", ATTRS{idProduct}=="0B22",
TAG+="uaccess"

(not entirely sure about the capitals in vendor/product)

I tried that and couldn't get it to work.  My (incomplete)
understanding is that the rule needs to match the fields from "udevadm
info --name=/dev/hidraw1 --attribute-walk" which looks like this.  The
"KERNELS" line was the best I could find with both the vendor and
product fields.  I wildcarded the 0005 because it changed when I
reconnected.

Yeah, so I vaguely remember that some properties are inherited from
the parents, and VendorID and ProductID might be inherited. And given
that this is a BLE device and that it's then using uhid, those
properties are not set.

TL;DR: seems like you got the correct match. You should probably use
TAG+="uaccess" instead of MODE="0666" to restrict the opening of the
device from the current user of the current session only.

quoted

  looking at device
'/devices/virtual/misc/uhid/0005:045E:0B22.0005/hidraw/hidraw1':
   KERNEL=="hidraw1"
   SUBSYSTEM=="hidraw"
   DRIVER==""
   ATTR{power/control}=="auto"
   ATTR{power/runtime_active_time}=="0"
   ATTR{power/runtime_status}=="unsupported"
   ATTR{power/runtime_suspended_time}=="0"

 looking at parent device '/devices/virtual/misc/uhid/0005:045E:0B22.0005':
   KERNELS=="0005:045E:0B22.0005"
   SUBSYSTEMS=="hid"
   DRIVERS=="microsoft"
   ATTRS{country}=="00"
   ATTRS{power/control}=="auto"
   ATTRS{power/runtime_active_time}=="0"
   ATTRS{power/runtime_status}=="unsupported"
   ATTRS{power/runtime_suspended_time}=="0"

 looking at parent device '/devices/virtual/misc/uhid':
   KERNELS=="uhid"
   SUBSYSTEMS=="misc"
   DRIVERS==""
   ATTRS{power/control}=="auto"
   ATTRS{power/runtime_active_time}=="0"

quoted

quoted

quoted

2. (no kernel compilation required) we can try to fix the report
descriptor of the device through HID-BPF. Assuming you have
CONFIG_HID_BPF enabled in your kernel, we can relatively easily change
the way the device is exported/handled by the kernel, to make it
useful hopefully
3. (hardest IMO as you'll have to recompile your kernel for the tests)
we can try to tune hid-microsoft.c to properly export these buttons

For 2 and 3, I'll need some events from your device with hid-recorder.
You only gave me the report descriptor, but no events which are hard
to deduce based on the long report descriptor.

With the udev rule, I attached the hid-recorder output when pressing
the paddles.  I see the 01 02 04 08 showing up at the end of the line.

Thanks for that. And as you can see, they are using the "Assign
Selection" usage, which is... new to me :)

quoted

quoted

Also for 2 and 3 we need to have a BTN_* button code to use, and I
don't know which ones should be used from the top of my head. HID-BPF
would be easiest to use as we can let the user decide of it, while
we'll need to have a more formal usage in case we fix hid-microsoft.

When connected with USB, evemu-record shows button names
"BTN_TRIGGER_HAPPY5" "BTN_TRIGGER_HAPPY6" "BTN_TRIGGER_HAPPY7"
"BTN_TRIGGER_HAPPY8".  I assume these are the button codes we can use?

################################
#      Waiting for events      #
################################
E: 0.000001 0001 02c4 0001      # EV_KEY / BTN_TRIGGER_HAPPY5   1
E: 0.000001 0000 0000 0000      # ------------ SYN_REPORT (0) ---------- +0ms
E: 0.143950 0001 02c4 0000      # EV_KEY / BTN_TRIGGER_HAPPY5   0
E: 0.143950 0000 0000 0000      # ------------ SYN_REPORT (0) ---------- +143ms
E: 6.543984 0001 02c5 0001      # EV_KEY / BTN_TRIGGER_HAPPY6   1
E: 6.543984 0000 0000 0000      # ------------ SYN_REPORT (0) ---------- +6400ms
E: 6.615981 0001 02c5 0000      # EV_KEY / BTN_TRIGGER_HAPPY6   0
E: 6.615981 0000 0000 0000      # ------------ SYN_REPORT (0) ---------- +72ms
E: 7.520034 0001 02c6 0001      # EV_KEY / BTN_TRIGGER_HAPPY7   1
E: 7.520034 0000 0000 0000      # ------------ SYN_REPORT (0) ---------- +905ms
E: 7.648127 0001 02c6 0000      # EV_KEY / BTN_TRIGGER_HAPPY7   0
E: 7.648127 0000 0000 0000      # ------------ SYN_REPORT (0) ---------- +128ms
E: 8.344035 0001 02c7 0001      # EV_KEY / BTN_TRIGGER_HAPPY8   1
E: 8.344035 0000 0000 0000      # ------------ SYN_REPORT (0) ---------- +696ms
E: 8.480049 0001 02c7 0000      # EV_KEY / BTN_TRIGGER_HAPPY8   0
E: 8.480049 0000 0000 0000      # ------------ SYN_REPORT (0) ---------- +136ms

Good point. Then we can easily tweak the device to use those BTN_* instead

quoted

quoted

For 1, maybe SDL (or Steam) already ships some udev rules, and
submitting a fix there would make things working for everybody.

Anyway, depending on how much you want this to be fixed and what you
can do (is CONFIG_HID_BPF enabled in your distro? and can you
recompile a kernel module?) we can figure out the next step.

Yes HID-BPF is configured in my kernel:

cat /proc/config.gz | gunzip
#
# HID-BPF support
#
CONFIG_HID_BPF=y
# end of HID-BPF support

Even better, it'll be way easier for the tests :)

I've opened a new MR with your device fix:
https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/32

You should be able to head to the last job in latest pipeline (in the
pipeline tab) and download the artifact:
https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/jobs/54687597/artifacts/browse

Then unpack and run `sudo ./install --verbose`.

Then reconnect the device over Bluetooth, and see in evemu-record that
the paddles are now reporting BTN_TRIGGER_HAPPY[5-8].

Thanks.  This does indeed work (with my udev rule still active).

\o/

quoted

quoted

I'd then be curious about 2 things:
- are the paddle now reporting the same events over USB and Bluetooth?
(is there no inversions between the BTN_TRIGGER*?, and are all the
buttons correctly handled?)

The button reports are nearly identical now, though Bluetooth outputs
more information.

\o/

quoted

This is paddle1, paddl2, paddle3, paddle4 pressed in that order each way.

USB:
E: 0.000001 0001 02c4 0001      # EV_KEY / BTN_TRIGGER_HAPPY5   1
E: 0.000001 0000 0000 0000      # ------------ SYN_REPORT (0) ---------- +0ms
E: 0.080031 0001 02c4 0000      # EV_KEY / BTN_TRIGGER_HAPPY5   0
E: 0.080031 0000 0000 0000      # ------------ SYN_REPORT (0) ---------- +80ms
E: 1.520025 0001 02c5 0001      # EV_KEY / BTN_TRIGGER_HAPPY6   1
E: 1.520025 0000 0000 0000      # ------------ SYN_REPORT (0) ---------- +1440ms
E: 1.631883 0001 02c5 0000      # EV_KEY / BTN_TRIGGER_HAPPY6   0
E: 1.631883 0000 0000 0000      # ------------ SYN_REPORT (0) ---------- +111ms
E: 2.183887 0001 02c6 0001      # EV_KEY / BTN_TRIGGER_HAPPY7   1
E: 2.183887 0000 0000 0000      # ------------ SYN_REPORT (0) ---------- +552ms
E: 2.295985 0001 02c6 0000      # EV_KEY / BTN_TRIGGER_HAPPY7   0
E: 2.295985 0000 0000 0000      # ------------ SYN_REPORT (0) ---------- +112ms
E: 2.800031 0001 02c7 0001      # EV_KEY / BTN_TRIGGER_HAPPY8   1
E: 2.800031 0000 0000 0000      # ------------ SYN_REPORT (0) ---------- +505ms
E: 2.879964 0001 02c7 0000      # EV_KEY / BTN_TRIGGER_HAPPY8   0
E: 2.879964 0000 0000 0000      # ------------ SYN_REPORT (0) ---------- +79ms

Bluetooth:
E: 0.000001 0004 0004 589845    # EV_MSC / MSC_SCAN             589845
E: 0.000001 0001 02c4 0001      # EV_KEY / BTN_TRIGGER_HAPPY5   1
E: 0.000001 0000 0000 0000      # ------------ SYN_REPORT (0) ---------- +0ms
E: 0.033496 0004 0004 589845    # EV_MSC / MSC_SCAN             589845
E: 0.033496 0001 02c4 0000      # EV_KEY / BTN_TRIGGER_HAPPY5   0
E: 0.033496 0000 0000 0000      # ------------ SYN_REPORT (0) ---------- +33ms
E: 1.726818 0004 0004 589846    # EV_MSC / MSC_SCAN             589846
E: 1.726818 0001 02c5 0001      # EV_KEY / BTN_TRIGGER_HAPPY6   1
E: 1.726818 0000 0000 0000      # ------------ SYN_REPORT (0) ---------- +1693ms
E: 1.843421 0004 0004 589846    # EV_MSC / MSC_SCAN             589846
E: 1.843421 0001 02c5 0000      # EV_KEY / BTN_TRIGGER_HAPPY6   0
E: 1.843421 0000 0000 0000      # ------------ SYN_REPORT (0) ---------- +117ms
E: 2.736883 0004 0004 589847    # EV_MSC / MSC_SCAN             589847
E: 2.736883 0001 02c6 0001      # EV_KEY / BTN_TRIGGER_HAPPY7   1
E: 2.736883 0000 0000 0000      # ------------ SYN_REPORT (0) ---------- +893ms
E: 2.826849 0004 0004 589847    # EV_MSC / MSC_SCAN             589847
E: 2.826849 0001 02c6 0000      # EV_KEY / BTN_TRIGGER_HAPPY7   0
E: 2.826849 0000 0000 0000      # ------------ SYN_REPORT (0) ---------- +90ms
E: 3.300247 0004 0004 589848    # EV_MSC / MSC_SCAN             589848
E: 3.300247 0001 02c7 0001      # EV_KEY / BTN_TRIGGER_HAPPY8   1
E: 3.300247 0000 0000 0000      # ------------ SYN_REPORT (0) ---------- +474ms
E: 3.373377 0004 0004 589848    # EV_MSC / MSC_SCAN             589848
E: 3.373377 0001 02c7 0000      # EV_KEY / BTN_TRIGGER_HAPPY8   0
E: 3.373377 0000 0000 0000      # ------------ SYN_REPORT (0) ---------- +73ms

Also via USB, evemu recognizes the controller as "Microsoft X-Box One
Elite 2 pad".  With Bluetooth it's seen as "Xbox Wireless Controller".
This happens with or without your merge request.

This is expected and also kind of normal. We are not connecting
through the same transport, so one should at least have the "wireless"
in it. Rest is just how the device itself has those strings stored, so
we should probably just say it's fine.

quoted

USB

quoted

evemu-record

Available devices:
/dev/input/event17:     Microsoft X-Box One Elite 2 pad

Bluetooth

quoted

evemu-record

Available devices:
/dev/input/event16:     Xbox Wireless Controller

quoted

- does this mess up with SDL over hidraw (so keeping your udev rule in place)

SDL seems to recognize the controller as 'Xbox One Elite 2 Controller'
over both USB and Bluetooth.  Though the ProductID is "000b" with USB
and "220b" via bluetooth.  Also, SDL, recognized the "hat" via USB,
but sees them as 4 more buttons through BT.  I'm using
Grumbel/sdl-jstest.git to test.  This happens with or without your MR.

Is this hat difference an issue? If so we can try to fix it, again,
and if not we can then leave it as it is.

quoted

USB:
Joystick Name:     'Xbox One Elite 2 Controller'
Joystick GUID:     030010f85e040000000b000011050000
Joystick Number:    0
Number of Axes:     6
Number of Buttons: 15
Number of Hats:     1
Number of Balls:    0
GameControllerConfig:
 Name:    'Xbox One Elite 2 Controller'
 Mapping: '030010f85e040000000b000011050000,Xbox One Elite 2
Controller,a:b0,b:b1,x:b2,y:b3,back:b6,guide:b8,start:b7,leftstick:b9,rightstick:b10,leftshoulder:b4,rightshould
er:b5,dpup:h0.1,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,paddle1:b11,paddle2:b13,paddle3:b12,paddle4:b14,leftx:a0,lefty:a1,rightx:a3,righty:a4,lefttrigger:a2,righttrigger:a5,crc:
f810,platform:Linux'

Bluetooth:
Joystick Name:     'Xbox One Elite 2 Controller'
Joystick GUID:     030018dc5e040000220b000000006800
Joystick Number:    0
Number of Axes:     6
Number of Buttons: 19
Number of Hats:     0
Number of Balls:    0
GameControllerConfig:
 Name:    'Xbox One Elite 2 Controller'
 Mapping: '030018dc5e040000220b000000006800,*,a:b0,b:b1,back:b4,dpdown:b12,dpleft:b13,dpright:b14,dpup:b11,guide:b5,leftshoulder:b9,leftstick:b7,lefttrigger:a4,leftx:a0,left
y:a1,rightshoulder:b10,rightstick:b8,righttrigger:a5,rightx:a2,righty:a3,start:b6,x:b2,y:b3,paddle1:b15,paddle2:b17,paddle3:b16,paddle4:b18,crc:dc18,platform:Linux'


Otherwise, no issues, Steam recognizes all buttons including paddles
correctly (with or without your MR).  But it also names the controller
"Xbox One Elite 2 Controller" via USB and "Xbox One Controller" when
using Bluetooth.  This doesn't seem to have any effect on registering
the paddles correctly though.

\o/

quoted

quoted

quoted

I've never recompiled a module before, but I've compiled lots of other
stuff before.  How hard can it be?

Technically it's not hard, I'm sure there is a proper Arch howto
available. But it's painful because you'll have to maintain &
recompile your kernel until your fix gets in the standard kernel of
your distribution (archlinux if I'm not wrong).

But the good point is that with HID-BPF that pain is relieved:  I can
provide you with the binary, you can check it if you like (the loader
is in rust and the bpf itself is C), and then once installed you can
forget about it.

Let's try it!

Well the more I think of it, the more I think we'll stick to the current state:
- SDL is actually fixed by the udev rule (they just prefer talk over hidraw)
- for evemu users, we have a bpf filter that works. I'll eventually
merge those in the kernel so they are automatically shipped.

So I don't really see the point of fixing a driver for the sake of
fixing it and just losing both of our time.

Thanks a lot for the quick testing.

Cheers,
Benjamin