On Mon, Nov 22, 2010 at 6:55 PM, Peter Hutterer <[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]>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]>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]
> > > > > >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.



> 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