Calibrating tuhi-live for use with xournal,inkscape or gimp

[vasvir]

Hi,

Not sure this is an actual issue but I didn't find a mailing list / forum to ask. Please point me to the right direction.

So this is the use case. I want to use tuhi-live with some programs such as xournalpp, inkspace and gimp. Right now tuhi-live exports a uhid device which acts like a touchpad? Doesn't feel like a mouse. Don't know really. Maybe someone can explain...

At startup tuhi-live informs the users that is in A4 landscape mode with dimension 29700x21600 point size 10 10mm. This is an aspect ratio of 1.375.

My display is 1920x1080 which has an aspect ratio of 16/9 = 1.77

So there is a difference in the aspect ratio and indeed stuff in xournalpp are displayed a big fatter (squeezed) than on paper. Further more I would like to calibrate the offset of the mouse cursor so the pen pointer does not exceed the limits of the drawing area.

Looking around I found xinput_calibrator some pointers [1. 2. 3]. The [3] is a google sheet that outputs the correct xinput line based on your resolution and your touchpad output.

But AFAIU tuhi-live is already doing some normalization and does not expose the raw values up to [29700, 21600] or is x10 times that (or / 10 that). Not sure.

So is it possible to work online (tuhi-live) with these programs? Are there any suggestions? Pointers?

Thanks in advance.

Vassilis

References:

• [1] https://wiki.archlinux.org/index.php/Calibrating_Touchscreen
• [2] https://wiki.archlinux.org/index.php/Talk:Calibrating_Touchscreen
• [3] https://docs.google.com/spreadsheets/d/13CNQjWfzpEkHM4ZdCcUWDTdQNaFqQ6TYTwatQsYcHcQ/edit?usp=sharing

[whot]

tuhi-live merely creates a tablet device with specific dimensions as we got them from the device (ideally, anything else would be a bug to be fixed). The device itself is largely indistinguishable from a physical device [1] - any aspect ration mapping needs to be done on the next level up, so either in X or in the Wayland Compositor. This includes things like rotation as well for example.

Having tuhi handle aspect ratio mapping would just duplicate that code and make things more complicated (after all, ideally a client stack can identify the different aspect ratios and auto-adjust).

So in summary: unless the dimensions are wrong, tuhi won't change anything here. And "wrong" means properly incorrect, having an axis range not in mm is fine as long as the resolution is set so that the real size can be determined. Would be interesting whas libinput debug-events --verbose says here, it should handle the size etc correctly.

[1] it's possible, but no part of the stack bothers to do so

[vasvir]

I wasn't meant to suggest introducing changes to tuhi except may be one or two lines in the documentation/FAQ if there is an official way to configure.

I was inquiring what other people are using because I am not very familiar with tablets and smartpads. If I could find a mailing list I would ask there. I tried to experiment and look around before before asking in order to make a more insightful question.

I will try libinput debug-events --verbose. Thanks

[whot]

So basically: it's all up to the drivers or the compositor. For a Wayland stack we expect that the compositor (which is also in charge of the display mapping) clips the input coordinates if the device is mapped to a screen, thus forcing the correct aspect ratio.

For the X.Org stack it's more difficult since the driver doesn't know about the monitor and the mapping is generally performed with the coordinate matrix. The wacom driver has the TopX, TopY... options (xsetwacom Area) which can adjust these dimensions. Ideally the desktop environment sets those options when you map to a monitor but I'm not 100% sure this happens. You can adjust them at runtime with xsetwacom or xinput set-prop, google may find a few pointers for those options - I've unfortunately paged all of this out by now.

[vasvir]

I did some tests.

$tuhi-live
22:46:24 INFO: tuhi.wacom: dimensions: 29700x21600, point size 10μm

tuhi-live reports 29700x21600

$libinput list-devices

Device:           Wacom Bamboo Slate Pen
Kernel:           /dev/input/event18
Group:            9
Seat:             seat0, default
Size:             262x206mm
...

libinput reports 262x206

$sudo libinput debug-events --verbose
...
 event18  TABLET_TOOL_AXIS +54.865s             261.93/204.70*  pressure: 0.00
 event18  TABLET_TOOL_AXIS +54.872s             261.93/204.81*  pressure: 0.00
 event18  TABLET_TOOL_AXIS +54.879s             261.93/204.98*  pressure: 0.00
 event18  TABLET_TOOL_AXIS +54.895s             261.93/205.22*  pressure: 0.00

Recording events near bottom right seems to confirm this

$ xinput --list-props 15  # <-- This is the id we got from xinput --list | grep Bamboo
Device 'Wacom Bamboo Slate Pen stylus':
        Device Enabled (185):   1
        Coordinate Transformation Matrix (187): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
        Device Accel Profile (316):     0
        Device Accel Constant Deceleration (317):       1.000000
        Device Accel Adaptive Deceleration (318):       1.000000
        Device Accel Velocity Scaling (319):    10.000000
        Device Node (308):      "/dev/input/event18"
        Wacom Tablet Area (719):        2500, 500, 28700, 21100
        Wacom Rotation (720):   0
        Wacom Pressurecurve (721):      0, 0, 100, 100
        Wacom Serial IDs (471): 1, 1, 2, 0, 0
        Wacom Serial ID binding (722):  0
        Wacom Pressure Threshold (723): 26
        Wacom Sample and Suppress (724):        2, 4
        Wacom Enable Touch (725):       0
        Wacom Hover Click (726):        1
        Wacom Enable Touch Gesture (727):       0
        Wacom Touch Gesture Parameters (728):   0, 0, 250
        Wacom Tool Type (729):  "STYLUS" (718)
        Wacom Button Actions (730):     "Wacom button action 0" (731), "Wacom button action 1" (732), "Wacom button action 2" (733)
        Wacom button action 0 (731):    1572865
        Wacom button action 1 (732):    1572866
        Wacom button action 2 (733):    1572867
        Wacom Pressure Recalibration (734):     1
        Device Product ID (309):        1386, 1
        Wacom Debug Levels (735):       0, 0

The transformation matrix seems to be the identical matrix I and xinput reports: 2500, 500, 28700, 21100 which I don't understand from where it comes from.

I looked for some of these string in tuhi and I didn't find anything. If I understand correctly from your previous reply tuhi-live exposes a device file and Xorg recognizes as Wacom tablet. That means that configuration must be possible with xsetwacom. That also means that any advanced program that speaks to xsetwacom should be able to configure the tablet the way it desires.

I will play a bit with xsetwacom and report back...

[whot]

ftr, you can just run `xinput list-props "Wacom Bamboo Slate Pen stylus" and save the indirect step.

that minor offset is (iirc, been a long time) some offset that we added by default because a lot of the wacom devices tend to have a larger sensor area than visible area. I can't quickly find the code for it though but it does look suspicious. xinput list --long will show you the full axis layout of the device btw including the actual min/max

The stack works roughly this way:

bluetooth-> tuhi-live -> uhid -> kernel -> event node -> xf86-input-wacom

so the wacom driver doesn't know tuhi-live is in the picture, it just picks up yet another event node as if if was a physical device.

[eduncan911]

I think this video explains it best (with great visuals!). It's what convinced me to go ahead and buy my Intuos Pro Paper with my Linux setup.

https://youtube.com/watch?v=BjdbQo0yXB8&list=WL&index=1

(Ignore the Nvidia reference. It had nothing to do with the video and setting Wacom up properly).

Also, maybe it should be added to the FAQs? Then maybe this issue can be closed?