x11-drivers/xf86-input-wacom is a (I suppose) branch of x11-drivers/linuxwacom specifically meant for >=xorg-server-1.6 support. It will also be maintained in the freedesktop.org repositories. Announcement here: http://sourceforge.net/mailarchive/forum.php?thread_name=167e8a330910051544g3eebb627lc5dca5ceb03076b8%40mail.gmail.com&forum_name=linuxwacom-devel Currently the driver compiles and works as a pointing device, however it does not send mouse/kbd events yet (needs to be rewritten, I think). linuxwacom will not build against xorg-server-1.7, so I think it's preferable to either use xf86-input-wacom or to completely mask wacom support from xorg-server/drivers-1.7 for the time being. Reproducible: Always
Created attachment 208422 [details] xf86-input-wacom live ebuild
(CC'ing linuxwacom maintainers)
Thanks very much for the build and the news Matthew! 5:) I've tried it out and it all seems to be working fine with my mouse (Graphire 3), so I've added it to my overlay. We'll push out a final one when they produce a tarball I guess. Feel free to prod us/me when that happens if we don't spot it... Thanks again! 5:)
While the X driver contained in this package seems to compile on my ~amd64 machine, the 'linuxwacom' package comes with a number of useful extras. Selected output from 'equery f linuxwacom' missing in xf86-input-wacom: /etc/udev/rules.d/60-wacom.rules /usr/bin/wacdump /usr/bin/xidump /usr/bin/xsetwacom /usr/share/hal/fdi/policy/20thirdparty/10-linuxwacom.fdi Neither the xorg-devel or linuxwacom-discuss/-devel mailing lists seem to have any discussion of what's happening with these tools & scripts in the move.
I don't think the udev rules are actually needed. My tablet is detected and the kernel and xorg drivers are loaded automatically without them. I have no idea what wacdump or xidump were for. xsetwacom probably isn't needed, as you can probably just set the properties via xinput. The hal policy file and wacomcpl (and xsetwacom, if needed) will need rewriting as there have been significant changes to the properties and how they're dealt with. Unfortunately I don't think the man pages have been updated yet.
I talked to Petter Hutterer (the upstream dev behind this friendly fork) and he will release new tarballs soon. I'd be more than happy to put the live ebuild in the x11 overlay and help with maintenance of the releases as going through FreeDesktop instead of SourceForge is much easier for us. (That and I know upstream now) Your call :)
Ok, so I've put it in the x11 overlay (with slight modifications). It'll go in portage when upstream makes a 0.10 release and xorg-drivers will be updated then. Thanks
Yep, you're welcome to look after it if you like Remi. I'll keep a copy in my overlay (since I don't use the X11 overlay) until it's in the tree (masked or otherwise). Hope that's ok?
Ok, I've now commented out the wacom USE flag and support from xorg-drivers-1.7 until xf86-input-wacom hits the tree. Linuxwacom also now requires <xorg-server-1.7. That will hopefully stop the confused users (or at least, ensure confused users don't end up with a broken system)...
FTR, I've made xorg-drivers-9999 use xf86-input-wacom. Cheers
0.10.0 is now in portage. Please test it out and report bugs :) Thanks
Created attachment 209359 [details] hook-up debug USE flag latest release has configurable debugging output
1) unified diffs are easier to review (diff -u) 2) IUSE is still empty. So, NAK as-is. Thanks
Created attachment 209374 [details] retry as patch, explicitly declare flag I've had conflicting requests over the preference of patches vs. complete ebuilds. So I have no idea what to post anymore. Also, the debug flag is set by the eclass, so I didn't think it was necessary to explicitly declare it.
(In reply to comment #14) > Created an attachment (id=209374) [details] > retry as patch, explicitly declare flag I've committed your patch nearly as is :) > I've had conflicting requests over the preference of patches vs. complete > ebuilds. So I have no idea what to post anymore. I guess this inconsistency is very consistent of us ;) > Also, the debug flag is set by the eclass, so I didn't think it was necessary > to explicitly declare it. Actually, the eclass IUSE and the ebuild IUSE are totally separate. So if the either one uses the flag somehow, it must be referenced in the local IUSE. Thanks
People, I don't get it - why do you put KERNEL driver package into xorg-driver package? Am I missing something? X is still a userspace app, and linuxwacom is still a kernelspace thing. So, why all this mess? Why new package?
Respon(In reply to comment #16) > People, I don't get it - why do you put KERNEL driver package into xorg-driver > package? Am I missing something? X is still a userspace app, and linuxwacom is > still a kernelspace thing. So, why all this mess? Why new package? > Responding to closed bug is not smartest idea you can do TM Well linuxwacom is old approach and using kernel driver for such stuff was wrong. Now they are doing it correctly with cooperation with xorg devs so it got onto git repository at freedesktop.org and has new name + releases.
This package is the (new/updated) xorg driver only. It does not contain the kernel parts.
I hate to add to an already closed bug, especially since you've received two replies already, but I wanted to avoid any confusion. Wacom graphics tablets have always required both kernel drivers and x11 drivers to function under X, so that's both kernel and userspace drivers. The wacom kernel drivers have been part of the 2.6 kernel for a few years now, but linuxwacom still offered the modules for those that wanted to build them out-of-tree, because the release cycles between the kernel and linuxwacom weren't always the same. This is why the linuxwacom package has a USE="modules" use flag, so that you can turn off the kernel module section, because they might be unnecessary. The x11 driver and tools were the primary purpose of the package, and hence were always built. Recently the xorg-server input architecture changed, and the old linuxwacom package has not been updated to the new architecture. Instead the x11 driver was taken from the package, updated, and turned into xf86-input-wacom. This is purely userspace, and assumes that the kernel modules have been built separately. In summary: x11-drivers/linuxwacom for <=xorg-server-1.6 No need for in-kernel kernel modules if USE=modules. x11-drivers/xf86-input-wacom for >=xorg-server-1.7 Requires that the kernel modules be built (and since Gentoo doesn't separately package the modules, this must be done in-kernel). Hopefully that clears everything up? If not, please contact me separately on IRC or by email and I'll be happy to clear up any remaining confusion. 5:)
My Intuos 4 is nothing more than a mouse now. The stylus/cursor functions are completely broken. The HAL fdi file that were written with the linuxwacom.ebuild worked like a champ. Why would this get introduced into the tree with no stylus support?? I guess I am headed over to linuxwacom to see whats up with development support for xorg-server 1.7.1 or downgrading back to xorg-1.6.x
Actually, we're aware of the problem. Do please remember however that this is ~arch, and there's no guarantee that packages will work perfectly on entering the tree. The autodetection has some issues, and we're working to resolve them (see freedesktop.org bug 25095). The wacom.fdi file alone will not work, because it requires a small helper program to be installed alongside it. Please could you test out the build in the ikelos overlay (which features the HAL patch) and let me know if that solves your problems? If not, please file a new bug. Also, in future, please take the time to open a new bug when you encounter an issue anyway, rather than just leaving a comment on an already closed bug that does not describe your issue.
