On Thu, Mar 29, 2012 at 10:36 AM, Jason Gerecke <killert...@gmail.com> wrote: > On Thu, Mar 29, 2012 at 6:54 AM, Chris Bagwell <ch...@cnpbagwell.com> wrote: >> On Wed, Mar 28, 2012 at 12:31 PM, Ping Cheng <pingli...@gmail.com> wrote: >>> On Wed, Mar 28, 2012 at 9:29 AM, Jason Gerecke <killert...@gmail.com> wrote: >>>> Based on upstream commit 803296b678a43005e3bc0aaa1951d211bd76a054 >>>> >>>> Signed-off-by: Jason Gerecke <killert...@gmail.com> >>> >>> Acked-by: Ping Cheng <pi...@wacom.com> for the set. >>> >>> Ping >> >> Are you going to commit patches yourself, Jason? >> > Yeah, just haven't gotten around to it yet. > >> I had hoped for 2.6.36 that I'd copy latest upstream source into that >> directory at some point instead of porting the 3 or so missing >> features... but I'm getting a little worried that we will need a 3.3 >> or 3.4 branch soon. If I compile the latest upstream version against >> my 3.2 kernel headers then it results in a non-working driver. So we >> may need to port each feature like you've done for 2.6.36 after all. >> >> Chris > > What's the problem you're having with the 3.2 headers? I just compiled > input-wacom with my I5 backports and your upstream wireless patches > (tweaked as necessary) and don't seem to be running into any trouble > with the resulting driver working with the Arch Linux 3.2.11-1 kernel.
Good to know its working OK for you. I'm on Fedora using one of their 3.2 kernels. They are pretty aggressive at patching the kernels and its not uncommon for internal structures to be closer to future releases. When compiling the wacom files from dtor's for-linus branch but against current kernels header files I get a new warning: linux/drivers/input/tablet/wacom_sys.c:1166:1: warning: data definition has no type or storage class [enabled by default] and the driver loads OK but doesn't do anything. > > I've recently been looking at how the versions are diverging, and > there's a couple things that need to be addressed. Some are trivial, > while others may need testing. Most of the differences though looks to > be pretty easy to merge back to 2.6.30, or possibly even 2.6.16 (I'm > not familiar enough with the legacy linuxwacom code to be sure of that > statement...). The hard part will be testing to ensure everything > works properly. I see I was a little confused in my statement. I meant to say I plan to copy latest upstream to 2.6.38; not 2.6.36. I guess that anything for 2.6.36 still needs hand porting. I did start a Bamboo 3rd gen backport to 2.6.36 but its stalled out at the moment. Chris > > If I can get some time, I'd like to work out what needs to be done to > get everything in sync again. Backporting I5 took longer than expected > because of all the small bumps in the merge process.... > > Jason > > --- > Day xee-nee-svsh duu-'ushtlh-ts'it; > nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it. > Huu-chan xuu naa~-gha. ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
