Ebuild to introduce USB TabletPC for linuxwacom Reproducible: Always Expected Results: Provide kernel and X11 support for USB Wacom tabletPC like HP Pavilion tx2000z series Ebuild needs some more work before inclusion: 1. Check if kernel has enabled wacom module, if so - do not build 2. Add udev rules: kernel driver creates 2 event devices, one for stylus related events, the other for finger touch - unfortunately they are random... Unfortunately product & vendor ID may be (but in some devices, like Asus are not) identical, have to find a way to to distinguish them for easy xorg.conf config
Created attachment 154087 [details] Ebuild for development linuxwacom driver
Created attachment 154091 [details, diff] Wacom module patch for linuxwacom by Andrew Zappacky
This ebuild does work (for me) on amd64 gentoo, HP Pavilion tx2010eo, yet there is a problem with event devices. They tend to change (in most cases for touch is event7, stylus event8, but they take random - following values between 5 and 10). I have no idea for udev rules to make symlinks line /dev/input/wacom-tpc-finger and wacom-tpc, or at least wacom-tpc0 and wacom-tpc1 (since in terms of xorg.conf they ar identical to configure. In my case both are 056a:0093 - but 2 event devices are created. (I read on google, that some devices there are 2 product id-s, always 0093 + sometimes 0090 or 0094)
Also, I can confirm it working on x86 gentoo (same tabletPC).
Created attachment 154113 [details] Rules to create /dev/input/wacom0 and wacom1 - Debian based
Created attachment 154119 [details] New name - since ebuild already does support it
Created attachment 154121 [details] Working xorg.conf - used with this ebuild
Created attachment 154123 [details] Works also with the latest stable linuxwacom-0.8.0-3
Hi again, Well I talked to Ping (linuxwacom) and Ron (60-wacom.rules). The patch is working in most cases, but uses some hard coded values that should be replaced with querying device - to make it more user-configuration-proof. This (changed) e-build (in my opinion) if as a temporary workaround ever makes it into portage tree - should be hard masked since the experimental patch - even though running stable - will be added upstream (stable linuxwacom and kernel) as soon as it is user-proof - at the moment it is not.
