Can't configure stylus buttons

[Marcelo Magno T. Sales]

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.duncan at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde/attachments/20160520/d9975c18/attachment.htm>
-------------- next part --------------
___________________________________________________
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.