Sway touchscreen input size in multi-monitor setups does not match the touchscreen display size

[ronchaine]

Sway Version:

swaymsg version 1.6-8fa7b998 (Oct  7 2021, branch 'master')

Configuration File:
Default config file

Description:

• Start sway on a touchscreen laptop and verify touchscreen coordinates match the screen coordinates
• Plug in external monitor (mine is configured on right, output of swaymsg -t get_outputs below)
• Touchscreen input no longer matches the position seen on the touchscreen monitor.

I'm not sure if this should be fixed in wlroots or sway.

It seems that the touchscreen coordinates are relative to entire output layout, instead of only the touchscreen monitor. (i.e. sway calls `wlr_cursor_absolute_to_layout_coords(...), which uses the layout size when it's expected that it should be restricted to only the touchscreen itself or smth. like that.)

Output eDP-1 'Unknown 0x0582 0x00000000' (focused) 
  Current mode: 3000x2000 @ 59.999 Hz
  Position: 0,0
  Scale factor: 1.000000

And another display on the right

Output DP-1 'Acer Technologies XV282K KV 11221B7F14200'
  Current mode: 3840x2160 @ 59.997 Hz
  Position: 3000,0
  Scale factor: 1.000000

'm unsure where / how this should be fixed (e.g. should sway do the cursor restriction or
should wlroots detect it is a touch input and do it itself, or does some other use case break in that situation?)

[emersion]

Sway has some detection mechanism for built-in touchscreens, but we can't get it always right.

What does udevadm info /dev/input/by-id/* print?

[emersion]

BTW - you can still manually map the input device to the output with map_to_output.

[ronchaine]

Sway has some detection mechanism for built-in touchscreens, but we can't get it always right.

Ye, I am not running the most common hardware so not too surprised

What does udevadm info /dev/input/by-id/* print?

udevadm info /dev/input/by-id/* can be found in here, but I doubt it is very helpful since

[ronchaine@mellori (0) ~/Source/desktop/wlroots]$ ls /dev/input/by-id -l
total 0
lrwxrwxrwx 1 root root 10 Oct  8 17:05 usb-8SSC20F27052L1GZ89E01P7_Integrated_Camera_200901010001-event-if00 -> ../event13
lrwxrwxrwx 1 root root 10 Oct  8 17:05 usb-Chicony_Electronics_Co._Ltd._Integrated_IR_Camera_0x0001-event-ir -> ../event12
lrwxrwxrwx 1 root root  9 Oct  8 17:05 usb-Chicony_ThinkPad_X1_Tablet_Thin_Keyboard_Gen_3-event-if01 -> ../event9
lrwxrwxrwx 1 root root  9 Oct  8 17:05 usb-Chicony_ThinkPad_X1_Tablet_Thin_Keyboard_Gen_3-event-kbd -> ../event4
lrwxrwxrwx 1 root root 11 Oct  8 17:05 usb-Chicony_ThinkPad_X1_Tablet_Thin_Keyboard_Gen_3-if02-event-mouse -> ../event256

shows that the device doesn't get linked there. (evtest shows it as event21)

/dev/input/event20:	Wacom HID 511A Pen
/dev/input/event21:	Wacom HID 511A Finger

BTW - you can still manually map the input device to the output with map_to_output.

Oh crap, I somehow missed this option in the input config. Thanks for that.

[emersion]

OK, what about udevadm info /dev/input/event21 then?

[ronchaine]

[ronchaine@mellori (1) ~/Source/desktop/sway]$ udevadm info /dev/input/event21
P: /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-8/i2c-WCOM511A:00/0018:056A:511A.0006/input/input28/event21
N: input/event21
L: 0
S: input/by-path/pci-0000:00:15.1-platform-i2c_designware.1-event
E: DEVPATH=/devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-8/i2c-WCOM511A:00/0018:056A:511A.0006/input/input28/event21
E: DEVNAME=/dev/input/event21
E: MAJOR=13
E: MINOR=85
E: SUBSYSTEM=input
E: USEC_INITIALIZED=3680062
E: ID_INPUT=1
E: ID_INPUT_TOUCHSCREEN=1
E: ID_INPUT_WIDTH_MM=274
E: ID_INPUT_HEIGHT_MM=182
E: ID_PATH=pci-0000:00:15.1-platform-i2c_designware.1
E: ID_PATH_TAG=pci-0000_00_15_1-platform-i2c_designware_1
E: LIBINPUT_DEVICE_GROUP=18/56a/511a:i2c-WCOM511A:00
E: LIBINPUT_FUZZ_35=4
E: LIBINPUT_FUZZ_36=4
E: DEVLINKS=/dev/input/by-path/pci-0000:00:15.1-platform-i2c_designware.1-event

I hope this helps in detecting these devices.

[emersion]

E: ID_PATH=pci-0000:00:15.1-platform-i2c_designware.1

Ah interesting, it seems our logic isn't accounting for this case:

sway/sway/input/libinput.c

Line 317 in 4e77bc2

bool sway_libinput_device_is_builtin(struct sway_input_device *sway_device) {

I think it would be reasonable to match platform devices when they are on a PCI bus -- so with a ID_PATH starting with pci- and containing -platform-. Would you be willing to send a patch?

[ronchaine]

I think it would be reasonable to match platform devices when they are on a PCI bus -- so with a ID_PATH starting with pci- and containing -platform-. Would you be willing to send a patch?

Sure. I'll send a PR in a few.