Re: [Linuxwacom-discuss] Invert the scroll direction of a touch device?

[Alexander Maret-H. <al...@ma...>]

Am Mittwoch, 13. März 2013, 13:30:08 schrieb Peter Hutterer:
> On Tue, Mar 12, 2013 at 07:41:38PM -0700, Jason Gerecke wrote:
> > On Tue, Mar 12, 2013 at 6:02 PM, Peter Hutterer <peter.hutterer@who-
t.net>wrote:
> > > On Tue, Mar 12, 2013 at 12:39:44PM +0100, Alexander Maret-Huskinson 
wrote:
> > > > Am Dienstag, 12. März 2013, 14:32:30 schrieb Peter Hutterer:
> > > > > On Mon, Mar 11, 2013 at 09:32:27AM -0700, Jason Gerecke wrote:
> > > > > > On Sat, Mar 9, 2013 at 6:31 AM, Alexander Maret-Huskinson
> > > > 
> > > > <al...@ma...>wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > I'm one of the developers of the KDE wacom KCM. We are currently
> > > 
> > > in the
> > > 
> > > > > > > process of preparing a new release and are fixing/removing all
> > > 
> > > features
> > > 
> > > > > > > which
> > > > > > > do no longer work.
> > > > > > > 
> > > > > > > With previous versions of xsetwacom it was possible to invert
> > > > > > > the
> > > 
> > > scroll
> > > 
> > > > > > > direction of a touch device by swapping the button numbers,
> > > > > > > e.g.:
> > > > > > > 
> > > > > > > xsetwacom --set $TOUCH_DEV button 4 5
> > > > > > > xsetwacom --set $TOUCH_DEV button 5 4
> > > > > > > 
> > > > > > > This however has not been working for quite some time now and
> > > > > > > I'm
> > > > > > > wondering if
> > > > > > > this is a feature or a bug? Is there currently any way to invert
> > > 
> > > the
> > > 
> > > > > > > scroll
> > > > > > > direction of a touch device or has this feature been removed
> > > 
> > > completely
> > > 
> > > > > > > from
> > > > > > > xsetwacom?
> > > > > > > 
> > > > > > > Greetings,
> > > > > > > Alex
> > > > > > 
> > > > > > Using the button assignment to change the scroll direction was
> > > > > > never
> > > > > > intended, but worked for a quite some time as a consequence of our
> > > > > > implementation. At the moment I'm not aware of any way to swap the
> > > 
> > > scroll
> > > 
> > > > > > direction, and I'm not sure if we want to add one in given that
> > > > > > our
> > > > > > eventual goal is to have gestures handled entirely out-of-driver
> > > 
> > > (via e.g.
> > > 
> > > > > > apps like Touchegg or framework integration like GTK).
> > > > > 
> > > > > you could take a negative scroll distance as a signal to invert
> > > 
> > > scrolling
> > > 
> > > > > (that's what we do in the synaptics driver).
> > > > > 
> > > > > having said that, the button 4/5 swap should still work since wacom
> > > 
> > > doesn't
> > > 
> > > > > use smooth scrolling. what does xev say?
> > > > > 
> > > > > Cheers,
> > > > > 
> > > > >    Peter
> > > > 
> > > > The negative scroll distance is a very nice idea. Currently scrolling
> > > 
> > > gets
> > > 
> > > > disabled if you set a negative scroll distance.
> > > > 
> > > > The button 4/5 swap does not work because xsetwacom does not allow you
> > > 
> > > to set
> > > 
> > > > it. If you try to swap the buttons you get an error message:
> > > > "Unsupported
> > > > offset into 'Wacom Button Actions' property.". Maybe we could map it
> > > > with
> > > > "xinput set-button-map" as scrolling seems to send normal button 4/5
> > > 
> > > events
> > > 
> > > > according to xev:
> > > > 
> > > > ------------
> > > > ButtonPress event, serial 35, synthetic NO, window 0x6200001,
> > > > 
> > > >     root 0x290, subw 0x6200002, time 1566013, (39,35),
> > > >     root:(2830,555),
> > > >     state 0x0, button 4, same_screen YES
> > > > 
> > > > ButtonRelease event, serial 35, synthetic NO, window 0x6200001,
> > > > 
> > > >     root 0x290, subw 0x6200002, time 1566013, (39,35),
> > > >     root:(2830,555),
> > > >     state 0x800, button 4, same_screen YES
> > > > 
> > > > ButtonPress event, serial 35, synthetic NO, window 0x6200001,
> > > > 
> > > >     root 0x290, subw 0x6200002, time 1567491, (39,35),
> > > >     root:(2830,555),
> > > >     state 0x0, button 5, same_screen YES
> > > > 
> > > > ButtonRelease event, serial 35, synthetic NO, window 0x6200001,
> > > > 
> > > >     root 0x290, subw 0x6200002, time 1567491, (39,35),
> > > >     root:(2830,555),
> > > >     state 0x1000, button 5, same_screen YES
> > > > 
> > > > -----------
> > > 
> > > button mapping is handled in the server, so a xinput set-button-map
> > > should
> > > just work here.
> > > 
> > > xsetwacom changes physical button mappings, not the logical ones*. thus
> > > button 4 would refer to physical button 4, which you likely don't have
> > > on
> > > the touch device. xinput changes logical buttons, and buttons 4-7 are
> > > reserved for scrolling. so physical button 4 is actually logical button
> > > 8..
> > > 
> > > Cheers,
> > > 
> > >    Peter
> > > 
> > > * Jason, correct me if that has changed recently, you re-did a lot of
> > > that
> > > code
> > 
> > xsetwacom actually still uses the logical button number for its interface,
> > but the driver itself (and the xinput properties) are indexed by the
> > physical button number. Trying to set a logical button that doesn't have a
> > physical button backing it gives the "Unsupported offset" error.
> > 
> > Your solution of xinput set-button-map works for me over here. I had tried
> > xmodmap earlier thinking it would change the server mapping, but either it
> > didn't work or I screwed up the command...
> 
> xmodmap -e "pointer = 1 2 3 5 4"
> 
> should still work (it does here)
> 
> oh, and I should probably link to this post here for anyone who needs more
> detail on button mapping.
> http://who-t.blogspot.com.au/2009/06/button-mapping-in-x.html
> 
> Cheers,
>    Peter

At least for our KCM, xmodmap can not be used because afaik it changes the 
mapping of the core pointer which is not what the user wants.

But we will have a look at XSetDeviceButtonMapping(3) which is what the xinput 
tool uses to set the button map for a specific device.

Thanks for your support.

Regards,
Alex