Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

udev bind event missing on AVRCP connections #352

Open
macmpi opened this issue Jun 2, 2022 · 10 comments
Open

udev bind event missing on AVRCP connections #352

macmpi opened this issue Jun 2, 2022 · 10 comments

Comments

@macmpi
Copy link

macmpi commented Jun 2, 2022

I'm trying to detect paired-devices incoming connection by setting a udev rule filtering ACTION=bind.
This works on HID devices, but not on AVRCP (bluez 5.64, kernel 5.15.32): udevadm monitor --property --udev only shows ACTION=add for dev inputs, but no ACTION=bind at the end for the latter.
Is that intended to be specific to HID only?

BTW, I could not find any specific key to detect A2DP speaker (audio card) connection either. Any suggested alternative?
Thanks.
@Vudentz
Copy link
Contributor

Vudentz commented Jun 2, 2022

@macmpi not sure what does has to do with BlueZ, we are using uHID to create the HID devices so if there events missing the component responsible for that would uHID not BlueZ. Regarding A2DP it doesn't create any devnode so I doubt we can integrate with udev, well except if there is a way to inject events an create entries on sysfs from userspace.

@macmpi
Copy link
Author

macmpi commented Jun 3, 2022

Thanks for feedback.
HID does declare bind fine; missing bind is for AVRCP actually.
However, I understand this is a kernel-side thing (bind there is related to driver attachment, not to Bluetooth link).

On A2DP side, would be nice user-space could be notified of A2DP availability though.

@macmpi macmpi closed this as completed Jun 3, 2022
@macmpi macmpi reopened this Jun 8, 2022
@macmpi
Copy link
Author

macmpi commented Jun 8, 2022

On the same vein, HID device bluetooth address is reported by udevadm, whereas that address is omitted for AVRCP devices.
This is very annoying to properly handle incoming AVRCP devices.

Exemple below on AVRCP:

$ udevadm info -a -n /dev/input/event1
  looking at device '/devices/virtual/input/input1/event1':
    KERNEL=="event1"
    SUBSYSTEM=="input"
    DRIVER==""

  looking at parent device '/devices/virtual/input/input1':
    KERNELS=="input1"
    SUBSYSTEMS=="input"
    DRIVERS==""
    ATTRS{uniq}==""
    ATTRS{properties}=="0"
    ATTRS{phys}=="b8:27:eb:3e:50:3d"
    ATTRS{inhibited}=="0"
    ATTRS{name}=="Vivan  BT600 (AVRCP)"

phys attribute is the host, whereas uniq is supposedly the attribute for the actual AVRCP device in that case.
For HID devices, uniq attribute is filled-in fine as per below:

$ udevadm info -a -n /dev/input/event1

  looking at device '/devices/platform/soc/20201000.serial/serial0/serial0-0/bluetooth/hci0/hci0:12/0005:04E8:7021.0001/input/input2/event1':
    KERNEL=="event1"
    SUBSYSTEM=="input"
    DRIVER==""

  looking at parent device '/devices/platform/soc/20201000.serial/serial0/serial0-0/bluetooth/hci0/hci0:12/0005:04E8:7021.0001/input/input2':
    KERNELS=="input2"
    SUBSYSTEMS=="input"
    DRIVERS==""
    ATTRS{uniq}=="b4:4b:1b:04:04:5f"
    ATTRS{properties}=="0"
    ATTRS{phys}=="b8:27:eb:3e:50:3d"
    ATTRS{inhibited}=="0"
    ATTRS{name}=="Amazon Fire TV Remote Keyboard"

  looking at parent device '/devices/platform/soc/20201000.serial/serial0/serial0-0/bluetooth/hci0/hci0:12/0005:04E8:7021.0001':
    KERNELS=="0005:04E8:7021.0001"
    SUBSYSTEMS=="hid"
    DRIVERS=="hid-generic"
    ATTRS{country}=="21"

  looking at parent device '/devices/platform/soc/20201000.serial/serial0/serial0-0/bluetooth/hci0/hci0:12':
    KERNELS=="hci0:12"
    SUBSYSTEMS=="bluetooth"
    DRIVERS==""

  looking at parent device '/devices/platform/soc/20201000.serial/serial0/serial0-0/bluetooth/hci0':
    KERNELS=="hci0"
    SUBSYSTEMS=="bluetooth"
    DRIVERS==""

  looking at parent device '/devices/platform/soc/20201000.serial/serial0/serial0-0':
    KERNELS=="serial0-0"
    SUBSYSTEMS=="serial"
    DRIVERS=="hci_uart_bcm"

  looking at parent device '/devices/platform/soc/20201000.serial/serial0':
    KERNELS=="serial0"
    SUBSYSTEMS=="serial"
    DRIVERS==""

  looking at parent device '/devices/platform/soc/20201000.serial':
    KERNELS=="20201000.serial"
    SUBSYSTEMS=="amba"
    DRIVERS=="uart-pl011"
    ATTRS{id}=="00241011"
    ATTRS{irq0}=="81"
    ATTRS{driver_override}=="(null)"

  looking at parent device '/devices/platform/soc':
    KERNELS=="soc"
    SUBSYSTEMS=="platform"
    DRIVERS=="simple-pm-bus"
    ATTRS{driver_override}=="(null)"

  looking at parent device '/devices/platform':
    KERNELS=="platform"
    SUBSYSTEMS==""
    DRIVERS==""

@Vudentz
Copy link
Contributor

Vudentz commented Jun 13, 2022

On the same vein, HID device bluetooth address is reported by udevadm, whereas that address is omitted for AVRCP devices. This is very annoying to properly handle incoming AVRCP devices.

Exemple below on AVRCP:

$ udevadm info -a -n /dev/input/event1
  looking at device '/devices/virtual/input/input1/event1':
    KERNEL=="event1"
    SUBSYSTEM=="input"
    DRIVER==""

  looking at parent device '/devices/virtual/input/input1':
    KERNELS=="input1"
    SUBSYSTEMS=="input"
    DRIVERS==""
    ATTRS{uniq}==""
    ATTRS{properties}=="0"
    ATTRS{phys}=="b8:27:eb:3e:50:3d"
    ATTRS{inhibited}=="0"
    ATTRS{name}=="Vivan  BT600 (AVRCP)"

phys attribute is the host, whereas uniq is supposedly the attribute for the actual AVRCP device in that case. For HID devices, uniq attribute is filled-in fine as per below:

$ udevadm info -a -n /dev/input/event1

  looking at device '/devices/platform/soc/20201000.serial/serial0/serial0-0/bluetooth/hci0/hci0:12/0005:04E8:7021.0001/input/input2/event1':
    KERNEL=="event1"
    SUBSYSTEM=="input"
    DRIVER==""

  looking at parent device '/devices/platform/soc/20201000.serial/serial0/serial0-0/bluetooth/hci0/hci0:12/0005:04E8:7021.0001/input/input2':
    KERNELS=="input2"
    SUBSYSTEMS=="input"
    DRIVERS==""
    ATTRS{uniq}=="b4:4b:1b:04:04:5f"
    ATTRS{properties}=="0"
    ATTRS{phys}=="b8:27:eb:3e:50:3d"
    ATTRS{inhibited}=="0"
    ATTRS{name}=="Amazon Fire TV Remote Keyboard"

  looking at parent device '/devices/platform/soc/20201000.serial/serial0/serial0-0/bluetooth/hci0/hci0:12/0005:04E8:7021.0001':
    KERNELS=="0005:04E8:7021.0001"
    SUBSYSTEMS=="hid"
    DRIVERS=="hid-generic"
    ATTRS{country}=="21"

  looking at parent device '/devices/platform/soc/20201000.serial/serial0/serial0-0/bluetooth/hci0/hci0:12':
    KERNELS=="hci0:12"
    SUBSYSTEMS=="bluetooth"
    DRIVERS==""

  looking at parent device '/devices/platform/soc/20201000.serial/serial0/serial0-0/bluetooth/hci0':
    KERNELS=="hci0"
    SUBSYSTEMS=="bluetooth"
    DRIVERS==""

  looking at parent device '/devices/platform/soc/20201000.serial/serial0/serial0-0':
    KERNELS=="serial0-0"
    SUBSYSTEMS=="serial"
    DRIVERS=="hci_uart_bcm"

  looking at parent device '/devices/platform/soc/20201000.serial/serial0':
    KERNELS=="serial0"
    SUBSYSTEMS=="serial"
    DRIVERS==""

  looking at parent device '/devices/platform/soc/20201000.serial':
    KERNELS=="20201000.serial"
    SUBSYSTEMS=="amba"
    DRIVERS=="uart-pl011"
    ATTRS{id}=="00241011"
    ATTRS{irq0}=="81"
    ATTRS{driver_override}=="(null)"

  looking at parent device '/devices/platform/soc':
    KERNELS=="soc"
    SUBSYSTEMS=="platform"
    DRIVERS=="simple-pm-bus"
    ATTRS{driver_override}=="(null)"

  looking at parent device '/devices/platform':
    KERNELS=="platform"
    SUBSYSTEMS==""
    DRIVERS==""

This should be easy to fix.

@Vudentz
Copy link
Contributor

Vudentz commented Jun 13, 2022

On the same vein, HID device bluetooth address is reported by udevadm, whereas that address is omitted for AVRCP devices. This is very annoying to properly handle incoming AVRCP devices.
Exemple below on AVRCP:

$ udevadm info -a -n /dev/input/event1
  looking at device '/devices/virtual/input/input1/event1':
    KERNEL=="event1"
    SUBSYSTEM=="input"
    DRIVER==""

  looking at parent device '/devices/virtual/input/input1':
    KERNELS=="input1"
    SUBSYSTEMS=="input"
    DRIVERS==""
    ATTRS{uniq}==""
    ATTRS{properties}=="0"
    ATTRS{phys}=="b8:27:eb:3e:50:3d"
    ATTRS{inhibited}=="0"
    ATTRS{name}=="Vivan  BT600 (AVRCP)"

The kernel interface for creating uinput is different than uhid, the former currently has no way to set the uniq attribute see:

https://patchwork.kernel.org/project/linux-input/patch/20191127185139.65048-1-abhishekpandit@chromium.org/

Perhaps you want to revive the thread to see if that can be arranged.

@Vudentz
Copy link
Contributor

Vudentz commented Jun 13, 2022

@macmpi perhaps if you create a bug reporting this to linux-input bugzilla maybe we get a proper answer on how we can set the uniq attribute when using uinput.

@macmpi
Copy link
Author

macmpi commented Jun 14, 2022 •
edited

@Vudentz thanks indeed for looking into that: I have just submitted a bug as suggested.
Of course having it fixed for uinput would be ideal.

However, another way to look at it could be to have AVRCP come-up as HID device (it's a sort of limited keyboard, like a bluetooth remote): would that make sense?

@Vudentz
Copy link
Contributor

Vudentz commented Jun 28, 2022 •
edited

@macmpi I wonder if there is anyone responsible for Input Devices nowadays, it doesn't looks like there is anyone assigned to the bug you created, perhaps we should ping the maintainers:

https://patchwork.kernel.org/project/linux-input/

@macmpi
Copy link
Author

macmpi commented Jun 29, 2022

wouldn't AVRCP declared as yet-another-HID-remote be possible?

@Vudentz
Copy link
Contributor

Vudentz commented Jun 29, 2022

wouldn't AVRCP declared as yet-another-HID-remote be possible?

AVCTP doesn't not use HID.

@pacho2 pacho2 mentioned this issue Jul 30, 2023
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@Vudentz @macmpi