linuxwacom project just released the beta 0.7.5-2 of linuxwacom drivers
attached you find a preliminary ebuild. the main difference is in the patch, as sources structure has changed
tests are welcome
Created attachment 96937 [details]
Created attachment 96938 [details, diff]
Created attachment 97078 [details]
Not working here, same behaviour of 7.4 : all seems good but
evtest /dev/input/eventx shows there's nothing coming from the tablet.
I have tested it and is working on older systems, also I have wacom as module
and evdev,ehci,ohci,hid as builtin.... am I missing something or I should not
compile wacom module from the kernel?
I've not tested all the combination but on my 2.6.16 kernel, I've enabled wacom as a module in the kernel, then I've emerge linuxwacom, then I've took the archive of linuxwacom, compiled it on my own and overwritten the file wacom.ko. finally rebooted
I don't know another way to make it work
Created attachment 97803 [details]
hackish ebuil with wacom flag to build module
worked like a charm! I created an hackish ebuild to use with 2.6.18 kernel
while waiting for a proper ebuild (one using versionator and linux-mod
eclasses). Tested only on x86 + gentoo-sources-2.6.18 , use at your risk.
I confirm! thx!
Created attachment 98041 [details]
That one was too hackish to substitute your previous ebuild, this one
at least uses linux-mod to get kernel version and check if wacom was
compiled as module. This should be much better.
Created attachment 98606 [details]
Updated for the new beta release
Care! I added _p4 release that seems to install the correct files,
however my tablet (volito 1 ) ceased working with that release and kernel
2.6.18.... I rollbacked to _p3 release.
Created attachment 99920 [details]
ebuild for latest STABLE release of linuxwacom driver
upstream finally made it xorg7.1 compatible. the patch is no more needed.
the ebuild is ok apart some "dodoc" warnings at the end
*** Bug 151802 has been marked as a duplicate of this bug. ***
Created attachment 100992 [details]
I've got a Volito 2, linux 2.6.18-gentoo and X.org 7.1.
linuxwacom-0.7.4_p3 and vanilla kernel module: doesn't work
linuxwacom-0.7.4_p3 and kernel module from the linuxwacom package: works
linuxwacom-0.7.6_p2 and vanilla kernel module: doesn't work
linuxwacom-0.7.6_p2 and kernel module from the linuxwacom package using USE=wacom: works like a charm :-]
So yeah, leaving the kernel module support to the version that will go in portage is quite critical.
afaik, enabling wacom module support (and therefor compiling the bundled module, even if not properly working) is mandatory as linuxwacom, during compile, checks if you have enabled that. if not, even you have asked it to, it will not compile its own module
sad, but true (afaik)
Just a note.... it seems to have issue if you emerge with wacom flag
while you're still using the old release of the kernel (while the newer is
already compiled and installed). So I would suggest you all to reboot
before recompiling linuxwacom (I got some strange issue, not doin so).
_p3 is out. just rename the ebuild file
(In reply to comment #15)
> afaik, enabling wacom module support (and therefor compiling the bundled
> module, even if not properly working) is mandatory as linuxwacom, during
> compile, checks if you have enabled that. if not, even you have asked it to, it
> will not compile its own module
> sad, but true (afaik)
At least with 0.7.6_p3, the external module gets built just fine if you don't enable the kernel's, so if the check was necessary before, it doesn't seem to be anymore.
_p4 is out. just rename the ebuild file
*** Bug 158154 has been marked as a duplicate of this bug. ***
I have a volito 2 wacom tablet, I write to let you know that with the stable version 0.7.4_p3 it wasn't working, while with the 0.7.6_p2 it works properly using the wacom useflag to override the wacom module.
Noticing several version since there has been an updated Gentoo ebuild. Wow! How about pushing a new ebuild into portage?
Also, are there any benefits with using the linuxwacom module over a recent kernel release?
(In reply to comment #22)
> Also, are there any benefits with using the linuxwacom module over a recent
> kernel release?
well... kinda. the linuxwacom module works, the vanilla kernel module doesn't. :P
@Nico: please try p4. I'm using it with a volito2 without problems.
I apologize for the late answer, I was on holidays. What do you mean with try p4? I'm using now the 0.7.6_p2 which is the latest (I suppose) and it works perfectly, if you're asking me to test something, I'll do it, but please be more clear... thanks, Nico
@Nico: sorry, i misread your original post. no need for testing
(In reply to comment #24)
> p4? I'm using now the 0.7.6_p2 which is the latest (I suppose) and it works
The latest is _p4. See comment #19
Upstream released 0.7.7-2
Created attachment 109400 [details]
based on the fedora core rules - creates /dev/input/wacom - this assumes only one tablet, but I don't know of any cases where two are needed.
Created attachment 109401 [details]
adds udev flag for installing 60-wacom.rules
Comment on attachment 100992 [details]
_p4-r1 with udev rules tested and working fine for me
Actually, I've got some udev rules I nicked from Debian Etch which handle multiple tablets, and work a treat with my Graphire 4 -- even on MIPS.
Quick query: What's the status with the X11 driver herd's support of this package? If there's a problem with test hardware, then I'm happy to test on your behalf -- as I use my tablet on a _daily_ basis. :-)
Created attachment 112349 [details]
Aforementioned Udev rules nicked from Debian Etch
The attached udev rules create the following symlinks:
stuartl@wander ~ $ ls -l /dev/input
crw------- 1 root root 13, 64 Mar 7 2007 event0
crw------- 1 root root 13, 65 Mar 7 09:40 event1
crw------- 1 root root 13, 66 Mar 7 09:40 event2
crw------- 1 root root 13, 67 Mar 7 09:40 event3
crw-r--r-- 1 root root 13, 63 Mar 7 2007 mice
crw-r--r-- 1 root root 13, 32 Mar 7 09:40 mouse0
crw-r--r-- 1 root root 13, 33 Mar 7 09:40 mouse1
lrwxrwxrwx 1 root root 6 Mar 7 09:40 tablet-graphire4-4x5 -> event1
lrwxrwxrwx 1 root root 6 Mar 7 09:40 wacom -> event1
I haven't seen this with other Wacom tablets or multiple tablets, but should handle them fine.
linuxwacom-0.7.6_p4-r1.ebuild (USE flags: -udev -usb -wacom) works just fine for me on a HP tc4200 (tablet PC, serial Wacom interface).
stable version 0.7.8 is out.
the attached linuxwacom-0.7.6_p4-r1.ebuild suffices for correctly compile and install it
stable version 0.7.8-1 is out.
see comment #34
Is there any chance to have the latest version in Portage? Or maybe there's an overlay I didn't see already?
ebuild doesn't work with linux-2.6.22, since the wacom module changed name from USB_WACOM to TABLET_USB_WACOM.
The path of the kernel module has changed to
Created attachment 126591 [details]
ebuild for 0.7.8-2 tested on linux 2.6.22
here is an updated ebuild for linuxwacom 0.7.8-2. I have tested it on linux gentoo-sources-2.6.22-r2 with a newly acquired wacom bamboo tablet.
Linuxwacom needs pixman.h from libpixman. Could this have something to do with the fact that I'm using Xorg 7.3?
Then it fails on:
./wcmCommon.c: In function 'xf86WcmEvent':
./wcmCommon.c:1099: error: 'pDev' undeclared (first use in this function)
./wcmCommon.c:1099: error: (Each undeclared identifier is reported only once
./wcmCommon.c:1099: error: for each function it appears in.)
looks like Linuxwacom needs to catch up. The New Xorg is new, so no biggie - yet ;-)
(In reply to comment #41)
I suspect it's simply a bug in the linuxwacom code. The compilation crashes inside a function definition starting like this:
void xf86WcmEvent(WacomCommonPtr common, unsigned int channel,
const WacomDeviceState* pState)
int i, suppress = 0;
pChannel = common->wcmChannel + channel;
pLast = &pChannel->valid.state;
DBG(10, common->debugLevel, ErrorF("xf86WcmEvent at channel = %d\n", channel));
/* Tool on the tablet when driver starts. This sometime causes
* access errors to the device */
#if defined WCM_XFREE86 || GET_ABI_MAJOR(ABI_XINPUT_VERSION) == 0
Unless pDev is meant to be some ugly global variable, its appearance there is probably a typo (cut & paste with insufficient editing?). After some searching and experimenting I've managed to compiled the code with the critical line stating:
I haven't tested if that actually works, but I've at least checked quickly that I can connect my Graphire 4 and get some interaction, so I'm going to share my solution and wait for extensive testing and/or better solutions from the others.
Created attachment 131092 [details, diff]
diff from linuxwacom-0.7.8_p2.ebuild to linuxwacom-0.7.8_p3.ebuild
Along with patch version increment adds media-libs/libpixman to dependencies, breaks obsolete (AFAIK) USE flag tcltk to tcl and tk, and applies patch to get rid of undeclared pDev in src/xdrv/wcmCommon.c (line 1099).
Created attachment 131093 [details, diff]
linuxwacom-0.7.8-pDev.patch for linuxwacom-0.7.8_p3.ebuild
(In reply to comment #44)
> Created an attachment (id=131093) 
> linuxwacom-0.7.8-pDev.patch for linuxwacom-0.7.8_p3.ebuild
working correctly here!
*** Bug 194506 has been marked as a duplicate of this bug. ***
This is working for me on suspend2-sources-2.6.22-r2.
What else is needed to bring this into portage?
posted ebuild for 0.7.8_p3 still has references to "tcltk":
tcltk? ( dev-lang/tcl dev-lang/tk )
also, the problem with linux-2.6.22 (see posts #38 and #39) hasn't been solved.
Created attachment 132812 [details, diff]
Omitted tcltk USE flag reference broken to tcl and tk. Worked for me before, because I have tcl and tk installed.
I'm not sure if tk flag ought not to enforce tcl; I just hope that somebody better acquainted and skillful with ebuilds will check and eventually correct that.
Comments #38 and #39 should have been dealt with before, by Denys Duchier in his ebuild for 0.7.8_p2 -- see comment #40. For me the modified ebuild for 0.7.8_p3 works with gentoo-sources-2.6.22-r6.
(In reply to comment #49)
> Comments #38 and #39 should have been dealt with before, by Denys Duchier in
> his ebuild for 0.7.8_p2 -- see comment #40. For me the modified ebuild for
> 0.7.8_p3 works with gentoo-sources-2.6.22-r6.
Oh yeah, you're right. However, I'm afraid that that ebuild won't work anymore with linux-2.6.21 and earlier.
I find that the 0.7.8-p3 version works fine with xorg-7.3 and gentoo-sources 2.6.22-r8, and any program I've used-- except for gimp (2.4.0-rc3). It acts as if the button mappings are screwed up, and it only seems to get worse when I try to change them in the gimp input settings.
BTW, this same version of gimp worked previously with 0.7.6-p4.
linuxwacom compiled with USE="gtk udev usb wacom -tcl -tk"
0.7.8-p3 works fine with my Volito2 tablet, linux-2.6.22-gentoo-r8, xorg-x11-7.2 and gimp-2.4.0 running on amd64.
I've upgraded my HOWTO to reflect the latest changes:
it seems to have some problem with bamboo tablet:
Created attachment 134867 [details]
alternative 0.7.8-3 ebuild
First of all thanks for the nice ebuild. However I had some problems with it and here I attach modiffied version of it. The changes are:
1) it will work with not only CONFIG_TABLET_USB_WACOM option in the kernel .config but also with CONFIG_USB_WACOM in the newer kernels. The same it will choose the appropriate driver path.
2) added USE flag "multitouch". Emerging with USE="-multitouch" will apply my patch (see next attachment) wich removes the multitouch "feature". This feature makes the usage almost impossible on my Lenovo X60t tablet. Accordingly to the forums I am not the only one who has this problem with the same tablet.
Created attachment 134868 [details, diff]
patch which removes the multitouch feature
patch which removes the multitouch feature. Emerge previosly attached 0.7.8-3 ebuild with USE="-multitouch" to apply this patch.
*** Bug 197699 has been marked as a duplicate of this bug. ***
antonmx's ebuild works fine with my Volito2 and linux-2.6.22.
However, USE=udev does nothing (it doesn't install the udev rules file).
# equery files linuxwacom | grep etc
60-wacom.rules does not get installed.
(In reply to comment #59)
> # equery files linuxwacom | grep etc
> 60-wacom.rules does not get installed.
You need to download 60-wacom.rules file from this page and put it into the files directory of the linuxwacom ebuild
(In reply to comment #60)
> You need to download 60-wacom.rules file from this page and put it into the
> files directory of the linuxwacom ebuild
Then the problem is, that the ebuild doesn't complain at all if the file is missing (while it should crash).
*** Bug 200876 has been marked as a duplicate of this bug. ***
*** Bug 201972 has been marked as a duplicate of this bug. ***
Do we have any idea when this new ebuild and version will make it into portage? I'll be happy to test, as my tablet is useless until it does.
I have Bamboo Fun Small and driver version 0.7.8_p3 does not support this tablet. Version 0.7.9-4 has support for this tablet. Ebuild for this version would be nice, becouse manual installation described on homepage didn't work for me as I expected.
udev rules should be installed without a use flag, see bug 158114.
antonmx, is that patch the revert of an upstream commit or did you do these changes yourself?
Created attachment 139632 [details]
Here's the linuxwacom-0.7.9_p4 ebuild I'm using. It does appear to work fine with my graphire 3 and Xorg-1.4, so it's probably worth people trying out. It doesn't have the multitouch patch applied, but I'm not certain where that came from and it seems a little odd to completely remove upstream code.
It no longer needs any of the other patches, but does use the debian udev rules, which are now always installed. It does still feature a USE flag for building the kernel module (called module, much like media-libs/libifp, although there doesn't seem to be a standard name for "build kernel module"). Ideally there would be a better method than manual installation and particularly overwriting the existing kernel module, but this does at least work. I've got some reading of the linux-mod eclass to do, and if anyone knows of other ebuilds that encounter this problem (fuse springs to mind), let me know and I'll see if we can get something cleaner going.
Lastly, I would have taken this package over a while ago when it came up as maintainer-needed, but several issues have all conspired to come together at once (not least of which is finger problems, making typing/coding much more time consuming). I therefore won't take over the package, but I'll help out however I can, and if there's still no maintainer in a few months (or more accurately once everything's returned to normal) then I'll take it over...
(In reply to comment #66)
> udev rules should be installed without a use flag, see bug 158114.
> antonmx, is that patch the revert of an upstream commit or did you do these
> changes yourself?
Just the revert. This feature, untested and annoying in many cases, was included into the main branch. So I removed it. Actually I am thinking of writing a patch which can turn it on/off on the fly. But now on vocation untill mid Feb.
antonmx, I will be committing this ebuild to the tree without your patch. I heard other complaints about missing functionality with the multitouch feature, but manually reverting is not the way to go for me.
There are two patches available, both not included upstream. Let's handle this at a new bug, ok?
(In reply to comment #69)
> antonmx, I will be committing this ebuild to the tree without your patch. I
> heard other complaints about missing functionality with the multitouch feature,
> but manually reverting is not the way to go for me.
> There are two patches available, both not included upstream. Let's handle this
> at a new bug, ok?
Hey, that is why I created the USE flag "multitouch": those who miss the functionality can turn it on, those who do not need it - cat turn it off. It is not the manually reverting: I have found that patch which included the feature and found the code where it is located and then REWROTE the code to exlude this and then created the patch. I tald reverting because I used the original patch to understand how it works. But of cause you can commit it as you prefer. I just do not understand why you do not want to give people the choise.
BTW, here I found the patch which is better than mine (accordingly to the description):
anton, please open a new bug for this discussion.
I did not mean to dispute your issue, but as you stated yourself, there are better ways to deal with this. It is a bad hack to enable or disable "bugs" at compile time. Also, it is Gentoo's policy to not deviate from upstream as far as we can, so I want to coordinate fixing that bug with them.
What I need for a next step (maybe inclusion of the patch your mentioned), is a new bug where you describe what the real problem with the vanilla upstream is (because I am missing this here).
(In reply to comment #72)
> anton, please open a new bug for this discussion.
> I did not mean to dispute your issue, but as you stated yourself, there are
> better ways to deal with this. It is a bad hack to enable or disable "bugs" at
> compile time. Also, it is Gentoo's policy to not deviate from upstream as far
> as we can, so I want to coordinate fixing that bug with them.
> What I need for a next step (maybe inclusion of the patch your mentioned), is a
> new bug where you describe what the real problem with the vanilla upstream is
> (because I am missing this here).
OK, Robert, I think you are right. It's better to do like you purpose. I will try to find a moment to post this bug. The only problem is i am pretty lazy and it's difficult to do smth unless i am forced to do, but now my pen works exactly as I expect from it..)) Anyway thanks for you work.
(In reply to comment #73)
> OK, Robert, I think you are right. It's better to do like you purpose. I will
> try to find a moment to post this bug. The only problem is i am pretty lazy and
> it's difficult to do smth unless i am forced to do, but now my pen works
> exactly as I expect from it..)) Anyway thanks for you work.
Only until the ebuild gets bumped in the tree. Just write four lines describing the problem ;-)
*** Bug 207745 has been marked as a duplicate of this bug. ***
Ok, sorry for the long wait guys, but 0.7.9_p7 is now in the tree. It's masked for the time being, as it's got a few new features and brings back the module building capability. It's been working for me for a few weeks without problem (in fact it fixed my jiggle problem), but hasn't been strongly tested on older kernels, or older Xorg versions. Please let me know how it works out by posting here... 5:)
Created attachment 144512 [details]
working here (w/ xorg-server-184.108.40.206-r3)
With the ebuilds in the tree, I think we can close this here now?
(In reply to comment #78)
> With the ebuilds in the tree, I think we can close this here now?
I would wait for it to be unmasked
Congrats! It just got unmasked. 5:) Please give the servers a couple of hours to synchronize...
For anyone affected, the multitouch bug is separately tracked as bug 211136.