On Wed, Dec 16, 2009 at 09:33:23PM +0100, Oldrich Jedlicka wrote:
> > just verifying: your commandline argument was
> > xsetwacom --set "Device Name" "Button1" "key shift"
> >
> > if so, the patches on my devel branch should fix this issue
> > http://cgit.freedesktop.org/~whot/xf86-input-wacom/log/?h=devel
> >
> > it'd be great if you could give this a test.
> 
> Works perfectly. Thanks :-) I'm using it as "key shift", or "key control" and 
> the like.

excellent, thank you for testing. I'll merge and push those patches.

> > > > > I have also difficulties double-clicking Button 3, because it
> > > > > freezes any mouse/tablet clicks (no buttons react) until some key is
> > > > > pressed.
> > > >
> > > > just double-clicking the physical button or assigning doubleclick to
> > > > it?
> > >
> > > Just double-click (Button 3) without any assigned functonality - just a
> > > pure button. I've tried it with tracing enabled, but I didn't see any
> > > difference from single click, only no mouse clicks accepted afterwards
> > > (also from normal mouse) - until the keyboard's key is pressed.
> > >
> > > I wanted to have a look at it during weekend, but I didn't have any free
> > > time for that...
> >
> > I can't reproduce this here, doubleclicks go through normally, without any
> > issues. Not sure what happens there.
> 
> I will check this, maybe it has something to do with the fact that clicking 
> the button sometimes moves the cursor to 0,0 (the pen lays down next to the 
> tablet all the time).

it could be. depending on a desktop environment, a click + move may be
interpreted as a drag event. This usually causes a grab to activate which
then prevents events to get through to other applications. with jumps like
this, the application issuing the drag may get confused and thus not release
the grab properly until you hit a key.

the best way to test this is to do the following:
$> sudo init 3  # switches to runlevel 3, disabling gdm and X.*
$> mv $HOME/.xinitrc $HOME/xinitrc_backup
$> echo "xterm" > $HOME/.xinitrc
$> xinit -- 

now X starts just with an xterm and will quit once you exit the xterm. run
xev try to reproduce the issue. does xev see events?

a simple "sudo init 5" gets you back to runlevel 5 with X running.

Cheers,
  Peter

* this works on Fedora, IIRC debian has different usages for runlevels so
you may need a different command there.

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Linuxwacom-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Reply via email to