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)

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?

"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 😝

correct, I don't

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):
	[email protected] at 0x0
	...

Monitor HDMI-A-2 (ID 1):
	[email protected] at -1920x0
	....

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

monitor=HDMI-A-1,[email protected],auto,1
monitor=HDMI-A-2,preferred,auto-left,1

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).

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.

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).

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.

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?

@Stoppedpuma check out #7586