Thanks M42.
Well this is pretty ridiculous. What's happened with rotation is that CW has become CCW and vice versa. So if you change your rotation script appropriately everything is fine!!! If you don't then when you rotate right or left the cursor moves 180 degrees inverted to your stylus.
I don't think this was happening with rec's script and .fdi file. I think the cursor would move at a right angle to the stylus motion. Which is what you would expect with xsetwacom commands not having any effect. But at this point I can't swear to it. I think this happened after I removed rec's script. But as to why it happened I don't yet know.
So I've learned rec's script actually takes you pretty far in Intrepid. You almost get things working. The important part is that with a custom .fdi and the script you can get stylus and touch, which is what was intended for Intrepid all along.
Interesting quote from Matthew Garrett's blog 3-6-09:
http://www.advogato.org/person/mjg59...html?start=198 Apparently the problem was known at least a month before we encountered it. I think this is the same person who maintains the HP-WMI module. Which lookes like it might control the swivel hinge and two lower bezel buttons. But it turns out he has a TX2500. So...After a bit of back and forth with Peter, we came up with a straightforward way of dealing with the fact that the Wacom driver needs a logical input device per input type[1], but the X server only generates an input device per hal device. The simplest solution turned out to be a hal callout that generates additional hal devices on demand, which also means we can add information to the fdi files to only add the appropriate device types. Ought to land in rawhide in the near future, at which point tablets should be basically working out of the box. Except that xsetwacom gets device name -> type mapping by attempting to parse xorg.conf. Pass the suicide.
Adv Reply
Bookmarks