I didn't reply earlier because I don't really have a good suggestion.
I can only offer the following if the patches are just to add USB ID's
to the list and not adding new driver logic.
You can make your own version of input-wacom quite easily but base it
on kernel the distribution is normally using. So at least the driver
logic in bug reports will be relative to that kernel (although we even
had a case of confusion last 2 weeks were Ubuntu added ID's and that
took some time to figure the difference out).
cp /path/to/kernel/driver/input/tablet/wacom_sys.c .
cp /path/to/kernel/driver/input/tablet/wacom_wac.c .
cp /path/to/kernel/driver/input/tablet/wacom_wac.h .
cp /path/to/kernel/driver/input/tablet/wacom.h .
[apply your patches here]
echo "wacom-objs := wacom_sys.o wacom_wac.o" > Makefile
echo "obj-m += wacom.o" >> Makefile
And to use this package, compile and install like this:
make -C /lib/modules/$(uname -r)/build SUBDIRS=$(pwd) modules
sudo cp wacom.ko /lib/modules/$(uname -r)/updates
Or some version of that that works for your packaging.
On Sun, Jul 3, 2011 at 5:34 AM, Andrzej Giniewicz <gginiu@...> wrote:
> Just today we had situation like this, if Arch used input-wacom
> module, we could add 3 new devices, but as it's for kernel <2.6.37 we
> have to wait ages before it reaches kernel. Does anyone have any
> recommendation for providing patched kernel module to users if
> input-wacom we used before isn't the right way to go? :)
> On Thu, Jun 23, 2011 at 11:41 AM, Andrzej Giniewicz <gginiu@...> wrote:
>> I'd like revive this old discussion, at least part of it :)
>> On Mon, May 23, 2011 at 4:44 PM, Chris Bagwell <chris@...> wrote:
>>> On Mon, May 23, 2011 at 1:50 AM, Andrzej Giniewicz <gginiu@...> wrote:
>>>> On Mon, May 23, 2011 at 8:37 AM, Favux ... <favux.is@...> wrote:
>>>>> I'm not going to comment on using input-wacom for the wacom.ko rather
>>>>> than the 2.6.38 or .39 kernel's wacom.ko. ;)
>>>> well, why? I though this was quite good solution when is tested,
>>>> because it seemed to me like there are more features than in latest
>>>> stable, for example at time of 2.6.38 there are some features
>>>> backported from 2.6.39? :)
>>> The main reason is that input-wacom is more a test ground. You may
>>> get a feature faster from that version but once it makes it to
>>> upstream kernel the logic may work totally different at that point.
>>> As an example, the Bamboo driver in input-wacom works different then
>>> official kernel version. That package contains multiple kernel
>>> versions and older kernels work way different while newer kernels work
>>> slightly different then official kernels do.
>>> Its sometime hard to isolate bug reports because of that.
>> After giving it some thought, I actually have to agree with that. In
>> Arch package I switched back to official kernel driver if someone uses
>> kernel newer than 2.6.36 (as described on wiki). But now I'm going to
>> raise two things I had in mind as to why I did not switched to
>> official module earlier:
>> - will inputattach work with default kernel driver? If yes, maybe it
>> would be better to distribute it with X driver, or maybe separate
>> support tools package? Right now Arch users download whole archive
>> only to get one or two files. Or maybe it also is depreceated and
>> there is some newer recommended approach I skipped when I was busy?
>> - the situation when there was input-wacom available as separate
>> package was really cool when users were to test patches. For example
>> Lenovo x220 tablet support was in Arch since 23'rd May, while it was
>> available in official kernel driver month later (2.6.39, it did not
>> worked with 2.6.38). It is a lot harder to package patched kernel
>> module when we have to use standard ways of doing so (which includes
>> pulling whole kernel sources and tweaking it's build script). Maybe
>> after all, for package maintainers, input-wacom could stay to be the
>> correct way of obtaining the driver - at least in form of repackaged
>> official module (when someone has new kernel)? That way we could
>> provide latest-greatest driver to users of our distros more easily,
>> and also earlier feedback to kernel patches :)
>> Simplify data backup and recovery for your virtual environment with vRanger.
>> Installation's a snap, and flexible recovery options mean your data is safe,
>> secure and there when you need it. Data protection magic?
>> Nope - It's vRanger. Get your free trial download today.
>> Linuxwacom-discuss mailing list
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> Linuxwacom-discuss mailing list