Rely on MapToOuput

[chabad360]

This PR removes the remapping code as xinput --maptooutput is meant to do the same thing (just better), and the remapping is now both redundant and has been causing (at least) me margin issues.

[Evidlo]

I don't want users to have to call xinput manually to set up orientation and scaling. It should be done automatically based on --orientation, --mode, and --monitor.

[chabad360]

Agreed, the thing is, setting the Wacom Tablet Area is (to my understanding) the "old way" of doing things. Besides, we already run xinput --maptooutput (it's the first of a few xinputs commands you run) so that's a bit of a non-issue. If your worried about orientation, I'll test to see how it's affected, but I don't think it will be an issue.

Regarding --mode, what was the reason for it in the first place?

[chabad360]

Regarding --mode, what was the reason for it in the first place?

That seems to have been answered in #21, in which case perhaps it would be best to do what Wacom does:

5. Select Force Proportions if you want the vertical and horizontal proportions to be the same on your device as on your monitors.

   • If you select Force Proportions , when you draw a circle on the device, you see a circle on the display screen, but a portion of the device active area that was previously usable may no longer be usable.
   • If you do not select Force Proportions, when you draw a circle on the device, you may see an ellipse on the display screen.

I.e. either it's stretched, or it's fit.

[Evidlo]

If we ignore the current behavior of --mode for the moment, do the other arguments map nicely into xinput commands?

[chabad360]

They already are.

[Evidlo]

OK, we can drop the current behavior of --mode and remove the remapping functions as long as the calls to xinput are subprocessed based on --mode, --orientation, and --monitor.

[chabad360]

I added some code (only for --evdev) that makes fill equal to stretch and also reworks the remap() math (could be refactored) to avoid a few quirks.

I needed to add some remapping code because there isn't a straight forward way of changing the fit of the display.

[Evidlo]

I needed to add some remapping code because there isn't a straight forward way of changing the fit of the display.

What mapping modes are supported natively by --map-to-output?

[chabad360]

To my knowledge just "stretch".

[Evidlo]

I think the most robust option is going to be computing the coordinate transform matrix: https://wiki.ubuntu.com/X/InputCoordinateTransformation

[chabad360]

I'm inclined to disagree for a few reasons:

• Affine Transforms are harder to understand (and calculate).
• Using CTMs isn't even mentioned as a potential method for solving this issue in any docs (that I could find).
• The previous leads me to believe that there might be a footgun (or some other trouble) that comes along with it.

Regardless, I don't understand why it's the most robust. If you want to argue that it would allow us to put all three mappings (monitor, fit, orientation) all in one call, that's fair. But you're going to want a rather large comment to explain how it works and why we did it (a large comment for what would be a rather large function).

[chabad360]

@Evidlo ping?

[Evidlo]

If --map-to-output really only supports stretch (no rotation, no fill mode, no monitor selection?), then I'm not a fan of switching everything to it. I'd rather just fix whatever margin issues you mentioned you were having.

[chabad360]

--map-to-output is meant for mapping the tablet to a specific monitor, you already use it for this. Rotation is handled by setting "Wacom Rotation", and fill mode is always stretch (unless we do some math).

It appears that --map-to-output uses a CTM for the underlying calculation (and they even documented it in the wiki, so I was wrong), so perhaps we could use that. But, I don't think I have the patience to figure out add aspect ratio preservation to that calculation. I may spend some time on it if I'm bored, but bored won't be for a little while.

[Evidlo]

Going to be phasing out subprocessing of xinput in anticipation of Wayland support. Sorry about that.

https://gitlab.freedesktop.org/libevdev/python-libevdev/-/issues/10

[chabad360]

Exclusive Wayland support?

I would think it would make sense to keep this (or the idea of it at least) in some form. As a lot of people are still using Xorg.

[Evidlo]

No, I'm just planning on doing remapping internally so I can use the same function for pynput/evdev/wayland.