Quantcast

Wacom Intuos3 9x12: Touchstrips don't scroll in Linux Mint, and possible bug

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Wacom Intuos3 9x12: Touchstrips don't scroll in Linux Mint, and possible bug

APrunai@email.it
Hello, and first and foremost, a huge "thank you" for all the work you
devote to this project! I've been using Wacom tablets for years and I'm
happy to be able to use my Intuos3 on Linux. It's thanks to hard work
such this that we can use and enjoy free software.
Recently I've switched to Linux Mint 17.2 and, with my great surprise, I
found that my tablet - though perfectly recognized on-the-fly and with
configurable buttons through Mint's system preferences - had no scroll
mapped to its touchstrips. I tried to map it by myself, first through
both prefs and dconf-editor, then via xsetwacom; everything led to
insuccess. The touchstrip does nothing, or it behaves quite strangely:
i.e., let's assume that I map something to Button 4 (I use the ShowHelp
function to have an immediate feedback); whenever I press the 4th button
on my Wacom, I will correctly see the beautiful Help screen popping
on-screen. Now if I issue the line:

xsetwacom --set "Wacom Intuos3 9x12 pad" StripRightUp 4

then, every time I scroll the right strip up, the Help screen will pop
up!! To recap, the strip is being told to point to the tablet's Button
#4... and not to Xorg's mouse button 4 (Scroll Up). A bit
self-referential if you ask me :)
Seriously, is this the intended behavior, or is it a bug? And in the
first hypothesis, what would the appropriate syntax?

Thanks!

Alessandro Prunai
Italy

 
 
 --
 ZE-Light e ZE-Pro: servizi zimbra per caselle con dominio email.it, per tutti i dettagli
Clicca qui http://posta.email.it/caselle-di-posta-z-email-it/?utm_campaign=email_Zimbra_102014=main_footer/f
 
 Sponsor:
 Caselle con tuo dominio su piattaforma Zimbra, fino a 30 GB di spazio, sincronizzazione dati e backup
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=13324&d=9-11

------------------------------------------------------------------------------
Presto, an open source distributed SQL query engine for big data, initially
developed by Facebook, enables you to easily query your data on Hadoop in a
more interactive manner. Teradata is also now providing full enterprise
support for Presto. Download a free open source copy now.
http://pubads.g.doubleclick.net/gampad/clk?id=250295911&iu=/4140
_______________________________________________
Linuxwacom-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/linuxwacom-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wacom Intuos3 9x12: Touchstrips don't scroll in Linux Mint, and possible bug

Jason Gerecke
On 11/9/2015 1:56 PM, [hidden email] wrote:

> Hello, and first and foremost, a huge "thank you" for all the work you
> devote to this project! I've been using Wacom tablets for years and I'm
> happy to be able to use my Intuos3 on Linux. It's thanks to hard work
> such this that we can use and enjoy free software.
> Recently I've switched to Linux Mint 17.2 and, with my great surprise, I
> found that my tablet - though perfectly recognized on-the-fly and with
> configurable buttons through Mint's system preferences - had no scroll
> mapped to its touchstrips. I tried to map it by myself, first through
> both prefs and dconf-editor, then via xsetwacom; everything led to
> insuccess. The touchstrip does nothing, or it behaves quite strangely:
> i.e., let's assume that I map something to Button 4 (I use the ShowHelp
> function to have an immediate feedback); whenever I press the 4th button
> on my Wacom, I will correctly see the beautiful Help screen popping
> on-screen. Now if I issue the line:
>
> xsetwacom --set "Wacom Intuos3 9x12 pad" StripRightUp 4
>
> then, every time I scroll the right strip up, the Help screen will pop
> up!! To recap, the strip is being told to point to the tablet's Button
> #4... and not to Xorg's mouse button 4 (Scroll Up). A bit
> self-referential if you ask me :)
> Seriously, is this the intended behavior, or is it a bug? And in the
> first hypothesis, what would the appropriate syntax?
>
> Thanks!
>
> Alessandro Prunai
> Italy
>

Alessandro,

Sorry for the delay in replying. Unfortunately, setting up the strips to
scroll in GNOME/Unity/Cinnamon is non-trivial. Scrolling isn't an action
you can choose, and the "gnome-settings-daemon" process (which is
responsible for carrying out all the settings set through the control
panel) inserts itself as a middleman between the X server and
applications which effectively prevents xsetwacom from working as
expected (see the technical details below if you're interested in what's
going on under the hood).

I can think of two ways to get scrolling to work. The first would be to
use a combination of two tools: "xbindkeys"[1] and "xdotool"[2]. The
former can be configured to run commands in response to keyboard
shortcuts, and the latter can simulate mouse clicks (including
scrolling) when run. To do this, you would want to configure the strips
to send a unique keyboard shortcuts in the control panel, and then set
up xindkeys to run xdotool in response to the shortcuts. It is a very
roundabout process, but should work.

Alternately, you can disable the "gsdwacom" plugin of
gnome-settings-daemon so that it no longer acts as a middleman. This
will allow xsetwacom to work normally and is much more straightforward,
but causes the control panel settings to have no effect on the tablet.
To do this, run:

$ gsettings set org.gnome.settings-daemon.plugins.gsdwacom active false


[1]: http://www.nongnu.org/xbindkeys/xbindkeys.html
[2]: http://www.semicomplete.com/projects/xdotool


## GEEKY TECHNICAL DETAILS:

For gnome-settings-daemon (which is used by GNOME, Unity, Cinnamon, etc.
as the business end of the control panel) to do its magic, it "grabs"
all events from the tablet before any other application can see them and
then either performs some internal action (e.g. popping up the help
screen) or injects a replacement event into X (e.g. a keypress) for
other applications to see.

To determine the correct action to perform, gnome-settings-daemon
translates the mouse button number that it receives from X into an
associated "physical" button number. This is necessary because our
driver skips mouse buttons 4-7 to prevent the ExpressKeys from sending
scroll and navigation events by default.

The weirdness in this case lies in their translation function.
Specifically, it does not ignore mouse buttons 4-7, and so ends up
claiming that they are associated with the 4th, 1st, 2nd, and 3rd
ExpressKey. If you use xsetwacom to have our driver send scroll events
(from the strips, rings, or even ExpressKeys) then gnome-settings-daemon
ends up believing that you're pressing one of those ExpressKeys and acts
accordingly.

Ideally, gnome-settings-daemon would either ignore those four mouse
buttons or inject replacement mouse events so that scrolling and
navigation worked properly. Even more ideally, it would map the strips
and rings to scroll (or allow you to set them to scroll in the control
panel) so that you never have to touch xsetwacom in the first place ;)

Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to say, eight) to the two, /
But you can’t take seven from three, /
So you look at the sixty-fours....

------------------------------------------------------------------------------
_______________________________________________
Linuxwacom-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/linuxwacom-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wacom Intuos3 9x12: Touchstrips don't scroll in Linux Mint, and possible bug

APrunai@email.it
In reply to this post by APrunai@email.it
Hi Jason,

don't worry, and thank you very much for your answer! It's very
complete, and I understood pretty well what's happening under the hood
(well, as far as my limited knowledge of GNU allows me).

I tried the first method (xbindkeys + xdotool) and it works all right,
though the scrolling is resulting a bit jerky; maybe the continuous
sequence of xdotool commands is what is preventing it to be really smooth.

I didn't try disabling gsdwacom, both because I'd like to reach a
system-compliant solution, and because xsetwacom parameters don't
survive hotplugging unless you dabble with xinit scripts which I would
gladly stay away from.  ;)

My course of action will be asking for a new feature in gsdwacom,
supporting it with your explanation and pointing that the natural
function of touchstrips is scrolling, both in general and while using
graphics programs.

Thanks again and keep up the good work!

Alessandro Prunai
Italy

> Alessandro,
>
> Sorry for the delay in replying. Unfortunately, setting up the strips to
> scroll in GNOME/Unity/Cinnamon is non-trivial. Scrolling isn't an action
> you can choose, and the "gnome-settings-daemon" process (which is
> responsible for carrying out all the settings set through the control
> panel) inserts itself as a middleman between the X server and
> applications which effectively prevents xsetwacom from working as
> expected (see the technical details below if you're interested in what's
> going on under the hood).
>
> I can think of two ways to get scrolling to work. The first would be to
> use a combination of two tools: "xbindkeys"[1] and "xdotool"[2]. The
> former can be configured to run commands in response to keyboard
> shortcuts, and the latter can simulate mouse clicks (including
> scrolling) when run. To do this, you would want to configure the strips
> to send a unique keyboard shortcuts in the control panel, and then set
> up xindkeys to run xdotool in response to the shortcuts. It is a very
> roundabout process, but should work.
>
> Alternately, you can disable the "gsdwacom" plugin of
> gnome-settings-daemon so that it no longer acts as a middleman. This
> will allow xsetwacom to work normally and is much more straightforward,
> but causes the control panel settings to have no effect on the tablet.
> To do this, run:
>
> $ gsettings set org.gnome.settings-daemon.plugins.gsdwacom active false
>
>
> [1]:http://www.nongnu.org/xbindkeys/xbindkeys.html
> [2]:http://www.semicomplete.com/projects/xdotool
>
>
> ## GEEKY TECHNICAL DETAILS:
>
> For gnome-settings-daemon (which is used by GNOME, Unity, Cinnamon, etc.
> as the business end of the control panel) to do its magic, it "grabs"
> all events from the tablet before any other application can see them and
> then either performs some internal action (e.g. popping up the help
> screen) or injects a replacement event into X (e.g. a keypress) for
> other applications to see.
>
> To determine the correct action to perform, gnome-settings-daemon
> translates the mouse button number that it receives from X into an
> associated "physical" button number. This is necessary because our
> driver skips mouse buttons 4-7 to prevent the ExpressKeys from sending
> scroll and navigation events by default.
>
> The weirdness in this case lies in their translation function.
> Specifically, it does not ignore mouse buttons 4-7, and so ends up
> claiming that they are associated with the 4th, 1st, 2nd, and 3rd
> ExpressKey. If you use xsetwacom to have our driver send scroll events
> (from the strips, rings, or even ExpressKeys) then gnome-settings-daemon
> ends up believing that you're pressing one of those ExpressKeys and acts
> accordingly.
>
> Ideally, gnome-settings-daemon would either ignore those four mouse
> buttons or inject replacement mouse events so that scrolling and
> navigation worked properly. Even more ideally, it would map the strips
> and rings to scroll (or allow you to set them to scroll in the control
> panel) so that you never have to touch xsetwacom in the first place ;)
>
> Jason
> ---
> Now instead of four in the eights place /
> you’ve got three, ‘Cause you added one /
> (That is to say, eight) to the two, /
> But you can’t take seven from three, /
> So you look at the sixty-fours....
 
 
 --
 ZE-Light e ZE-Pro: servizi zimbra per caselle con dominio email.it, per tutti i dettagli
Clicca qui http://posta.email.it/caselle-di-posta-z-email-it/?utm_campaign=email_Zimbra_102014=main_footer/f
 
 Sponsor:
 Soluzioni di email hosting per tutte le esigenze: dalle caselle gratuite a quelle professionali su piattaforma Zimbra, da quelle su proprio dominio a quelle certificate PEC. Confronta le soluzioni
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=13326&d=14-11

------------------------------------------------------------------------------
_______________________________________________
Linuxwacom-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/linuxwacom-discuss
Loading...