search

swaywm / sway

i3-compatible Wayland compositor
https://swaywm.org
MIT License
14.4k stars 1.1k forks source link

Input identifiers are not unique #3608

Open CaptainBloodz opened 5 years ago

CaptainBloodz commented 5 years ago

swaymsg -t get_version sway version 1.0-rc1-31-gee56428b (Feb 7 2019, branch 'HEAD')

xwayland enabled

swaymsg -t get_inputs

Input device: USB OPTICAL MOUSE
  Type: Mouse
  Identifier: 10077:2982:USB_OPTICAL_MOUSE
  Product ID: 2982
  Vendor ID: 10077
  Libinput Send Events: enabled

Input device: USB HCT Keyboard
  Type: Mouse
  Identifier: 49395:673:USB_HCT_Keyboard
  Product ID: 673
  Vendor ID: 49395
  Libinput Send Events: enabled

Input device: USB HCT Keyboard
  Type: Keyboard
  Identifier: 49395:673:USB_HCT_Keyboard
  Product ID: 673
  Vendor ID: 49395
  Active Keyboard Layout: French
  Libinput Send Events: enabled

Input device: USB HCT Keyboard
  Type: Keyboard
  Identifier: 49395:673:USB_HCT_Keyboard
  Product ID: 673
  Vendor ID: 49395
  Active Keyboard Layout: French
  Libinput Send Events: enabled

Input device: Sleep Button
  Type: Keyboard
  Identifier: 0:3:Sleep_Button
  Product ID: 3
  Vendor ID: 0
  Active Keyboard Layout: English (US)
  Libinput Send Events: enabled
...

Is this replication:

1) Caused by some out of sway configuration? 2) Originated in sway behavior, whether expected or not? 3) Something else?

Plz note this isn't causing any issue he know of.

Thanks for your attention.

RedSoxFan commented 5 years ago

Related https://github.com/swaywm/wlroots/issues/403

emersion commented 5 years ago

I think those are in the same group.

Related: https://github.com/swaywm/wlroots/issues/1217

Kimapr commented 4 years ago

This causes me a problem. I can't configure my two RAPOO keyboard/mouse combos independently

Zocker1999NET commented 2 years ago

same here, I have a Thinkpad Tablet with a trackpoint and a touch pad. With libinput list-devices and libinput debug-events --device /dev/input/eventXX it was possible to distinguish them. However, sway cannot distinguish them

Zocker1999NET commented 2 years ago

This seems to be the code in question which generates the "unique" identifiers for each device: https://github.com/swaywm/sway/blob/956b689d6ab18ad78f53f15cdeb7606af98e9e5e/sway/input/input-manager.c#L65-L90

I thought about two ideas which could might solve this issue:

  1. This code could be changed to fix this issue, however, without any workarounds, this would break current user configurations. And also, the new identifier needs to be stable so it keeps the same across multiple boots while trying to be unique. But I did not find any value, which could be added.
  2. But, at least to distinguish between some devices, it could be added that we can describe, what capabilities the devices have (because they differ in my case) like in CSS, e.g. input:pointer[gesture], input:pointer[!gesture], and, if sway knows, maybe this could also be used to describe the port, where the device is connected (solving the issue with two identical keyboards connected). This change should be backward compatible to current configurations and could be expanded in the future, if required.
Liriel commented 2 years ago

counting the number of "unique" appearances of vendor:product:devicename combinations should provide a way to address a single device not breaking any configs

I realize of course that the order these are discoverd might not be the same each time, but I lived with that under X and it would be a dramatic improvement compared to not being able to adress a single device at all.

tdaniel22 commented 1 year ago

Here's a VERY quick and dirty patch to set the USB physical connector name as the input identifier : https://gist.github.com/tdaniel22/166301c48a2e50502ba34877f509dcfb. I needed this to map two touch panels of the same brand to their respective outputs.

GoodDays13 commented 3 months ago

I am encountering this as an issue trying to put two controllers in different seats. They are connected via Bluetooth.

xtj7 commented 1 month ago

I have the same issue with multiple touchscreens of the same brand. I need to map them to the correct output, but can't due to them having the same identifier. At least having some additional differentiating value would be important here.

Maybe worth mentioning: in the raspberry pi project they fixed this issue with a kernel patch to make the IDs unique. Which is great for the pi, but unfortunately I am not running a pi and would prefer not to patch my kernel. https://github.com/raspberrypi/bookworm-feedback/issues/138

Can we use the device as an alternative identifier perhaps? For example: /dev/input/event17?

erelson commented 1 month ago

Found this issue while looking into mapping input from two of the same model touchscreens to their respective screens.

I eventually realized that in my case (where there are only these two screens, so it's "simple"), and I'm not unplugging/replugging the hardware (i.e. always using two, plugged into the same respective ports), I can create a pair of udev rules that:

0.5 0 0
  0 1 0

and

0.5 0 0.5
  0 1   0

So I have rules like:

ACTION=="add|change", KERNEL=="event*", ATTRS{id/vendor}=="abcd", ATTRS{id/product}=="abcd", ATTRS{phys}=="usb*-1.2/*", ENV{LIBINPUT_CALIBRATION_MATRIX}="0.5 0 0 0 1 0"
ACTION=="add|change", KERNEL=="event*", ATTRS{id/vendor}=="abcd", ATTRS{id/product}=="abcd", ATTRS{phys}=="usb*-2.2/*", ENV{LIBINPUT_CALIBRATION_MATRIX}="0.5 0 0.5 0 1 0"

You can get the USB phys values from udevadm info {/sys path} but they're also easy enough to infer directly from loginctl seat-status seat0.

Edit: However: in my particular setup this does not help me, as I can't get a wayland compositor to render to both of 2 separate displaylink touchscreens.