Hi Borden, On Sat, Oct 29, 2016 at 01:45:54AM -0400, Borden Rhodes wrote: > It's perfectly fair to assume that my Bluetooth mouse + Wacom tablet > has created a corner case creating the sorts of lock-ups I describe. > Whilst I agree that the developers should improve the software as a > whole instead of chase one-off corner cases, the software neither > crashes loudly nor even whispers to ~/.xsession-errors that this, what > I hope you'll agree is, undesirable behaviour occurred and the > component that broke. Can this silence alone be considered a problem > with the software that is worth addressing?
Well, you reported it against an unstable snapshot from 2013, that never even made it into a release - and a lot of things have changed in a lot of places since then - so the first useful thing to do would be to see if the problem does still exist in what's currently in unstable in preparation for the next release. That nothing was reported to the logs you looked in, could well mean that the problem isn't where you think. Hardware 'lock ups' are often more likely to be in the kernel than anywhere else - and even if it was some race, a deadlock doesn't usually report "hey I'm deadlocked", because if it could, it wouldn't deadlock :) If you can still reproduce it on current unstable, then really the best place to take it would be to the upstream wacom list - since there's a much better chance of there being people there who do have this hardware (or access to it), who can help you dig into it further. If that does result in a patch getting pushed for it there, then you could bring a report of that back here (to either me or the kernel team depending on where it is), to see if we can still get it in for the next stable release. Cheers, Ron > On 28 October 2016 at 04:21, Debian Bug Tracking System > <ow...@bugs.debian.org> wrote: > > This is an automatic notification regarding your Bug report > > which was filed against the xserver-xorg-input-wacom package: > > > > #741582: wacom: Stylus can lock up left mouse button with no debug trail > > > > It has been closed by Ron <r...@debian.org>. > > > > Their explanation is attached below along with your original report. > > If this explanation is unsatisfactory and you have not received a > > better one in a separate message then please contact Ron <r...@debian.org> > > by > > replying to this email. > > > > > > -- > > 741582: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741582 > > Debian Bug Tracking System > > Contact ow...@bugs.debian.org with problems > > > > > > ---------- Forwarded message ---------- > > From: Ron <r...@debian.org> > > To: 741582-d...@bugs.debian.org > > Cc: > > Date: Fri, 28 Oct 2016 18:39:19 +1030 > > Subject: Stylus can lock up left mouse button with no debug trail > > > > Hi, > > > > I'm going to tentatively close this bug here now, since there's a pretty > > good chance that it falls into the "new device, not yet properly supported" > > category, and so there's a reasonably good chance that things have > > improved on that front since it was reported. > > > > If you've got 'mouse buttons' locking up, that sounds like something > > more fundamental is wrong than just a glitch with the part of it in > > this package. > > > > If you're still seeing this with the kernel and drivers in unstable, > > then more information might be useful - but it's the kind of bug that > > is hard for anyone without the device in question to do much about. > > > > Ron > > > > ---------- Forwarded message ---------- > > From: Borden Rhodes <j...@bordenrhodes.com> > > To: Debian Bug Tracking System <sub...@bugs.debian.org> > > Cc: > > Date: Fri, 14 Mar 2014 01:48:28 -0400 > > Subject: wacom: Stylus can lock up left mouse button with no debug trail > > Package: xserver-xorg-input-wacom > > Version: 0.23.0+20131011-1+b1 > > Severity: important > > File: wacom > > > > Good evening, > > > > I use a Fujitsu Lifebook T4410, which comes with a built-in touchpad and > > Wacom > > touch + stylus screen. In addition, I use a generic bluetooth mouse > > (typically > > in lieu of the touchpad when I'm using it in laptop mode). > > > > The stylus has these features: > > 1) tapping the pointy end normally acts like a normal left mouse button > > click > > (LMB); > > 2) pressing the bottom end of the stylus button and then tapping acts like a > > right mouse button (RMB); > > 3) pressing the top end of the stylus button and then tapping acts like a > > middle mouse button (MMB); and > > 4) the eraser bit at the other end of the stylus appears to act like a left > > mouse button click (Eraser). > > > > I was using the stylus in Xournal when I noticed that the left regular LMB > > was > > no longer working. I was still able to draw in Xournal, but tapping outside > > the > > drawing area had no effect at all. The MMB and RMB continued to work > > normally, > > except that I couldn't activate anything because the LMB wasn't working. > > This > > behaviour affected the whole desktop, which is why I'm not filing a bug with > > Xournal. > > > > The same behaviour extended to the laptop's touchpad and my Bluetooth mouse: > > right clicks, middle clicks and movement continued to work normally, but > > left > > clicks had no response. > > > > Using keyboard commands, I opened a terminal and tailed every log in > > /var/log/, > > including dmesg, syslog, Xorg.0.log, messages, kdm.log, kern.log, debug and > > daemon.log. I also tailed ~/.xsession-errors for good measure. None of these > > logs had any mention whatsoever of the Wacom drivers during the time period > > when the stylus/mouse started acting up. The only message relevant to human > > input devices were dmesg entries announcing that my Bluetooth mouse had > > woken > > up and been assigned correctly. > > > > Accordingly, other than my epic on how my mouse got to this situation, I > > have > > no other debugging information to offer. > > > > I went back into Xournal and mashed the RMB and MMB a couple of times and > > the > > LMB started working again (as did the left mouse button on my Bluetooth > > mouse > > and touchpad). For all intents and purposes, my computer is working normally > > again. > > > > I should add that this is not the first time the LMB has locked up like > > this. > > Sometimes, the LMB will lock in 'pressed' mode, leading to a persistent > > drag- > > and-drop state. However, I wasn't paying close enough attention the times it > > locked up before to give any useful information. I don't know how to > > reproduce > > this problem reliably, but I can assure that it will recur if I keep using > > my > > tablet regularly. > > > > This issue falls into one of two categories: > > 1) The wacom driver doesn't throw useful logging messages when the LMB locks > > up; or > > 2) There is some sort of bug in the Wacom driver which somehow causes LMBs > > from > > any input source to no longer be acknowledged. > > > > I would be grateful for any direction. > > > > > > > > -- System Information: > > Debian Release: jessie/sid > > APT prefers testing > > APT policy: (500, 'testing') > > Architecture: amd64 (x86_64) > > Foreign Architectures: i386 > > > > Kernel: Linux 3.12-1-amd64 (SMP w/2 CPU cores) > > Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) > > Shell: /bin/sh linked to /bin/dash > > > > Versions of packages xserver-xorg-input-wacom depends on: > > ii libc6 2.18-4 > > ii libx11-6 2:1.6.2-1 > > ii libxi6 2:1.7.2-1 > > ii libxinerama1 2:1.1.3-1 > > ii libxrandr2 2:1.4.2-1 > > ii xserver-xorg-core [xorg-input-abi-20] 2:1.15.0-2 > > > > xserver-xorg-input-wacom recommends no packages. > > > > Versions of packages xserver-xorg-input-wacom suggests: > > pn xinput <none> > > > > -- no debconf information > >
