[Linuxwacom-devel] [PATCH libwacom] data: set the 22HD(T) to allow for touch strip modes

[Peter Hutterer]

There is no physical LED to show the current mode, but the tablet was clearly
intended to be used that way [1] and we already reserve two buttons as mode
switch buttons anyway. Declare it correctly and let the userspace stack worry
about displaying mode switches (it's already responsible for changing LEDs
anyway).

[1] "The ambidextrous design of the Cintiq 22HD touch features a pair of
rear-mounted Touch Strips, along with accompanying Touch Strip Toggle buttons.
Each controls up to four application-specific functions, such as brush size,
zooming, scrolling and on-screen canvas rotation."
https://buywacom.com.au/cintiq-22hd-touch.html

Signed-off-by: Peter Hutterer <***@who-t.net>
---
data/cintiq-22hd.tablet | 2 ++
data/cintiq-22hdt.tablet | 2 ++
2 files changed, 4 insertions(+)

diff --git a/data/cintiq-22hd.tablet b/data/cintiq-22hd.tablet
index 54f3219..9c32131 100644
--- a/data/cintiq-22hd.tablet
+++ b/data/cintiq-22hd.tablet
@@ -54,3 +54,5 @@ Right=K;L;M;N;J;O;P;Q;R

Touchstrip=A
Touchstrip2=J
+# Note: no physical LEDs to show mode
+StripsNumModes=4
diff --git a/data/cintiq-22hdt.tablet b/data/cintiq-22hdt.tablet
index 9e74c41..63c5bc5 100644
--- a/data/cintiq-22hdt.tablet
+++ b/data/cintiq-22hdt.tablet
@@ -56,3 +56,5 @@ Right=K;L;M;N;J;O;P;Q;R

Touchstrip=A
Touchstrip2=J
+# Note: no physical LEDs to show mode
+StripsNumModes=4

[Ping Cheng]

Post by Peter Hutterer
There is no physical LED to show the current mode, but the tablet was clearly
intended to be used that way [1] and we already reserve two buttons as mode
switch buttons anyway. Declare it correctly and let the userspace stack worry
about displaying mode switches (it's already responsible for changing LEDs
anyway).

If user space agrees with your suggestion, I am all for it!

Reviewed-by: Ping Cheng <***@wacom.com>

Thank you for the patch.

Ping

Post by Peter Hutterer
[1] "The ambidextrous design of the Cintiq 22HD touch features a pair of
rear-mounted Touch Strips, along with accompanying Touch Strip Toggle buttons.
Each controls up to four application-specific functions, such as brush size,
zooming, scrolling and on-screen canvas rotation."
https://buywacom.com.au/cintiq-22hd-touch.html
---
data/cintiq-22hd.tablet | 2 ++
data/cintiq-22hdt.tablet | 2 ++
2 files changed, 4 insertions(+)
diff --git a/data/cintiq-22hd.tablet b/data/cintiq-22hd.tablet
index 54f3219..9c32131 100644
--- a/data/cintiq-22hd.tablet
+++ b/data/cintiq-22hd.tablet
@@ -54,3 +54,5 @@ Right=K;L;M;N;J;O;P;Q;R
Touchstrip=A
Touchstrip2=J
+# Note: no physical LEDs to show mode
+StripsNumModes=4
diff --git a/data/cintiq-22hdt.tablet b/data/cintiq-22hdt.tablet
index 9e74c41..63c5bc5 100644
--- a/data/cintiq-22hdt.tablet
+++ b/data/cintiq-22hdt.tablet
@@ -56,3 +56,5 @@ Right=K;L;M;N;J;O;P;Q;R
Touchstrip=A
Touchstrip2=J
+# Note: no physical LEDs to show mode
+StripsNumModes=4
--
2.9.3

[Bastien Nocera]

Post by Peter Hutterer
There is no physical LED to show the current mode, but the tablet was clearly
intended to be used that way [1] and we already reserve two buttons as mode
switch buttons anyway. Declare it correctly and let the userspace stack worry
about displaying mode switches (it's already responsible for changing LEDs
anyway).
[1] "The ambidextrous design of the Cintiq 22HD touch features a pair of
rear-mounted Touch Strips, along with accompanying Touch Strip Toggle buttons.
Each controls up to four application-specific functions, such as brush size,
zooming, scrolling and on-screen canvas rotation."
https://buywacom.com.au/cintiq-22hd-touch.html

Looks like this would need user-space changes to show an OSD when the
feature is being used. In the meanwhile, I'd hold off on making a
change until at least one front-end implemented the functionality.

[Ping Cheng]

Post by Bastien Nocera

Post by Peter Hutterer
There is no physical LED to show the current mode, but the tablet was clearly
intended to be used that way [1] and we already reserve two buttons as mode
switch buttons anyway. Declare it correctly and let the userspace stack worry
about displaying mode switches (it's already responsible for changing LEDs
anyway).
[1] "The ambidextrous design of the Cintiq 22HD touch features a pair of
rear-mounted Touch Strips, along with accompanying Touch Strip Toggle buttons.
Each controls up to four application-specific functions, such as brush size,
zooming, scrolling and on-screen canvas rotation."
https://buywacom.com.au/cintiq-22hd-touch.html

Looks like this would need user-space changes to show an OSD when the
feature is being used. In the meanwhile, I'd hold off on making a
change until at least one front-end implemented the functionality.

Maybe it's not a bad idea to make the change now so front-end can rely
on it when user-space is ready, as long as the change won't break the
existing user-space implementation. Does that make sense?

Ping

[Bastien Nocera]

Post by Ping Cheng

Post by Bastien Nocera

Post by Peter Hutterer
There is no physical LED to show the current mode, but the tablet
was
clearly
intended to be used that way [1] and we already reserve two
buttons
as mode
switch buttons anyway. Declare it correctly and let the userspace stack worry
about displaying mode switches (it's already responsible for
changing
LEDs
anyway).
[1] "The ambidextrous design of the Cintiq 22HD touch features a
pair
of
rear-mounted Touch Strips, along with accompanying Touch Strip
Toggle
buttons.
Each controls up to four application-specific functions, such as brush size,
zooming, scrolling and on-screen canvas rotation."
https://buywacom.com.au/cintiq-22hd-touch.html

Looks like this would need user-space changes to show an OSD when the
feature is being used. In the meanwhile, I'd hold off on making a
change until at least one front-end implemented the functionality.

Maybe it's not a bad idea to make the change now so front-end can rely
on it when user-space is ready, as long as the change won't break the
existing user-space implementation. Does that make sense?

If you made that change without the corresponding user-space changes,
you'd have a button that used to work as simply a button, and that now
would change modes without any feedback as to which mode it's using.

I would at least expect a bug filed explaining the intent (for GNOME I
guess), so that Carlos has a chance to look into how we'd hook the UI
for this.

It might be a one-liner once a lot of the calibration and setup UI has
moved into the shell but we won't know until we're there.

Cheers

[Peter Hutterer]

Post by Bastien Nocera

Post by Ping Cheng

Post by Bastien Nocera

Post by Peter Hutterer
There is no physical LED to show the current mode, but the tablet
was
clearly
intended to be used that way [1] and we already reserve two
buttons
as mode
switch buttons anyway. Declare it correctly and let the userspace stack worry
about displaying mode switches (it's already responsible for
changing
LEDs
anyway).
[1] "The ambidextrous design of the Cintiq 22HD touch features a
pair
of
rear-mounted Touch Strips, along with accompanying Touch Strip
Toggle
buttons.
Each controls up to four application-specific functions, such as brush size,
zooming, scrolling and on-screen canvas rotation."
https://buywacom.com.au/cintiq-22hd-touch.html

Looks like this would need user-space changes to show an OSD when the
feature is being used. In the meanwhile, I'd hold off on making a
change until at least one front-end implemented the functionality.

Maybe it's not a bad idea to make the change now so front-end can rely
on it when user-space is ready, as long as the change won't break the
existing user-space implementation. Does that make sense?

If you made that change without the corresponding user-space changes,
you'd have a button that used to work as simply a button, and that now
would change modes without any feedback as to which mode it's using.

the buttons are already assigned to the strips. not 100% what gnome does,
but I'd expect them to be dead right now given they're assigned to the
strips but the strips have no mode.

Post by Bastien Nocera
I would at least expect a bug filed explaining the intent (for GNOME I
guess), so that Carlos has a chance to look into how we'd hook the UI
for this.

see https://bugzilla.gnome.org/show_bug.cgi?id=771098

Cheers,
Peter

Post by Bastien Nocera
It might be a one-liner once a lot of the calibration and setup UI has
moved into the shell but we won't know until we're there.
Cheers

[Ping Cheng]

On Sun, Oct 30, 2016 at 2:58 PM, Peter Hutterer

Post by Peter Hutterer

Post by Bastien Nocera

Post by Ping Cheng

Post by Bastien Nocera

Post by Peter Hutterer
There is no physical LED to show the current mode, but the tablet
was
clearly
intended to be used that way [1] and we already reserve two
buttons
as mode
switch buttons anyway. Declare it correctly and let the userspace stack worry
about displaying mode switches (it's already responsible for
changing
LEDs
anyway).
[1] "The ambidextrous design of the Cintiq 22HD touch features a
pair
of
rear-mounted Touch Strips, along with accompanying Touch Strip
Toggle
buttons.
Each controls up to four application-specific functions, such as brush size,
zooming, scrolling and on-screen canvas rotation."
https://buywacom.com.au/cintiq-22hd-touch.html

Looks like this would need user-space changes to show an OSD when the
feature is being used. In the meanwhile, I'd hold off on making a
change until at least one front-end implemented the functionality.

Maybe it's not a bad idea to make the change now so front-end can rely
on it when user-space is ready, as long as the change won't break the
existing user-space implementation. Does that make sense?

If you made that change without the corresponding user-space changes,
you'd have a button that used to work as simply a button, and that now
would change modes without any feedback as to which mode it's using.

the buttons are already assigned to the strips. not 100% what gnome does,
but I'd expect them to be dead right now given they're assigned to the
strips but the strips have no mode.

Post by Bastien Nocera
I would at least expect a bug filed explaining the intent (for GNOME I
guess), so that Carlos has a chance to look into how we'd hook the UI
for this.

see https://bugzilla.gnome.org/show_bug.cgi?id=771098

Then, please merge the patch so we make the request official ;). Maybe
also add the above info to your commit comments.

Thank you both!

Ping