Thank you, I'll try that as soon as I have some spare time and will post the results here later.
[]'s Marcelo 2016-05-19 5:08 GMT-03:00 Duncan <1i5t5.dun...@cox.net>: > 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.
___________________________________________________ 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.