On Wed, Nov 2, 2011 at 9:42 AM, Cedric Sodhi <[email protected]> wrote: > On Wed, Nov 02, 2011 at 08:59:55AM -0500, Chris Bagwell wrote: >> xsetwacom's TabletPCButton == xinput's "Wacom Hover Click". > > Well, I did try TabletPCButton before, and it did not work. After trying > it again, it seems like the value > > xsetwacom --set 13 TabletPCButton on > > wont stick. A subsequent xsetwacom --get 13 all still reports the > setting to be off (and off->on doesn't work either). Apparently, only > xinput cli is able to affect that settings.
There is a bugfix in git that mentions something like the --get value displayed is the inverse of the value --set. Also, I just now notice that TabletPCButton is inversed meaning of the Hover one. Does it seem to align with those two pieces of info? Depending on how old your xf86-input-wacom is, there may be additional bugs in that option. > > Thanks for clarifying that the two options actually refer to the same > property. > > As for the manpage, I think synaptics (as other drivers) do only tell > about the mapping "xinput property->xorg.conf entry", since with them > there are no such sort of "inconsistencies" as with the wacom, which > offers a dedicated tool to superseede xinput (there still is synclient, > but it doesn't specify such a mapping either). I believe we need the same thing for the same reasons as synaptics. When it says: Option "TabletPCButton" "on|off", that is the xorg.conf entry. Need something to tell xinput property value. BTW: xsetwacom is not mean to supersede xinput in this case. Its meant to compliment it. There is some backstory in the archive in last month if your interested (search for xsetwacom in title). > > Isn't it possible to simply offer *absolutely no* properties through > xinput cli (except the few generic ones) and have it all through > xsetwacom (not until xsetwacom can properly set TabletPCButton, of > course :p) - that would perhaps be more consistent and clear. The opposite could certainly be true but not what you suggest. I believe "properties" were created so that drivers could stop implement per driver programs to set per driver internal variables and move to a generic approach were you can query supported properties and set them generically; either using X provided functions or the xinput command which is just a wrapper for those generic functions. That is a feature that won't be going away. But 2 ways to do same thing is confusing to me as well. So I lean towards removing logic from xsetwacom where it overlaps. But then see the back story in archive for more opinions. Chris > > Not that it would be a big problem, whatsoever (apart from that > xsetwacom can't affect that settings, which probabaly is a bug, but I'll > verify it with current GIT before calling it such) > > Thanks. > > >> >> Agree it would be nice to include a xsetwacom to X properties >> conversion table in man pages; similar to how "man synaptics" does it. >> >> Patches welcome (since this is on the developers list)! >> >> Chris >> >> On Wed, Nov 2, 2011 at 8:50 AM, Cedric Sodhi <[email protected]> wrote: >> > Well, this is interesting. I found the solution which is rather easy, >> > yet not all that obvious to find. >> > >> > Apparently xinput (cli tool) offers a setting "Wacom Hover Click" which >> > turns the side button on. >> > >> > Of course that yields the question why that setting is not covered by >> > xsetwacom. Is it that some settings can only be set by xinput cli and >> > others only by xsetwacon cli? Sounds a little strange to me - I would >> > rather expect all settings to be handled by xsetwacom (I would even >> > prefer if all settings were handled by xinput). >> > >> > On Wed, Nov 02, 2011 at 11:52:59AM +0100, Cedric Sodhi wrote: >> >> Hello, the device is a 056a:0090 n USB. I'm 99.99% certain that the >> >> button on the side of my stylus used to work, but it no longer does. GPM >> >> and the event interface still respond to the button (GPM pastes, when I >> >> press it, which means it is reported as the right button), but there is >> >> no response to it in X. I use 0.11.1 - I'm just puzzled because it used >> >> to work (afaicr - I haven't been using that pc for long). >> >> >> >> I don't think I've updated xf86-input-wacom since it used to work. I'm >> >> actually positive I did not. >> >> >> >> Any idea how to find out what's wrong? xsetwacom --get ... all returns >> >> >> >> Button requires exactly 1 values >> >> >> >> Which I think refers to the click with the pen, not the button. >> >> >> >> Thanks for your help, >> >> Cedric >> >> >> >> ------------------------------------------------------------------------------ >> >> RSA® Conference 2012 >> >> Save $700 by Nov 18 >> >> Register now! >> >> http://p.sf.net/sfu/rsa-sfdev2dev1 >> >> _______________________________________________ >> >> Linuxwacom-devel mailing list >> >> [email protected] >> >> https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel >> > >> > ------------------------------------------------------------------------------ >> > RSA® Conference 2012 >> > Save $700 by Nov 18 >> > Register now! >> > http://p.sf.net/sfu/rsa-sfdev2dev1 >> > _______________________________________________ >> > Linuxwacom-devel mailing list >> > [email protected] >> > https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel >> > > ------------------------------------------------------------------------------ RSA® Conference 2012 Save $700 by Nov 18 Register now! http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ Linuxwacom-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
