Tablet no longer maps to area correctly

[Stoppedpuma]

Hyprland Version

System/Version info

Hyprland, built from branch main at commit 494b9415a1157279a1e1782ba635fc2ef6a18155  (layersurface: avoid restack on identical layers).
Tag: v0.40.0-62-g494b9415, commits: 4668

flags: (if any)

System Information:
System name: Linux
Release: 6.8.9-273-tkg-eevdf-llvm
Version: #1 SMP PREEMPT_DYNAMIC TKG

GPU information: 
0c:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 22 [Radeon RX 6700/6700 XT/6750 XT / 6800M/6850M XT] [1002:73df] (rev c5) (prog-if 00 [VGA controller])

Bug or Regression?

Regression

Description

Caused by #5902 I'm assuming.

Tablet area and display area in OpenTabletDriver no longer map correctly, neither the tablet area or display area seem to work correctly.

Possible reason this might not have been reported in the PR is that I'm using two displays?

Crash reports, logs, images, videos

Video showing cursor stopping near the middle of the screen:

1715453401.mp4

Screenshot of the display area in OpenTabletDriver:

[Agent00Ming]

Yeah, I can replicate. Hyprland ignores what opentabletdriver is mapped to and automatically maps to the display your cursor is on. You can leave the opentabletdriver mapping to default (whole area/virtual display?) and Hyprland will do it's thing. You can set which monitor to map your tablet to in input:tablet:output=

(It wasn't reported because next to no tablet users showed up to test it. I didn't even have a tablet for the first two days of the PR)

[Stoppedpuma]

Hyprland ignores what opentabletdriver is mapped to

Is this the way planned forward or just an oversight? I don't think that ignoring the drivers configuration is the best way of handling multiple displays? It kind of makes sense in terms of it being an input but it basically just throws away the configuration fluency that works everywhere else. If it is going to be this way then maybe tablet:output=driver or something would be a good default to prevent messing with configurations?

[Agent00Ming]

"Be the change you want to see". I'll look at the code and see if there's a better way to manage this (add a config maybe?). Stock behaviour has definitely changed from before #5902 and vaxry doesn't even have a tablet to test with 😝

[vaxerski]

correct, I don't

[Deftera186]

I have the same problem with two monitors. A weird thing worth mentioning is that I don't know if it's related to this issue or should be in another issue, but it seems like my monitors are placed at weird coordinates.
Running hyprctl monitors will give:

Monitor HDMI-A-1 (ID 0):
	1920x1080@74.97300 at 0x0
	...

Monitor HDMI-A-2 (ID 1):
	1920x1080@60.00000 at -1920x0
	....

I'm using the new auto positions introduced in #5670

monitor=HDMI-A-1,1920x1080@74.97Hz,auto,1
monitor=HDMI-A-2,preferred,auto-left,1

[Agent00Ming]

Apparently this is an open issue on the OpenTabletDriver github issue tracker concerning this behaviour in KDE Plasma as well. 🤔 They describe the workaround being to let the compositor decide how to map things just like I've said here #6023 (comment). I've been having my fair share of obscure bugs with OTD (things that I can't replicate with libwacom kernel driver) so I don't know if it's even worth trying. Mapping in the driver is broken on wayland compositors that automatically map to monitors by default (Kwin, Hyprland, etc) and the behaviour of the mapping isn't even consistent on the different modes that OTD offers (absolute and artist have some weird differences and relative is a whole different beast).

[Stoppedpuma]

I would still think having an option would be preferable? Breaking configuration compatibility which works nearly everywhere else OOTB is probably not the best option in my opinion, especially when "nearly everywhere" includes other operating systems. If an option is off the table then makes more sense to me to control externally managed drivers such as OTD on their driver and to have those "built into hyprland" (libwacom?) / not managed externally to be configured in the configuration file? It just leads to less problems on the users side in my eyes.

[Agent00Ming]

libwacom and digimend-kernel-drivers are the gold standard for graphics tablet support across the Linux landscape. OTD seems to be having some trouble with wayland support in regards to their own driver implementation, I'd wait until they fix up their many issues regarding mapping on wayland compositors in general (they have an issue on Gnome monitor mapping as well if you look through their issue tracker). The previous behaviour was at best undocumented (I didn't even have a tablet back then).

[Agent00Ming]

I agree that it would be nice to have the option but I can't seem to make use of OTD without encountering some serious driver issues when iterating so I won't be continuing the debugging process on my end.

[CobaltSpace]

Tablet is being restricted to output only on monitor currently focused on, even when set to unbound.

It should instead be that the tablet maps to the entire layout of all active outputs. This matches the behavior of other desktops (xorg, kde, gnome, sway, hyprland <= 0.40.0)

That was the issue I made before being directed to this issue. I discovered this issue trying to play vr and use wlx-overlay-s, and was told by their maintainers when I brought up the issue:

i'd make a ticket that the absolute pointer input should by default be mapped like on other desktops (xorg, kde, gnome). to the rectangle that encapsulates all screens

Would that fall under this issue or should it be its own?

[Agent00Ming]

@Stoppedpuma check out #7586

[Agent00Ming]

Should be fixed. #8352