[Linuxwacom-devel] ScreenNo

[Markus Kuhn]

I am trying to use my Wacom Cintiq 13HD in what some call a
"ZaphodHead" configuration, i.e. where my xorg.conf file
has dual sections for Device, Screen and Monitor,
one for my regular 1600x1200 desktop display (DISPLAY=:0) and one for
the 1920x1080 display in the tablet (DISPLAY=:0.1).

Unfortunately, I have not managed to find a way in xorg.conf
to constrain the stylus range of the Wacom tablet to just one
of my two Screens (namely the DISPLAY=:0.1 one). Instead, the
stylus always travels horizontally across a 1600+1920 wide
virtual screen, which obviously breaks positioning on the tablet
display.

I just noticed that the exact functionality I was hoping for did
in fact exist in the past, in form of

Option "ScreenNo" "1"

but was removed in commit 4ffd3c64ca29a637bf1d2c69b11e360e8d8a82f5:

Author: Peter Hutterer <***@who-t.net> 2010-11-24 05:02:15

Purge ScreenNo handling.
The definition of ScreenNo isn't clear, given that we have RandR screens,
ScreenRecs and protocol screens, not all of which overlap totally. Let the
mapping of the tablet to a given area on the available desktop be handled by
a client.

That removed option seemed to do exactly what I wanted (for
protocol screens) ... :-(

Is there now any other way in /etc/X11/xorg.conf.d/ (or a similar
global config file) to bind the absolute coordinate range of a wacom
tablet to just one single screen?

I would very much like this binding between screen and tablet
to be done properly from the very beginning by the X server,
in a system-wide configuration file for all users (like xorg.conf),
before the user logs into a display manager. I therefore would
like to avoid user clients such as "xsetwacom set 14 MapToOutput ..."
that only kick in after login.

Is there no chance to bring Option "ScreenNo" back,
perhaps with a slightly changed syntax to make the
semantics unambiguous?

What was gained be dropping the existing multi-head support
from the driver?

Markus
--
Markus Kuhn, Computer Laboratory, University of Cambridge
http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain



P.S.: I was hoping to get this to work on Ubuntu 16.04:

Section "ServerLayout"
Identifier "LectureRecording"
Screen 0 "Screen-Desktop"
Screen 1 "Screen-Tablet" RightOf "Screen-Desktop"
InputDevice "Cintiq 13HD stylus mgk"
EndSection

Section "Screen"
Identifier "Screen-Desktop"
Device "Intel0"
Monitor "Samsung"
EndSection

Section "Screen"
Identifier "Screen-Tablet"
Device "Intel1"
Monitor "Cintiq 13HD"
EndSection

Section "Monitor"
Identifier "Samsung"
EndSection

Section "Monitor"
Identifier "Cintiq 13HD"
EndSection

Section "Device"
Identifier "Intel0"
Driver "intel"
BusID "PCI:0:2:0"
Screen 0
Option "Monitor-HDMI3" "Samsung"
Option "ZaphodHeads" "HDMI3"
EndSection

Section "Device"
Identifier "Intel1"
Driver "intel"
BusID "PCI:0:2:0"
Screen 1
Option "Monitor-HDMI1" "Cintiq 13HD"
Option "ZaphodHeads" "HDMI1"
EndSection

Section "InputDevice"
Identifier "Cintiq 13HD stylus mgk"
Driver "wacom"
Option "Type" "stylus"
Option "ScreenNo" "1" <-- no effect :-(
Option "MMonitor" "off" <-- no effect :-(
EndSection

------------------------------------------------------------------------------

[Juan]

Hi Markus!

I have a similar problem and I fixed this way:

1. Get your device name
xsetwacom --list devices
Wacom ... Pen stylus id: 11 type: STYLUS

2. Your screen:
xrandr -q
Screen 0: minimum 320 x 200, current 4400 x 6000 (< I think that Wacom
uses the sum of all real screens)
HDMI9 connected ...

3. Set it:
xsetwacom --set "Wacom ... Pen stylus" MapToOutput HDMI9


I can't help you more because I'm a newbie, but maybe this could help
you until you find how to configure Xorg.

Juan

------------------------------------------------------------------------------

[Peter Hutterer]

Post by Markus Kuhn
I am trying to use my Wacom Cintiq 13HD in what some call a
"ZaphodHead" configuration, i.e. where my xorg.conf file
has dual sections for Device, Screen and Monitor,
one for my regular 1600x1200 desktop display (DISPLAY=:0) and one for
the 1920x1080 display in the tablet (DISPLAY=:0.1).
Unfortunately, I have not managed to find a way in xorg.conf
to constrain the stylus range of the Wacom tablet to just one
of my two Screens (namely the DISPLAY=:0.1 one). Instead, the
stylus always travels horizontally across a 1600+1920 wide
virtual screen, which obviously breaks positioning on the tablet
display.
I just noticed that the exact functionality I was hoping for did
in fact exist in the past, in form of
Option "ScreenNo" "1"
Purge ScreenNo handling.
The definition of ScreenNo isn't clear, given that we have RandR screens,
ScreenRecs and protocol screens, not all of which overlap totally. Let the
mapping of the tablet to a given area on the available desktop be handled by
a client.
That removed option seemed to do exactly what I wanted (for
protocol screens) ... :-(
Is there now any other way in /etc/X11/xorg.conf.d/ (or a similar
global config file) to bind the absolute coordinate range of a wacom
tablet to just one single screen?
I would very much like this binding between screen and tablet
to be done properly from the very beginning by the X server,
in a system-wide configuration file for all users (like xorg.conf),
before the user logs into a display manager. I therefore would
like to avoid user clients such as "xsetwacom set 14 MapToOutput ..."
that only kick in after login.
Is there no chance to bring Option "ScreenNo" back,
perhaps with a slightly changed syntax to make the
semantics unambiguous?
What was gained be dropping the existing multi-head support
from the driver?

maintainability. ScreenNo predates the ability to hotplug screens in X,
these days a protocol screen like you use it is the exception, not the rule.

the problem with ScreenNo isn't the ambiguity, it's that it just doesn't
really apply when a screen isn't already plugged in on boot. in many cases,
the screen order isn't clear until after login, e.g. when you use xrandr to
arrange the displays.

Cheers,
Peter

------------------------------------------------------------------------------

[Markus Kuhn]

Post by Peter Hutterer
these days a protocol screen like you use it is the exception, not the rule.
the problem with ScreenNo isn't the ambiguity, it's that it just doesn't
really apply when a screen isn't already plugged in on boot. in many cases,
the screen order isn't clear until after login, e.g. when you use xrandr to
arrange the displays.

The xrandr model, namely all displays just showing parts of a single
virtual screen, can cause problems in situations were one screen
really serves a completely different purpose from the other screen,
i.e. were you really don't want windows to go across screens,
or where a screen is linked to an input device that is meant to
provides absolute coordinates for one screen only.

When I try to use xinput_calibrator to calibrate a touchpanel
against its built-in screen, under xrandr it really gets confused
about the size of the physical screen versus the size of
xrandr's virtual screen. xinput_calibrator opens its window
across both my desktop and my Cintiq 13HD, and there is no
option to tell it to cover just the latter. Even if there were,
there would still be a risk that stylus coordinates at the edge of the
tablet could leak into the other screen.

Protocol screens used to be a very convenient way to keep
screens separate, rather than confuse applications by screens
sharing the same coordinate system.

If integer protocol screen numbers really are no longer viable, is
there no other conceivable way to unambiguously bind the
coordinate system of an "absolute" input device to the coordinate
system of just one physical output of a graphics card? For example
by providing a new option to specify under Section "InputDevice" the
identifier of a corresponding Section "Screen" in xorg.conf
(just like Option "ScreenNo" "0" did, just not using integers
that might depend on hot-plug order, but something that actually
refers to a named device driver instance, Port-ID, Bus-ID, whatever).

Markus

[Peter Hutterer]

Post by Markus Kuhn

Post by Peter Hutterer
these days a protocol screen like you use it is the exception, not the rule.
the problem with ScreenNo isn't the ambiguity, it's that it just doesn't
really apply when a screen isn't already plugged in on boot. in many cases,
the screen order isn't clear until after login, e.g. when you use xrandr to
arrange the displays.

The xrandr model, namely all displays just showing parts of a single
virtual screen, can cause problems in situations were one screen
really serves a completely different purpose from the other screen,
i.e. were you really don't want windows to go across screens,
or where a screen is linked to an input device that is meant to
provides absolute coordinates for one screen only.
When I try to use xinput_calibrator to calibrate a touchpanel
against its built-in screen, under xrandr it really gets confused
about the size of the physical screen versus the size of
xrandr's virtual screen. xinput_calibrator opens its window
across both my desktop and my Cintiq 13HD, and there is no
option to tell it to cover just the latter. Even if there were,
there would still be a risk that stylus coordinates at the edge of the
tablet could leak into the other screen.
Protocol screens used to be a very convenient way to keep
screens separate, rather than confuse applications by screens
sharing the same coordinate system.
If integer protocol screen numbers really are no longer viable, is
there no other conceivable way to unambiguously bind the
coordinate system of an "absolute" input device to the coordinate
system of just one physical output of a graphics card? For example
by providing a new option to specify under Section "InputDevice" the
identifier of a corresponding Section "Screen" in xorg.conf
(just like Option "ScreenNo" "0" did, just not using integers
that might depend on hot-plug order, but something that actually
refers to a named device driver instance, Port-ID, Bus-ID, whatever).

the input transformation matrix that's used for calibration (and by the
varous map-to-screen options) is just a matrix that represents the whole
screen estate, normalised to [0, 1.0). So you can use it to map to any area
on the screen, regardless of whether it's a protocol screen, a normal
screen, or just an area.

Cheers,
Peter


------------------------------------------------------------------------------