Bug 366

It appears that while the linuxwacom driver seems to be under the MIT/X11
license (correct me if I'm wrong), that to have the full functionality of
the linuxwacom driver, users need or will want the rest of the utilities and
other stuff included in the linuxwacom project, however most of that stuff
seems to be under the GPL license.  GPL licenced code is not accepted into
the X.Org source code tree.

So while we could include the driver portion itself into X.Org, we can't
include the bits that would make the driver fully useful to people.  Is
it still beneficial enough to just include the MIT/X11 licenced stuff into
Xorg without the rest?

My opinion (without having looked specifically at which files are under which
license) -- it would be quite helpful to have the driver portion distributed
with xorg, since that is most dependent on matching exactly the correct version
and so forth, and has to install into the same directories.  

Someone could presumably build an add-on package with the testing and
calibration utilities, which are not so tightly integrated into the X system. 
Installing this would be much easier than the currently-needed process.

I'd imagine someone who's involved with the linuxwacom project could give a
better answer here as to what level of integration makes the most sense.

It's true that the linuxwacom X driver is X11 licensed and could be distributed
with the monolithic release.

However, the linuxwacom project demonstrates shorter release cycles and quick
support for new hardware, i.e.  what we are hoping to accomplish with the
modularization of the monolithic tree.

If distributions packaged the linuxwacom drivers, the end-user experience would
be the same as if it was included in X.org.

Instead of including the linuxwacom drivers, I think we should work to better
accomodate out-of-tree drivers.  The SDK goes a long way in this respect, and
with the upcoming modularization this willl hopefully become the default.

Re: comments #1 and #2

Personally (for my own use, on my Toshiba Portege 3500) I don't need or use the
"utilities and other stuff", just the main driver itself.


Re: comment #3

>If distributions packaged the linuxwacom drivers, the end-user experience would
>be the same as if it was included in X.org.

Red Hat/Fedora's position on this issue is here:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=118638

---begin quote from above URL---
 Additional Comment #1 From Mike A. Harris  on 2004-03-23 15:09 -------

It is best if the upstream Xorg sources directly include the new
wacom driver in the upcoming release instead, as that way there is
a common base, which is easier to maintain, and more consistent.

Can you file a request for enhancement for this in the upstream
bugzilla at http://bugs.freedesktop.org against the "xorg"
product?

Thanks in advance.
---end quote---

>Instead of including the linuxwacom drivers, I think we should work to better
>accomodate out-of-tree drivers.  The SDK goes a long way in this respect, and
>with the upcoming modularization this willl hopefully become the default.

That might be nice for the future, but in the meantime, is there a valid reason
to drag around an obsolete wacom driver in the tree? I mean, if the driver's not
going to be updated even once every several releases, shouldn't it at least be
removed altogether? (Maybe I'm not understanding something here...)

I agree with Kristian, that it is best to spend effort supporting out-of-tree
driver builds for things like this, especially when the driver gets frequent
updates and releases on a schedule faster than X.Org does.  We definitely
are moving in the direction of modularization over the long term, so this
makes sense if it is doable now, which it is.

From the viewpoint of the older wacom driver in X.Org, if it doesn't work
at all, it should be disabled completely and removed from the tree.  If it
is included, it should be updated to something current, however it is too
late for driver updates for 6.8.0 at this point, so it will likely ship
as-is now, which is unfortunate, but this problem comes to us in the 11th
hour of the Xorg devel cycle, so there isn't likely much that can be
done until after 6.8.0.

From the viewpoint of Red Hat/Fedora Core OS builds, Kristian has created
a linuxwacom rpm package which I believe is either in fedora devel now, or
destined to be there this week sometime.  I will be modifying our X.Org
rpms to disable the X.Org included wacom driver, as that makes the most
sense for our OS right now at this point in time.

I think this report should remain open in Xorg bugzilla however, until either:

1) The wacom driver is updated

or

2) AN official decision is made to remove the ancient driver and move to
   out of tree modular driver builds.


The latter solution has the benefit that the non-MIT licensed bits can be
included in the same rpm packaging (or deb, or whatever), and so will be
matched to the driver.

I made patches for wacom driver, xf86Wacom.c, and its man page, wacom.man, 
against the source of X11R6.8.1 under directory 
xc/programs/Xserver/hw/xfree86/input/wacom last Nov. Please check bug 1917 for 
the patches. I think, unless you remove Wacom driver from the Xorg source, we 
still need to update the driver since other vendors may include the driver 
from Xorg instead of from linuxwacom.sf.net. 

I didn't search the bug database before I submitted the patches last Nov. 
Otherwise, I would have attached them here.

*** This bug has been marked as a duplicate of 1910 ***