[PATCH libinput 5/7] tablet: add support for relative x/y motion deltas

[Peter Hutterer]

On Tue, Jan 19, 2016 at 12:23:22PM -0800, Bill Spitzak wrote:
> On Mon, Jan 18, 2016 at 1:57 PM, Peter Hutterer <peter.hutterer at who-t.net>
> wrote:
> 
> >
> > mapping aspect ratio will be the job of the compositor. In reality, this
> > will mean that one of the axes will be shortened to match the ratio.
> >
> 
> Yes I believe the compositor has to do this. libinput obviously cannot, and
> I don't think clients can do this.
> 
> if absolute mode on your tablet is "completely useless" that would indicate
> > you never looked at wacom(4) or any instructions on how to fix this. We've
> > had config options to adjust this for years.
> >
> 
> I am well aware of the wacom command, and use it. Setting a working
> relative mode is really painful, and also does not survive reboot or
> sleep/wakeup. 

xorg.conf snippets? or, better, let your desktop environment handle this.

> I have a batch file that I run every time in order to fix the
> tablet, here are the contents:
> 
> xsetwacom --set "Wacom Intuos3 6x8 stylus" Mode Relative
> xsetwacom --set "Wacom Intuos3 6x8 stylus" Area "0 0 162560 121920"
> xsetwacom --set "Wacom Intuos3 6x8 eraser" Mode Relative
> xsetwacom --set "Wacom Intuos3 6x8 eraser" Area "0 0 162560 121920"
> 
> Absolute mode on my tablet is completely useless, at least for drawing and
> 3d modelling. The tablet is 8" wide and 6" tall. My two HDTV monitors side
> by side are about 43" wide and 12" tall. Therefore the physical scaling
> from pen motion to cursor motion is about 5x horizontally and 2x
> vertically. This scale makes it impossible to do fine detail without so
> much zooming in that I have cropped off all useful context, and the aspect
> ratio difference makes it impossible to transfer muscle memory used for
> drawing with a physical pen or a tablet on a different device to this one.
> 
> I still find it hard to believe my situation is unique. Vastly more small
> tablets are sold than big desktop-sized ones.

you want to control two side-by-side monitors with the same tablet - yes
that is a fairly niche use-case. it's probably not unique, but I avoid the
term unique anyway because human ingenuity knows no bounds (or reason). see
the xkcd workflow comic for reference.

so let me state that now: mapping a 8:6 tablet to a 4:1 output is not a
use-case that we will focus on. the only way to make this useful is by
reducing the tablet area so much that most of it becomes useless.
 
> A few ideas that will make xsetwacom a bit less painful:

xsetwacom is a run-time configuration tool that is older than things like
input device hotplugging. it has a specific use-case but permanent
configuration is not it.

> 1. Should be able to set the relative and absolute mapping with one
> command, rather than one per tool. This is independent of whether the tool
> is relative or absolute. If you really want add a way to override it per
> tool, but setting the default would help. My above code only works because
> I only have a pen and eraser, if I added another tool I would have to fix
> this.

no. if you're using xsetwacom you're already resigned to shell scripts, at
that point it's easy to extend this. xsetwacom will remain simple.

> 2. Relative mode should default to some square aspect and the size should
> not depend on the screens in any way. I think this basically means that the
> relative and absolute rectangles are different. The absolute rectangle is
> completely under control of the compositor, which is well aware of the size
> of the outputs, or any api by clients to restrict the tablet to an area.

that's a problem with the way how the server handles relative events from
absolute devices. wayland won't have that problem.
 
> 3. (this is my only real proposal that would differ from existing systems):
> I think the system could automatically switch to relative mode if the
> absolute area exceeds the relative area by too large a factor. In my
> experience this is as small as 1, but it is possible other users would
> disagree. At least use this to initialize a new device before the user
> customizes it.

this is policy that belongs into the compositor. and frankly, this is a
niche case that is not worth auto-detecting, it's a single checkbox away if
the user needs it and the compositor wants to support that use case.

Cheers,
   Peter