Bug 1910

Created attachment 1358 [details] [review]
huge, but very well-tested, patch

Comment on attachment 1358 [details] [review]
huge, but very well-tested, patch

make roland less angry

(In reply to comment #0)
> Since there is no parallel development going on and it has been well-tested by
> most distributions (I believe Red Hat incorporates it also), please, please,
> incorporate it for the next release, or drop the Wacom driver from the tree.

We actually package the linuxwacom.sf.net drivers seperately in the linuxwacom
rpm and disable the in-tree wacom drivers.  I think this is the better way to
go, with the modularization on the horizon.  I would expect that the in-tree
driver just goes away when we modularize the distribution, and linuxwacom.sf.net
becomes the oficially sanctioned wacom driver.

While I think the code drop is a bit much for a point-release, I don't see it
affecting the overall server stability, and I agree that you probably can't
break the in-tree driver more than it already is.

It's worth checking out the discussion in bug #366 when considering this.

> We actually package the linuxwacom.sf.net drivers seperately in the linuxwacom
> rpm and disable the in-tree wacom drivers.  I think this is the better way to
> go, with the modularization on the horizon.  I would expect that the in-tree
> driver just goes away when we modularize the distribution, and linuxwacom.sf.net
> becomes the oficially sanctioned wacom driver.

We just have it in our #000_* patches, which we don't really count in our 'how
many patches do we have' count, as they're typically taken from upstream anyway.
 While I agree that pointing people to linuxwacom is the way to go in terms of
modularisation, the fact that the Wacom there is there by default indicates that
it's there to be used and it works, and I believe it should either be dropped,
or made vaguely useful.

Are there any objections?

only that bug #1917 conflicts...

*** Bug 1917 has been marked as a duplicate of this bug. ***

i'm going to merge this at some point

i'm going to merge this at some point

*** Bug 366 has been marked as a duplicate of this bug. ***

while this will be addressed in future modular releases by just making
linuxwacom.sf.net the official driver, we still need to resolve this for 7.0,
either by merging daniel's patch or by dropping our copy of the wacom driver.

just a friendly reminder.

If no-one has any objections, I think we should drop our version.

marked as deprecated on the wiki:

http://xorg.freedesktop.org/wiki/DeprecatedInX11R7

leaving open until 7.0 release on the off chance that someone has a convincing
argument for updating our version.

Hi,

I just saw this bug whilst investigating possible reasons for relative mode not
working with the 2.6.13_rc1,2,3 kernels.  Anyway, during my investigations I
found that linuxwacom apparently still doesn't support dlloader.  Not only is
dlloader slated to be the default module loading method in new Xorgs, but also
it's the only way to load modules on a pic/pie hardened system.  Therefore,
until this is implemented in linuxwacom I'd recommend not deprecating the
in-built version which does appear to build and work with dlloader.  Thanks,

Mike  5:)

dlloader support will take care of itself, in my opinion.  someone will try to
use linuxwacom with 6.9/7.0, notice that it fails, and run the ld magic to
convert it to dlloader format.  it's really quite trivial.

with that said: the wacom driver is autotooled for 7.0, but is still being
marked deprecated, and will not be updated to match linuxwacom.  closing.