<div dir="ltr">Thank you, I'll try that as soon as I have some spare time and will post the results here later.<div><br></div><div>[]'s</div><div>Marcelo</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-05-19 5:08 GMT-03:00 Duncan <span dir="ltr"><<a href="mailto:1i5t5.duncan@cox.net" target="_blank">1i5t5.duncan@cox.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Marcelo Magno T. Sales posted on Mon, 16 May 2016 17:22:17 -0300 as<br>
excerpted:<br>
<span class=""><br>
> I'm running Kubuntu 14.04 (KDE backports PPA enabled) and KDE 4.14.13 on<br>
> two computers, a desktop and a notebook.<br>
><br>
> When I connect a wacom Intuos Pro tablet to the desktop, I can't<br>
> configure the stylus buttons. They both always perform left-clicks, no<br>
> matter what function I assign to them using the Input Devices applet in<br>
> System Settings. Everything else works fine, including pressure<br>
> sensitivity and express buttons setup. If I stop the wacom tablet<br>
> daemon, I can use the tablet as if it was a mouse and the stylus buttons<br>
> act as middle-click and right-click, but then I lose pressure<br>
> sensitivity and express buttons customization, among other things.<br>
><br>
> However, when I plug the same tablet to the notebook, everything works<br>
> fine, including the stylus buttons. I can't find a difference in<br>
> software versions or configurations between the desktop and the<br>
> notebook.<br>
><br>
> Any idea on what is going on here, or on how to debug this?<br>
<br>
<br>
</span>The way I go about finding the problem in similar cases here may be<br>
somewhat laborious, but it does tend to work.  It's a process called<br>
bisection, and has been popularized of late by the git bisect command,<br>
which semi-automates the same process to help developers and advanced<br>
users willing to build their own copies of the software from git sources<br>
track down bugs to an individual commit when you know an earlier version<br>
worked and a new version doesn't, and want to find precisely which commit<br>
between the two triggered the problem.<br>
<br>
In the context of your posted problem, what you do first on the non-<br>
working machine is configure a new user, and see if the problem appears<br>
for a new user, without any customized user config at all.<br>
<br>
Alternatively, while logged in as a different user or as root, move your<br>
normal user's home dir elsewhere for backup, and recreate it, empty.<br>
<br>
Assuming the problem is gone with a new user or empty home dir, you know<br>
the problem must be in the configuration stored in some file in the home<br>
dir.  The question is then to figure out which one.  That's where the<br>
bisect process starts.<br>
<br>
Taking into account dotfiles and dirs (those starting with a dot, like<br>
~/.config/ and ~/.bashrc, normally not displayed in file managers and the<br>
like, but likely where the config file of interest is, since most config<br>
files are in fact either dotfiles themselves or located in dotdirs), move<br>
half of your user's directories and files elsewhere, leaving the other<br>
half.<br>
<br>
Now login as that user and see if the problem persists.  If it does, the<br>
problem must be in the half that's there.  If it doesn't, it must be in<br>
the half you moved.<br>
<br>
Now use the same method to recursively split the bad half in half again<br>
and again, testing at each split, until you find the bad directory, and<br>
eventually the bad file within the directory.  Of course as the bad half<br>
gets smaller and after you've eliminated any personal files you need to<br>
keep and it's only config files left, at some point you may decide you've<br>
done enough testing and can simply redo whatever customized config you'd<br>
lose by deleting the remaining files.  Or you can continue on until you<br>
have a specific file.<br>
<br>
When you have the bad file its name will give you a clue as to where the<br>
problem is at the application level at least, and assuming it's a text<br>
file, you can open it and see how big it is.  If it's only a few lines<br>
the problem may be obvious at that point.  If it's large, you can either<br>
continue with the bisect using a text editor now instead of a file<br>
manager or mv commands, or decide you can lose and redo whatever config<br>
it contained, and simply delete the file.<br>
<br>
<br>
Of course if the new-user or empty home dir test still reproduces the<br>
problem, then you know it's a difference in either what's actually<br>
installed on the system, or in the system configs themselves.  That's<br>
useful information as well, altho you can't really use bisect to solve<br>
the problem then, since critical system functionality is involved.  But<br>
at that point, since you know it's a system level issue, you can post to<br>
your distro's lists or forums with the information you know upto that<br>
point, including the fact that it can't be in your user config as you<br>
tried an empty config and the problem was still there, which will give<br>
people a head start on helping you solve the problem from there.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Duncan - List replies preferred.   No HTML msgs.<br>
"Every nonfree program has a lord, a master --<br>
and if you use the program, he is your master."  Richard Stallman<br>
<br>
___________________________________________________<br>
This message is from the kde mailing list.<br>
Account management:  <a href="https://mail.kde.org/mailman/listinfo/kde" rel="noreferrer" target="_blank">https://mail.kde.org/mailman/listinfo/kde</a>.<br>
Archives: <a href="http://lists.kde.org/" rel="noreferrer" target="_blank">http://lists.kde.org/</a>.<br>
More info: <a href="http://www.kde.org/faq.html" rel="noreferrer" target="_blank">http://www.kde.org/faq.html</a>.</font></span></blockquote></div><br></div>