Can't configure stylus buttons

[Duncan]

Marcelo Magno T. Sales posted on Mon, 16 May 2016 17:22:17 -0300 as
excerpted:

> I'm running Kubuntu 14.04 (KDE backports PPA enabled) and KDE 4.14.13 on
> two computers, a desktop and a notebook.
> 
> When I connect a wacom Intuos Pro tablet to the desktop, I can't
> configure the stylus buttons. They both always perform left-clicks, no
> matter what function I assign to them using the Input Devices applet in
> System Settings. Everything else works fine, including pressure
> sensitivity and express buttons setup. If I stop the wacom tablet
> daemon, I can use the tablet as if it was a mouse and the stylus buttons
> act as middle-click and right-click, but then I lose pressure
> sensitivity and express buttons customization, among other things.
> 
> However, when I plug the same tablet to the notebook, everything works
> fine, including the stylus buttons. I can't find a difference in
> software versions or configurations between the desktop and the
> notebook.
> 
> Any idea on what is going on here, or on how to debug this?


The way I go about finding the problem in similar cases here may be 
somewhat laborious, but it does tend to work.  It's a process called 
bisection, and has been popularized of late by the git bisect command, 
which semi-automates the same process to help developers and advanced 
users willing to build their own copies of the software from git sources 
track down bugs to an individual commit when you know an earlier version 
worked and a new version doesn't, and want to find precisely which commit 
between the two triggered the problem.

In the context of your posted problem, what you do first on the non-
working machine is configure a new user, and see if the problem appears 
for a new user, without any customized user config at all.

Alternatively, while logged in as a different user or as root, move your 
normal user's home dir elsewhere for backup, and recreate it, empty.

Assuming the problem is gone with a new user or empty home dir, you know 
the problem must be in the configuration stored in some file in the home 
dir.  The question is then to figure out which one.  That's where the 
bisect process starts.

Taking into account dotfiles and dirs (those starting with a dot, like 
~/.config/ and ~/.bashrc, normally not displayed in file managers and the 
like, but likely where the config file of interest is, since most config 
files are in fact either dotfiles themselves or located in dotdirs), move 
half of your user's directories and files elsewhere, leaving the other 
half.  

Now login as that user and see if the problem persists.  If it does, the 
problem must be in the half that's there.  If it doesn't, it must be in 
the half you moved.

Now use the same method to recursively split the bad half in half again 
and again, testing at each split, until you find the bad directory, and 
eventually the bad file within the directory.  Of course as the bad half 
gets smaller and after you've eliminated any personal files you need to 
keep and it's only config files left, at some point you may decide you've 
done enough testing and can simply redo whatever customized config you'd 
lose by deleting the remaining files.  Or you can continue on until you 
have a specific file.

When you have the bad file its name will give you a clue as to where the 
problem is at the application level at least, and assuming it's a text 
file, you can open it and see how big it is.  If it's only a few lines 
the problem may be obvious at that point.  If it's large, you can either 
continue with the bisect using a text editor now instead of a file 
manager or mv commands, or decide you can lose and redo whatever config 
it contained, and simply delete the file.


Of course if the new-user or empty home dir test still reproduces the 
problem, then you know it's a difference in either what's actually 
installed on the system, or in the system configs themselves.  That's 
useful information as well, altho you can't really use bisect to solve 
the problem then, since critical system functionality is involved.  But 
at that point, since you know it's a system level issue, you can post to 
your distro's lists or forums with the information you know upto that 
point, including the fact that it can't be in your user config as you 
tried an empty config and the problem was still there, which will give 
people a head start on helping you solve the problem from there.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.