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.
