On 22/11/10 19:18 , Jason alavaliant wrote:
>
>
> On Mon, Nov 22, 2010 at 6:55 PM, Peter Hutterer
> <[email protected] <mailto:[email protected]>> wrote:
>
>     On Mon, Nov 22, 2010 at 06:26:50PM +1300, Jason alavaliant wrote:
>      > On Thu, Nov 18, 2010 at 5:13 PM, Peter Hutterer
>     <[email protected] <mailto:[email protected]>>wrote:
>      >
>      > > On Thu, Nov 18, 2010 at 04:55:18PM +1300, Jason alavaliant wrote:
>      > > > On Wed, Oct 13, 2010 at 12:51 PM, Peter Hutterer
>      > > > <[email protected]
>     <mailto:[email protected]>>wrote:
>      > > >
>      > > > > On Tue, Oct 12, 2010 at 09:55:32PM +1300, Jason alavaliant
>     wrote:
>      > > > > > On Tue, Oct 5, 2010 at 1:44 PM, Peter Hutterer <
>      > > [email protected] <mailto:[email protected]>
>      > > > > >wrote:
>      > > > > [...]
>      > > > > > >
>      > > > > > > Haven't checked out the code because right now I'm at
>     an airport
>      > > and
>      > > > > I'm
>      > > > > > > not
>      > > > > > > even sure when I can send this email.
>      > > > > > >
>      > > > > > > Please don't use xsetwacom. We have properties, they
>     are the
>      > > driver's
>      > > > > > > official API. xsetwacom makes no guarantee for
>     consistency or
>      > > backwards
>      > > > > > > compatibility on its commandline interface. It's
>     intended for
>      > > testing
>      > > > > of
>      > > > > > > settings at runtime, but not as a base layer for any
>     other client.
>      > > > > > >
>      > > > > >
>      > > > > >
>      > > > > > I was wondering if that was the direction I should be
>     going in.   The
>      > > > > main
>      > > > > > reason I'm using xsetwacom currently is that wacom-config
>     -v1 was
>      > > > > originally
>      > > > > > written as a wacomcpl compatible tool that let you change
>     settings
>      > > from
>      > > > > > either tool (and there was no way to set things besides
>     xsetwacom at
>      > > the
>      > > > > > time).       Is there any guide that covers all the
>     properties for
>      > > the
>      > > > > wacom
>      > > > > > driver?    I think I can reverse engineer what most
>     settings are via
>      > > > > > xsetwacom commands and watching how the properties change
>     but things
>      > > like
>      > > > > > 'Wacom Display Options (263):    -1, 0, 0'   would be a
>     lot faster to
>      > > > > > understand with some notes.  (I think the middle value is
>     twinview
>      > > based
>      > > > > on
>      > > > > > seeing it change when setting twinview via xsetwacom but
>     I've got no
>      > > idea
>      > > > > > what the other two are.)
>      > > > >
>      > > > > All the properties are documented in the wacom-properties.h
>     file but
>      > > not
>      > > > > overly expressive. I haven't added the man pages yet
>     because some of
>      > > the
>      > > > > properties are still in flux (e.g. the removal of TwinView
>     related
>      > > ones).
>      > > > > so
>      > > > > once wacom 1.0 comes out, the list of properties may not
>     necessarily be
>      > > the
>      > > > > same.
>      > > > >
>      > > > > Cheers,
>      > > > >   Peter
>      > > > >
>      > > >
>      > > >
>      > > > I've been making good progress working with xinput properties
>     and have
>      > > got
>      > > > code that uses the Coordinate Transformation Matrix  working well
>      > >  (atleast
>      > > > now I've backported the patch that added that property to the
>     kubuntu
>      > > 10.04
>      > > > xserver so my computers support it),   I've been preparing to
>     change over
>      > > > all my other functions to use properties as well but there is
>     one point I
>      > > > can't work out.    What format/encoding are the values for
>     the 'Wacom
>      > > Button
>      > > > action X' properties stored as?
>      > > >
>      > > > (i.e.  xsetwacom set 'Wacom Intuos3 6x8 pad' Button1 "key l"
>         is stored
>      > > as
>      > > > the property "Wacom button action 1 (482):    1114158, 65582"
>         I can
>      > > > easily enough set the Wacom button action 1 property on the
>     device but I
>      > > > can't workout how to tell what numbers to use,   65582 isn't
>     as far as I
>      > > can
>      > > > tell an X keycode, ascii, unicode or any other encoding
>     scheme I can
>      > > think
>      > > > of.   (and extensive reading of the source code hasn't
>     enlightened me)
>      > > )
>      > >
>      > > have a look at Xwacom.h.
>      > > "key l" is stored as 2-value property
>      > >    AC_KEY | AC_KEYBTNPRESS | <keycode>
>      > >    AC_KEY | <keycode>
>      > >
>      > >
>      >
>      >
>      > thanks,  that got me to the point where I can successfully
>     generate the
>      > needed codes for any key for a 'Wacom button action'.  (at least
>     I'm pretty
>      > sure they are right since if I pick a key do the calculations and
>     then
>      > compare to what an xsetwacom command does the numbers match.)
>      >
>      > However I'm rather confused since no matter how I alter the
>     properties (and
>      > they are updating I can see the changes with xinput list-props)
>     the actual
>      > action the button is set to doesn't seem to change.    (infact
>     even deleting
>      > the property seems to have no effect,  the button continues on
>     being mapped
>      > to the last thing it was mapped to with xsetwacom)
>      >
>      > Can you give me a sample set of commands that would use the
>     properties to
>      > set say pad button1 to 'key c' that work on your machine ?   Or
>     is updating
>      > the button mappings via properties just rather broken currently
>     like I
>      > suspect?     (and speaking of broken,  the command "xinput
>     delete-prop
>      > 'Wacom Intuos3 6x8 pad' 'Wacom button action 1'" followed by
>     "xsetwacom set
>      > 'Wacom Intuos3 6x8 pad' Button1 'key c'"  equal instant xserver
>     segfault in
>      > my testing.  Possibly the error  handling there in the driver
>     should be a
>      > little more robust so silly commands can't kill the xserver so
>     easy :) )
>
>     yeah, that sounds like a bug :)
>     likely triggered by me testing with xsetwacom which leaves most
>     properties
>     in-place but not this combination of xinput + xsetwacom.
>
>     other than that, the command
>
>         xsetwacom set <device name> Button1 "key c"
>
>     should set the properties, correctly. at least it did when I
>     implemented it.
>
>
> Sorry should have been clearer - xsetwacom commands work fine.  What I'm
> trying to do and not having much luck with is follow your earlier advise
> to use the properties directly rather than xsetwacom.   If I use xinput
> to adjust the button mapping properties directly it appears to have no
> effect.   So the example I'm looking for is mapping a key to a button
> using xinput to adjust the properties.

have a look at this, I think your problem may be the same issue
http://linuxwacom.git.sourceforge.net/git/gitweb.cgi?p=linuxwacom/xf86-input-wacom;a=commit;h=ba77b532e6c2a0b7b05ab129009c1f614b089c37

in short, when you update the button action, also re-write the button 
mapping property to force the driver to reload the data. just a simple 
XGetDataProperty() followed by XChangeDeviceProperty() with the same 
data should do.

Cheers,
   Peter


>

>     Can I assume you're running the latest git version?
>
>
> Git from a few weeks back at this point.
>
> Thanks
> -J
>


------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
Linuxwacom-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Reply via email to