Graphire4 Pad Button freeze with 0.10.11.
|
View:
New views
13 Messages
—
Rating Filter:
Alert me
|
 |
Graphire4 Pad Button freeze with 0.10.11.
by Favux ...
::
Rate this Message:
Hi list,
We're seeing some problems with the Graphire4 pad buttons in Ubuntu Natty (2.6.38 and xf86-input-wacom-0.10.11). Peter said he needed some more information. I have a little now. See this Launchpad bug report: https://bugs.launchpad.net/ubuntu/+source/xf86-input-wacom/+bug/782756 and this possibly related one: https://bugs.edge.launchpad.net/ubuntu/+source/xf86-input-wacom/+bug/769477 What happens is the Graphire's buttons work until the stylus is used then they stop working. The only way to fix the button freeze is to hot plug the tablet. Chris worked on the Graphire pad button logic a few months ago. I seem to recall Chris and Ping talking about maybe implementing some kernel changes for the Graphire pad logic also, but I don't think anything happened. I've attached Conner's debug Xorg.0.log and his annotated version where he describes his actions. As far as I can see he gets a 6:usbParseKeyEvent when the buttons are working and the pad is recognized and a button event sent. But once he uses the stylus the 6:usbParseKeyEvent no longer happens. However I do see it pop up, apparently after he has unplugged his tablet, in the tablet removed stuff. Any help appreciated. Favux PS: This is my third attempt to post. Because of size limitations the Xorg.0.log can't be attached and the annotated Xorg.0.log had to be compressed. ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 _______________________________________________ Linuxwacom-discuss mailing list Linuxwacom-discuss@... https://lists.sourceforge.net/lists/listinfo/linuxwacom-discuss |
|
|
Re: Graphire4 Pad Button freeze with 0.10.11.
by Chris Bagwell
::
Rate this Message:
Hi Favux,
For first bug report, it does sound same issue as I looked into a while back. The kernel driver is mistakenly telling userland that the PAD device has gone out of proximity when you use pen. From that point, buttons don't work. Something has changed in xf86-input-wacom that we must l trust kernel information more then we used to. My personal preference is to fix the kernel to give us good info instead of reverting back to old xf86-input-wacom behavior. Maybe when Ping gets back next month we can have some progress. Or hopefully we can find a user that doesn't mind hacking kernel drivers. I can give tons of guidance on patch to implement (its like 3 lines for simple solution) but ultimately I can't push forward much more since I don't have the device. For second bug report (X server crash), I've no idea. It sounds like its own issue. Chris On Fri, May 27, 2011 at 3:45 PM, Favux ... <favux.is@...> wrote: > Hi list, > > We're seeing some problems with the Graphire4 pad buttons in Ubuntu > Natty (2.6.38 and xf86-input-wacom-0.10.11). Peter said he needed > some more information. I have a little now. > > See this Launchpad bug report: > https://bugs.launchpad.net/ubuntu/+source/xf86-input-wacom/+bug/782756 > and this possibly related one: > https://bugs.edge.launchpad.net/ubuntu/+source/xf86-input-wacom/+bug/769477 > > What happens is the Graphire's buttons work until the stylus is used > then they stop working. The only way to fix the button freeze is to > hot plug the tablet. > > Chris worked on the Graphire pad button logic a few months ago. I > seem to recall Chris and Ping talking about maybe implementing some > kernel changes for the Graphire pad logic also, but I don't think > anything happened. > > I've attached Conner's debug Xorg.0.log and his annotated version > where he describes his actions. As far as I can see he gets a > 6:usbParseKeyEvent when the buttons are working and the pad is > recognized and a button event sent. But once he uses the stylus the > 6:usbParseKeyEvent no longer happens. However I do see it pop up, > apparently after he has unplugged his tablet, in the tablet removed > stuff. > > Any help appreciated. > > Favux > > PS: This is my third attempt to post. Because of size limitations > the Xorg.0.log can't be attached and the annotated Xorg.0.log had to > be compressed. > > ------------------------------------------------------------------------------ > vRanger cuts backup time in half-while increasing security. > With the market-leading solution for virtual backup and recovery, > you get blazing-fast, flexible, and affordable data protection. > Download your free trial now. > http://p.sf.net/sfu/quest-d2dcopy1 > _______________________________________________ > Linuxwacom-discuss mailing list > Linuxwacom-discuss@... > https://lists.sourceforge.net/lists/listinfo/linuxwacom-discuss > > ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 _______________________________________________ Linuxwacom-discuss mailing list Linuxwacom-discuss@... https://lists.sourceforge.net/lists/listinfo/linuxwacom-discuss |
|
|
Re: Graphire4 Pad Button freeze with 0.10.11.
by Favux ...
::
Rate this Message:
Hi Chris,
Thank you for responding. I'll quote you on the bug report and hopefully Connor or another Graphire4 will take up the challenge. The timing is perfect because I just finished updating my HOW TO and it includes a little guide on how to compile the wacom.ko from Ubuntu source code. So if they don't know how they'll have something to look at. I'm guessing patches on the 2.6.38 kernel wacom_wac.c should be good to go for the 2.6.39's wacom_wac.c and so can be submitted to Linux-input. Favux ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 _______________________________________________ Linuxwacom-discuss mailing list Linuxwacom-discuss@... https://lists.sourceforge.net/lists/listinfo/linuxwacom-discuss |
|
|
Re: Graphire4 Pad Button freeze with 0.10.11.
by Jason G.
::
Rate this Message:
On Fri, May 27, 2011 at 9:11 PM, Chris Bagwell <chris@...> wrote:
> Hi Favux, > > For first bug report, it does sound same issue as I looked into a > while back. The kernel driver is mistakenly telling userland that the > PAD device has gone out of proximity when you use pen. From that > point, buttons don't work. > > Something has changed in xf86-input-wacom that we must l trust kernel > information more then we used to. My personal preference is to fix > the kernel to give us good info instead of reverting back to old > xf86-input-wacom behavior. > > Maybe when Ping gets back next month we can have some progress. Or > hopefully we can find a user that doesn't mind hacking kernel drivers. > I can give tons of guidance on patch to implement (its like 3 lines > for simple solution) but ultimately I can't push forward much more > since I don't have the device. > > For second bug report (X server crash), I've no idea. It sounds like > its own issue. > > Chris > > On Fri, May 27, 2011 at 3:45 PM, Favux ... <favux.is@...> wrote: >> Hi list, >> >> We're seeing some problems with the Graphire4 pad buttons in Ubuntu >> Natty (2.6.38 and xf86-input-wacom-0.10.11). Peter said he needed >> some more information. I have a little now. >> >> See this Launchpad bug report: >> https://bugs.launchpad.net/ubuntu/+source/xf86-input-wacom/+bug/782756 >> and this possibly related one: >> https://bugs.edge.launchpad.net/ubuntu/+source/xf86-input-wacom/+bug/769477 >> >> What happens is the Graphire's buttons work until the stylus is used >> then they stop working. The only way to fix the button freeze is to >> hot plug the tablet. >> >> Chris worked on the Graphire pad button logic a few months ago. I >> seem to recall Chris and Ping talking about maybe implementing some >> kernel changes for the Graphire pad logic also, but I don't think >> anything happened. >> >> I've attached Conner's debug Xorg.0.log and his annotated version >> where he describes his actions. As far as I can see he gets a >> 6:usbParseKeyEvent when the buttons are working and the pad is >> recognized and a button event sent. But once he uses the stylus the >> 6:usbParseKeyEvent no longer happens. However I do see it pop up, >> apparently after he has unplugged his tablet, in the tablet removed >> stuff. >> >> Any help appreciated. >> >> Favux >> >> PS: This is my third attempt to post. Because of size limitations >> the Xorg.0.log can't be attached and the annotated Xorg.0.log had to >> be compressed. >> >> >> > Chris, I just happen to have a Graphire4 at home. If you have an idea of where the bug may lie, I'd be happy to try patching up the kernel code :) Jason --- Day xee-nee-svsh duu-'ushtlh-ts'it; nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it. Huu-chan xuu naa~-gha. ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 _______________________________________________ Linuxwacom-discuss mailing list Linuxwacom-discuss@... https://lists.sourceforge.net/lists/listinfo/linuxwacom-discuss |
|
|
Re: Graphire4 Pad Button freeze with 0.10.11.
by Chris Bagwell
::
Rate this Message:
On Sat, May 28, 2011 at 3:54 PM, Jason Gerecke <killertofu@...> wrote:
> On Fri, May 27, 2011 at 9:11 PM, Chris Bagwell <chris@...> wrote: >> Hi Favux, >> >> For first bug report, it does sound same issue as I looked into a >> while back. The kernel driver is mistakenly telling userland that the >> PAD device has gone out of proximity when you use pen. From that >> point, buttons don't work. >> >> Something has changed in xf86-input-wacom that we must l trust kernel >> information more then we used to. My personal preference is to fix >> the kernel to give us good info instead of reverting back to old >> xf86-input-wacom behavior. >> >> Maybe when Ping gets back next month we can have some progress. Or >> hopefully we can find a user that doesn't mind hacking kernel drivers. >> I can give tons of guidance on patch to implement (its like 3 lines >> for simple solution) but ultimately I can't push forward much more >> since I don't have the device. >> >> For second bug report (X server crash), I've no idea. It sounds like >> its own issue. >> >> Chris >> > > Chris, I just happen to have a Graphire4 at home. If you have an idea > of where the bug may lie, I'd be happy to try patching up the kernel > code :) > > Jason > against Linus' git that was rebased at some random time in last month or two. Originally, I was going to give you a patch against input-wacom but it looks like that is different compared to upstream for graphire. Specifically, it is correctly setting MSC_SERIAL when switching over to pen. That means input-wacom may be working with graphire4. input-wacom is not ever sending BTN_TOOL_FINGER for some reason so if its not working then thats probably only change needed (add it back in to match kernel). Chris [graphire.diff] diff --git a/drivers/input/tablet/wacom_wac.c b/drivers/input/tablet/wacom_wac.c index 08ba5ad..27bbfc0 100644 --- a/drivers/input/tablet/wacom_wac.c +++ b/drivers/input/tablet/wacom_wac.c @@ -263,6 +263,8 @@ static int wacom_graphire_irq(struct wacom_wac *wacom) if (!prox) wacom->id[0] = 0; input_report_abs(input, ABS_MISC, wacom->id[0]); /* report tool id */ + input_event(input, EV_MSC, MSC_SERIAL, 1); + input_report_key(input, wacom->tool[0], prox); input_sync(input); /* sync last event */ } @@ -295,7 +297,7 @@ static int wacom_graphire_irq(struct wacom_wac *wacom) input_report_key(input, BTN_4, (data[7] & 0x10)); input_report_key(input, BTN_5, (data[7] & 0x40)); input_report_abs(input, ABS_WHEEL, (data[8] & 0x7f)); - input_report_key(input, BTN_TOOL_FINGER, 0xf0); + input_report_key(input, BTN_TOOL_FINGER, prox); if (!prox) wacom->id[1] = 0; input_report_abs(input, ABS_MISC, wacom->id[1]); ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 _______________________________________________ Linuxwacom-discuss mailing list Linuxwacom-discuss@... https://lists.sourceforge.net/lists/listinfo/linuxwacom-discuss |
|
|
Re: Graphire4 Pad Button freeze with 0.10.11.
by Jason G.
::
Rate this Message:
On Sat, May 28, 2011 at 5:53 PM, Chris Bagwell <chris@...> wrote:
> On Sat, May 28, 2011 at 3:54 PM, Jason Gerecke <killertofu@...> wrote: >> On Fri, May 27, 2011 at 9:11 PM, Chris Bagwell <chris@...> wrote: >>> Hi Favux, >>> >>> For first bug report, it does sound same issue as I looked into a >>> while back. The kernel driver is mistakenly telling userland that the >>> PAD device has gone out of proximity when you use pen. From that >>> point, buttons don't work. >>> >>> Something has changed in xf86-input-wacom that we must l trust kernel >>> information more then we used to. My personal preference is to fix >>> the kernel to give us good info instead of reverting back to old >>> xf86-input-wacom behavior. >>> >>> Maybe when Ping gets back next month we can have some progress. Or >>> hopefully we can find a user that doesn't mind hacking kernel drivers. >>> I can give tons of guidance on patch to implement (its like 3 lines >>> for simple solution) but ultimately I can't push forward much more >>> since I don't have the device. >>> >>> For second bug report (X server crash), I've no idea. It sounds like >>> its own issue. >>> >>> Chris >>> >> >> Chris, I just happen to have a Graphire4 at home. If you have an idea >> of where the bug may lie, I'd be happy to try patching up the kernel >> code :) >> >> Jason >> > > Cool. I've attached the patch I think that is needed. This is > against Linus' git that was rebased at some random time in last month > or two. > > Originally, I was going to give you a patch against input-wacom but it > looks like that is different compared to upstream for graphire. > Specifically, it is correctly setting MSC_SERIAL when switching over > to pen. > > That means input-wacom may be working with graphire4. input-wacom is > not ever sending BTN_TOOL_FINGER for some reason so if its not working > then thats probably only change needed (add it back in to match > kernel). > > Chris > While I can confirm the bug under Ubuntu 11.04 64-bit (2.6.38-8-generic), I can't under my 32-bit Arch Linux development box. This was tested with the pre-installed "2.6.38-ARCH" kernel, as well as the tarballs from kernel.org for 2.6.38.7 or 2.8.39 (with the config from /proc/config used as the source). xf86-input-wacom was from Git obviously :) There is a similar bug under these kernels (multiple presses to the same pad button don't work while pen is in prox -- you either have to press another button before the first works again, or take the pen out of prox to press buttons repeatedly). I'll try setting up a build environment under my virtual Ubuntu box to see what the official kernel sources do there. Jason --- Day xee-nee-svsh duu-'ushtlh-ts'it; nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it. Huu-chan xuu naa~-gha. ------------------------------------------------------------------------------ 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. http://p.sf.net/sfu/quest-sfdev2dev _______________________________________________ Linuxwacom-discuss mailing list Linuxwacom-discuss@... https://lists.sourceforge.net/lists/listinfo/linuxwacom-discuss |
|
|
Re: Graphire4 Pad Button freeze with 0.10.11.
by Favux ...
::
Rate this Message:
On Tue, May 31, 2011 at 1:28 PM, Jason Gerecke <killertofu@...> wrote:
> On Sat, May 28, 2011 at 5:53 PM, Chris Bagwell <chris@...> wrote: > > While I can confirm the bug under Ubuntu 11.04 64-bit > (2.6.38-8-generic), I can't under my 32-bit Arch Linux development > box. This was tested with the pre-installed "2.6.38-ARCH" kernel, as > well as the tarballs from kernel.org for 2.6.38.7 or 2.8.39 (with the > config from /proc/config used as the source). xf86-input-wacom was > from Git obviously :) Andrzej Giniewicz (the Arch Wacom package maintainer) is using the input-wacom wacom.ko for at least 2.6.38 & 2.6.39. So that fits with what Chris said about input-wacom. > There is a similar bug under these kernels (multiple presses to the > same pad button don't work while pen is in prox -- you either have to > press another button before the first works again, or take the pen out > of prox to press buttons repeatedly). > > I'll try setting up a build environment under my virtual Ubuntu box to > see what the official kernel sources do there. > > Jason > Favux ------------------------------------------------------------------------------ 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. http://p.sf.net/sfu/quest-sfdev2dev _______________________________________________ Linuxwacom-discuss mailing list Linuxwacom-discuss@... https://lists.sourceforge.net/lists/listinfo/linuxwacom-discuss |
|
|
Re: Graphire4 Pad Button freeze with 0.10.11.
by Chris Bagwell
::
Rate this Message:
On Tue, May 31, 2011 at 1:28 PM, Jason Gerecke <killertofu@...> wrote:
> On Sat, May 28, 2011 at 5:53 PM, Chris Bagwell <chris@...> wrote: >> On Sat, May 28, 2011 at 3:54 PM, Jason Gerecke <killertofu@...> wrote: >>> On Fri, May 27, 2011 at 9:11 PM, Chris Bagwell <chris@...> wrote: >>>> Hi Favux, >>>> >>>> For first bug report, it does sound same issue as I looked into a >>>> while back. The kernel driver is mistakenly telling userland that the >>>> PAD device has gone out of proximity when you use pen. From that >>>> point, buttons don't work. >>>> >>>> Something has changed in xf86-input-wacom that we must l trust kernel >>>> information more then we used to. My personal preference is to fix >>>> the kernel to give us good info instead of reverting back to old >>>> xf86-input-wacom behavior. >>>> >>>> Maybe when Ping gets back next month we can have some progress. Or >>>> hopefully we can find a user that doesn't mind hacking kernel drivers. >>>> I can give tons of guidance on patch to implement (its like 3 lines >>>> for simple solution) but ultimately I can't push forward much more >>>> since I don't have the device. >>>> >>>> For second bug report (X server crash), I've no idea. It sounds like >>>> its own issue. >>>> >>>> Chris >>>> >>> >>> Chris, I just happen to have a Graphire4 at home. If you have an idea >>> of where the bug may lie, I'd be happy to try patching up the kernel >>> code :) >>> >>> Jason >>> >> >> Cool. I've attached the patch I think that is needed. This is >> against Linus' git that was rebased at some random time in last month >> or two. >> >> Originally, I was going to give you a patch against input-wacom but it >> looks like that is different compared to upstream for graphire. >> Specifically, it is correctly setting MSC_SERIAL when switching over >> to pen. >> >> That means input-wacom may be working with graphire4. input-wacom is >> not ever sending BTN_TOOL_FINGER for some reason so if its not working >> then thats probably only change needed (add it back in to match >> kernel). >> >> Chris >> > > While I can confirm the bug under Ubuntu 11.04 64-bit > (2.6.38-8-generic), I can't under my 32-bit Arch Linux development > box. This was tested with the pre-installed "2.6.38-ARCH" kernel, as > well as the tarballs from kernel.org for 2.6.38.7 or 2.8.39 (with the > config from /proc/config used as the source). xf86-input-wacom was > from Git obviously :) > Strange. Must be distro's backporting patches. > There is a similar bug under these kernels (multiple presses to the > same pad button don't work while pen is in prox -- you either have to > press another button before the first works again, or take the pen out > of prox to press buttons repeatedly). Yeah, that sounds about right for this bug. When switching tools (PEN vs. PAD), we are not correctly changing serial # and that side affect can be seen a few different ways. > > I'll try setting up a build environment under my virtual Ubuntu box to > see what the official kernel sources do there. Since Graphire is generally stable, I look at git to see whats been changing. Here is immediately interesting one. Looks like a non-Tablet PC change snuck in this commit. commit ab687b18aa77aeda5472d9ea054bf92c45c49c0c Author: Ping Cheng <pingc@...> Date: Mon Apr 5 23:07:41 2010 -0700 Input: wacom - streamline 2-finger touch support Clean up 2-finger touch support. This still needs to be converted to proper multi-touch protocol. Signed-off-by: Ping Cheng <pingc@...> Signed-off-by: Dmitry Torokhov <dtor@...> diff --git a/drivers/input/tablet/wacom_wac.c b/drivers/input/tablet/wacom_wac.c index 950a81d..847fd01 100644 --- a/drivers/input/tablet/wacom_wac.c +++ b/drivers/input/tablet/wacom_wac.c @@ -236,13 +236,12 @@ static int wacom_graphire_irq(struct wacom_wac *wacom) rw = ((data[7] & 0x18) >> 3) - ((data[7] & 0x20) >> 3); input_report_rel(input, REL_WHEEL, rw); input_report_key(input, BTN_TOOL_FINGER, 0xf0); - input_report_abs(input, ABS_MISC, wacom->id[1]); if (!prox) wacom->id[1] = 0; input_report_abs(input, ABS_MISC, wacom->id[1]); input_event(input, EV_MSC, MSC_SERIAL, 0xf0); + retval = 1; } - retval = 1; break; There more in that patch but just wanted to show the part about ABS_MISC being removed. Here is my original email ton linuxwacom-devel to describe gist of problem. It contains reference to why removing that above ABS_MISC may have side affect of fixing graphire issue. http://sourceforge.net/mailarchive/message.php?msg_id=27202503 I prefer my patch I included in this thread alaready for its correctness but I think above happens to make things squeak by. Chris ------------------------------------------------------------------------------ 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. http://p.sf.net/sfu/quest-sfdev2dev _______________________________________________ Linuxwacom-discuss mailing list Linuxwacom-discuss@... https://lists.sourceforge.net/lists/listinfo/linuxwacom-discuss |
|
|
Re: Graphire4 Pad Button freeze with 0.10.11.
by Jason G.
::
Rate this Message:
On Tue, May 31, 2011 at 12:43 PM, Chris Bagwell <chris@...> wrote:
> On Tue, May 31, 2011 at 1:28 PM, Jason Gerecke <killertofu@...> wrote: >> On Sat, May 28, 2011 at 5:53 PM, Chris Bagwell <chris@...> wrote: >>> On Sat, May 28, 2011 at 3:54 PM, Jason Gerecke <killertofu@...> wrote: >>>> On Fri, May 27, 2011 at 9:11 PM, Chris Bagwell <chris@...> wrote: >>>>> Hi Favux, >>>>> >>>>> For first bug report, it does sound same issue as I looked into a >>>>> while back. The kernel driver is mistakenly telling userland that the >>>>> PAD device has gone out of proximity when you use pen. From that >>>>> point, buttons don't work. >>>>> >>>>> Something has changed in xf86-input-wacom that we must l trust kernel >>>>> information more then we used to. My personal preference is to fix >>>>> the kernel to give us good info instead of reverting back to old >>>>> xf86-input-wacom behavior. >>>>> >>>>> Maybe when Ping gets back next month we can have some progress. Or >>>>> hopefully we can find a user that doesn't mind hacking kernel drivers. >>>>> I can give tons of guidance on patch to implement (its like 3 lines >>>>> for simple solution) but ultimately I can't push forward much more >>>>> since I don't have the device. >>>>> >>>>> For second bug report (X server crash), I've no idea. It sounds like >>>>> its own issue. >>>>> >>>>> Chris >>>>> >>>> >>>> Chris, I just happen to have a Graphire4 at home. If you have an idea >>>> of where the bug may lie, I'd be happy to try patching up the kernel >>>> code :) >>>> >>>> Jason >>>> >>> >>> Cool. I've attached the patch I think that is needed. This is >>> against Linus' git that was rebased at some random time in last month >>> or two. >>> >>> Originally, I was going to give you a patch against input-wacom but it >>> looks like that is different compared to upstream for graphire. >>> Specifically, it is correctly setting MSC_SERIAL when switching over >>> to pen. >>> >>> That means input-wacom may be working with graphire4. input-wacom is >>> not ever sending BTN_TOOL_FINGER for some reason so if its not working >>> then thats probably only change needed (add it back in to match >>> kernel). >>> >>> Chris >>> >> >> While I can confirm the bug under Ubuntu 11.04 64-bit >> (2.6.38-8-generic), I can't under my 32-bit Arch Linux development >> box. This was tested with the pre-installed "2.6.38-ARCH" kernel, as >> well as the tarballs from kernel.org for 2.6.38.7 or 2.8.39 (with the >> config from /proc/config used as the source). xf86-input-wacom was >> from Git obviously :) >> > > Strange. Must be distro's backporting patches. > >> There is a similar bug under these kernels (multiple presses to the >> same pad button don't work while pen is in prox -- you either have to >> press another button before the first works again, or take the pen out >> of prox to press buttons repeatedly). > > Yeah, that sounds about right for this bug. When switching tools (PEN > vs. PAD), we are not correctly changing serial # and that side affect > can be seen a few different ways. > >> >> I'll try setting up a build environment under my virtual Ubuntu box to >> see what the official kernel sources do there. > > Since Graphire is generally stable, I look at git to see whats been > changing. Here is immediately interesting one. Looks like a > non-Tablet PC change snuck in this commit. > > commit ab687b18aa77aeda5472d9ea054bf92c45c49c0c > Author: Ping Cheng <pingc@...> > Date: Mon Apr 5 23:07:41 2010 -0700 > > Input: wacom - streamline 2-finger touch support > > Clean up 2-finger touch support. This still needs to be converted to > proper multi-touch protocol. > > Signed-off-by: Ping Cheng <pingc@...> > Signed-off-by: Dmitry Torokhov <dtor@...> > > diff --git a/drivers/input/tablet/wacom_wac.c b/drivers/input/tablet/wacom_wac.c > index 950a81d..847fd01 100644 > --- a/drivers/input/tablet/wacom_wac.c > +++ b/drivers/input/tablet/wacom_wac.c > @@ -236,13 +236,12 @@ static int wacom_graphire_irq(struct wacom_wac *wacom) > rw = ((data[7] & 0x18) >> 3) - ((data[7] & 0x20) >> 3); > input_report_rel(input, REL_WHEEL, rw); > input_report_key(input, BTN_TOOL_FINGER, 0xf0); > - input_report_abs(input, ABS_MISC, wacom->id[1]); > if (!prox) > wacom->id[1] = 0; > input_report_abs(input, ABS_MISC, wacom->id[1]); > input_event(input, EV_MSC, MSC_SERIAL, 0xf0); > + retval = 1; > } > - retval = 1; > break; > > > There more in that patch but just wanted to show the part about > ABS_MISC being removed. > > Here is my original email ton linuxwacom-devel to describe gist of > problem. It contains reference to why removing that above ABS_MISC > may have side affect of fixing graphire issue. > > http://sourceforge.net/mailarchive/message.php?msg_id=27202503 > > I prefer my patch I included in this thread alaready for its > correctness but I think above happens to make things squeak by. > > Chris > Looks like your patch works when applied to the ubuntu-natty git tree. Buttons continue to work flawlessly after pen enters and exits proximity. I haven't yet tested to see if your patch fixes the related bug I was seeing on my development box, but I'll get around to that soon(-ish). Jason --- Day xee-nee-svsh duu-'ushtlh-ts'it; nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it. Huu-chan xuu naa~-gha. ------------------------------------------------------------------------------ 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. http://p.sf.net/sfu/quest-sfdev2dev _______________________________________________ Linuxwacom-discuss mailing list Linuxwacom-discuss@... https://lists.sourceforge.net/lists/listinfo/linuxwacom-discuss |
|
|
Re: Graphire4 Pad Button freeze with 0.10.11.
by Jason G.
::
Rate this Message:
On Wed, Jun 1, 2011 at 3:53 PM, Jason Gerecke <killertofu@...> wrote:
> On Tue, May 31, 2011 at 12:43 PM, Chris Bagwell <chris@...> wrote: >> On Tue, May 31, 2011 at 1:28 PM, Jason Gerecke <killertofu@...> wrote: >>> On Sat, May 28, 2011 at 5:53 PM, Chris Bagwell <chris@...> wrote: >>>> On Sat, May 28, 2011 at 3:54 PM, Jason Gerecke <killertofu@...> wrote: >>>>> On Fri, May 27, 2011 at 9:11 PM, Chris Bagwell <chris@...> wrote: >>>>>> Hi Favux, >>>>>> >>>>>> For first bug report, it does sound same issue as I looked into a >>>>>> while back. The kernel driver is mistakenly telling userland that the >>>>>> PAD device has gone out of proximity when you use pen. From that >>>>>> point, buttons don't work. >>>>>> >>>>>> Something has changed in xf86-input-wacom that we must l trust kernel >>>>>> information more then we used to. My personal preference is to fix >>>>>> the kernel to give us good info instead of reverting back to old >>>>>> xf86-input-wacom behavior. >>>>>> >>>>>> Maybe when Ping gets back next month we can have some progress. Or >>>>>> hopefully we can find a user that doesn't mind hacking kernel drivers. >>>>>> I can give tons of guidance on patch to implement (its like 3 lines >>>>>> for simple solution) but ultimately I can't push forward much more >>>>>> since I don't have the device. >>>>>> >>>>>> For second bug report (X server crash), I've no idea. It sounds like >>>>>> its own issue. >>>>>> >>>>>> Chris >>>>>> >>>>> >>>>> Chris, I just happen to have a Graphire4 at home. If you have an idea >>>>> of where the bug may lie, I'd be happy to try patching up the kernel >>>>> code :) >>>>> >>>>> Jason >>>>> >>>> >>>> Cool. I've attached the patch I think that is needed. This is >>>> against Linus' git that was rebased at some random time in last month >>>> or two. >>>> >>>> Originally, I was going to give you a patch against input-wacom but it >>>> looks like that is different compared to upstream for graphire. >>>> Specifically, it is correctly setting MSC_SERIAL when switching over >>>> to pen. >>>> >>>> That means input-wacom may be working with graphire4. input-wacom is >>>> not ever sending BTN_TOOL_FINGER for some reason so if its not working >>>> then thats probably only change needed (add it back in to match >>>> kernel). >>>> >>>> Chris >>>> >>> >>> While I can confirm the bug under Ubuntu 11.04 64-bit >>> (2.6.38-8-generic), I can't under my 32-bit Arch Linux development >>> box. This was tested with the pre-installed "2.6.38-ARCH" kernel, as >>> well as the tarballs from kernel.org for 2.6.38.7 or 2.8.39 (with the >>> config from /proc/config used as the source). xf86-input-wacom was >>> from Git obviously :) >>> >> >> Strange. Must be distro's backporting patches. >> >>> There is a similar bug under these kernels (multiple presses to the >>> same pad button don't work while pen is in prox -- you either have to >>> press another button before the first works again, or take the pen out >>> of prox to press buttons repeatedly). >> >> Yeah, that sounds about right for this bug. When switching tools (PEN >> vs. PAD), we are not correctly changing serial # and that side affect >> can be seen a few different ways. >> >>> >>> I'll try setting up a build environment under my virtual Ubuntu box to >>> see what the official kernel sources do there. >> >> Since Graphire is generally stable, I look at git to see whats been >> changing. Here is immediately interesting one. Looks like a >> non-Tablet PC change snuck in this commit. >> >> commit ab687b18aa77aeda5472d9ea054bf92c45c49c0c >> Author: Ping Cheng <pingc@...> >> Date: Mon Apr 5 23:07:41 2010 -0700 >> >> Input: wacom - streamline 2-finger touch support >> >> Clean up 2-finger touch support. This still needs to be converted to >> proper multi-touch protocol. >> >> Signed-off-by: Ping Cheng <pingc@...> >> Signed-off-by: Dmitry Torokhov <dtor@...> >> >> diff --git a/drivers/input/tablet/wacom_wac.c b/drivers/input/tablet/wacom_wac.c >> index 950a81d..847fd01 100644 >> --- a/drivers/input/tablet/wacom_wac.c >> +++ b/drivers/input/tablet/wacom_wac.c >> @@ -236,13 +236,12 @@ static int wacom_graphire_irq(struct wacom_wac *wacom) >> rw = ((data[7] & 0x18) >> 3) - ((data[7] & 0x20) >> 3); >> input_report_rel(input, REL_WHEEL, rw); >> input_report_key(input, BTN_TOOL_FINGER, 0xf0); >> - input_report_abs(input, ABS_MISC, wacom->id[1]); >> if (!prox) >> wacom->id[1] = 0; >> input_report_abs(input, ABS_MISC, wacom->id[1]); >> input_event(input, EV_MSC, MSC_SERIAL, 0xf0); >> + retval = 1; >> } >> - retval = 1; >> break; >> >> >> There more in that patch but just wanted to show the part about >> ABS_MISC being removed. >> >> Here is my original email ton linuxwacom-devel to describe gist of >> problem. It contains reference to why removing that above ABS_MISC >> may have side affect of fixing graphire issue. >> >> http://sourceforge.net/mailarchive/message.php?msg_id=27202503 >> >> I prefer my patch I included in this thread alaready for its >> correctness but I think above happens to make things squeak by. >> >> Chris >> > > Looks like your patch works when applied to the ubuntu-natty git tree. > Buttons continue to work flawlessly after pen enters and exits > proximity. I haven't yet tested to see if your patch fixes the related > bug I was seeing on my development box, but I'll get around to that > soon(-ish). > > Jason > > --- > Day xee-nee-svsh duu-'ushtlh-ts'it; > nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it. > Huu-chan xuu naa~-gha. > Patch looks good on my Arch box with the kernel.org 2.6.38.7 release as well. Fixes the related bug I was experiencing. I assume Peter knows how to get this upstream? Jason --- Day xee-nee-svsh duu-'ushtlh-ts'it; nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it. Huu-chan xuu naa~-gha. ------------------------------------------------------------------------------ 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. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 _______________________________________________ Linuxwacom-discuss mailing list Linuxwacom-discuss@... https://lists.sourceforge.net/lists/listinfo/linuxwacom-discuss |
|
|
Re: Graphire4 Pad Button freeze with 0.10.11.
by Chris Bagwell
::
Rate this Message:
On Fri, Jun 3, 2011 at 10:48 AM, Jason Gerecke <killertofu@...> wrote:
> On Wed, Jun 1, 2011 at 3:53 PM, Jason Gerecke <killertofu@...> wrote: >> On Tue, May 31, 2011 at 12:43 PM, Chris Bagwell <chris@...> wrote: >>> On Tue, May 31, 2011 at 1:28 PM, Jason Gerecke <killertofu@...> wrote: >>>> On Sat, May 28, 2011 at 5:53 PM, Chris Bagwell <chris@...> wrote: >>>>> On Sat, May 28, 2011 at 3:54 PM, Jason Gerecke <killertofu@...> wrote: >>>>>> On Fri, May 27, 2011 at 9:11 PM, Chris Bagwell <chris@...> wrote: >>>>>>> Hi Favux, >>>>>>> >>>>>>> For first bug report, it does sound same issue as I looked into a >>>>>>> while back. The kernel driver is mistakenly telling userland that the >>>>>>> PAD device has gone out of proximity when you use pen. From that >>>>>>> point, buttons don't work. >>>>>>> >>>>>>> Something has changed in xf86-input-wacom that we must l trust kernel >>>>>>> information more then we used to. My personal preference is to fix >>>>>>> the kernel to give us good info instead of reverting back to old >>>>>>> xf86-input-wacom behavior. >>>>>>> >>>>>>> Maybe when Ping gets back next month we can have some progress. Or >>>>>>> hopefully we can find a user that doesn't mind hacking kernel drivers. >>>>>>> I can give tons of guidance on patch to implement (its like 3 lines >>>>>>> for simple solution) but ultimately I can't push forward much more >>>>>>> since I don't have the device. >>>>>>> >>>>>>> For second bug report (X server crash), I've no idea. It sounds like >>>>>>> its own issue. >>>>>>> >>>>>>> Chris >>>>>>> >>>>>> >>>>>> Chris, I just happen to have a Graphire4 at home. If you have an idea >>>>>> of where the bug may lie, I'd be happy to try patching up the kernel >>>>>> code :) >>>>>> >>>>>> Jason >>>>>> >>>>> >>>>> Cool. I've attached the patch I think that is needed. This is >>>>> against Linus' git that was rebased at some random time in last month >>>>> or two. >>>>> >>>>> Originally, I was going to give you a patch against input-wacom but it >>>>> looks like that is different compared to upstream for graphire. >>>>> Specifically, it is correctly setting MSC_SERIAL when switching over >>>>> to pen. >>>>> >>>>> That means input-wacom may be working with graphire4. input-wacom is >>>>> not ever sending BTN_TOOL_FINGER for some reason so if its not working >>>>> then thats probably only change needed (add it back in to match >>>>> kernel). >>>>> >>>>> Chris >>>>> >>>> >>>> While I can confirm the bug under Ubuntu 11.04 64-bit >>>> (2.6.38-8-generic), I can't under my 32-bit Arch Linux development >>>> box. This was tested with the pre-installed "2.6.38-ARCH" kernel, as >>>> well as the tarballs from kernel.org for 2.6.38.7 or 2.8.39 (with the >>>> config from /proc/config used as the source). xf86-input-wacom was >>>> from Git obviously :) >>>> >>> >>> Strange. Must be distro's backporting patches. >>> >>>> There is a similar bug under these kernels (multiple presses to the >>>> same pad button don't work while pen is in prox -- you either have to >>>> press another button before the first works again, or take the pen out >>>> of prox to press buttons repeatedly). >>> >>> Yeah, that sounds about right for this bug. When switching tools (PEN >>> vs. PAD), we are not correctly changing serial # and that side affect >>> can be seen a few different ways. >>> >>>> >>>> I'll try setting up a build environment under my virtual Ubuntu box to >>>> see what the official kernel sources do there. >>> >>> Since Graphire is generally stable, I look at git to see whats been >>> changing. Here is immediately interesting one. Looks like a >>> non-Tablet PC change snuck in this commit. >>> >>> commit ab687b18aa77aeda5472d9ea054bf92c45c49c0c >>> Author: Ping Cheng <pingc@...> >>> Date: Mon Apr 5 23:07:41 2010 -0700 >>> >>> Input: wacom - streamline 2-finger touch support >>> >>> Clean up 2-finger touch support. This still needs to be converted to >>> proper multi-touch protocol. >>> >>> Signed-off-by: Ping Cheng <pingc@...> >>> Signed-off-by: Dmitry Torokhov <dtor@...> >>> >>> diff --git a/drivers/input/tablet/wacom_wac.c b/drivers/input/tablet/wacom_wac.c >>> index 950a81d..847fd01 100644 >>> --- a/drivers/input/tablet/wacom_wac.c >>> +++ b/drivers/input/tablet/wacom_wac.c >>> @@ -236,13 +236,12 @@ static int wacom_graphire_irq(struct wacom_wac *wacom) >>> rw = ((data[7] & 0x18) >> 3) - ((data[7] & 0x20) >> 3); >>> input_report_rel(input, REL_WHEEL, rw); >>> input_report_key(input, BTN_TOOL_FINGER, 0xf0); >>> - input_report_abs(input, ABS_MISC, wacom->id[1]); >>> if (!prox) >>> wacom->id[1] = 0; >>> input_report_abs(input, ABS_MISC, wacom->id[1]); >>> input_event(input, EV_MSC, MSC_SERIAL, 0xf0); >>> + retval = 1; >>> } >>> - retval = 1; >>> break; >>> >>> >>> There more in that patch but just wanted to show the part about >>> ABS_MISC being removed. >>> >>> Here is my original email ton linuxwacom-devel to describe gist of >>> problem. It contains reference to why removing that above ABS_MISC >>> may have side affect of fixing graphire issue. >>> >>> http://sourceforge.net/mailarchive/message.php?msg_id=27202503 >>> >>> I prefer my patch I included in this thread alaready for its >>> correctness but I think above happens to make things squeak by. >>> >>> Chris >>> >> >> Looks like your patch works when applied to the ubuntu-natty git tree. >> Buttons continue to work flawlessly after pen enters and exits >> proximity. I haven't yet tested to see if your patch fixes the related >> bug I was seeing on my development box, but I'll get around to that >> soon(-ish). >> >> Jason >> >> --- >> Day xee-nee-svsh duu-'ushtlh-ts'it; >> nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it. >> Huu-chan xuu naa~-gha. >> > > Patch looks good on my Arch box with the kernel.org 2.6.38.7 release > as well. Fixes the related bug I was experiencing. > > I assume Peter knows how to get this upstream? > I can help with that part. Its just a matter of sending the patch in to linux-input mailing list as a real git patch against their tree. If you want, you can give it a shot submitting this kernel patch and put both our Signed-off-by:'s on it or if you you prefer I can send the patch in with your Tested-by: attached to it. Just let me know. Chris ------------------------------------------------------------------------------ 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. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 _______________________________________________ Linuxwacom-discuss mailing list Linuxwacom-discuss@... https://lists.sourceforge.net/lists/listinfo/linuxwacom-discuss |
|
|
Re: Graphire4 Pad Button freeze with 0.10.11.
by Jason G.
::
Rate this Message:
On Fri, Jun 3, 2011 at 10:36 AM, Chris Bagwell <chris@...> wrote:
> On Fri, Jun 3, 2011 at 10:48 AM, Jason Gerecke <killertofu@...> wrote: >> On Wed, Jun 1, 2011 at 3:53 PM, Jason Gerecke <killertofu@...> wrote: >>> On Tue, May 31, 2011 at 12:43 PM, Chris Bagwell <chris@...> wrote: >>>> On Tue, May 31, 2011 at 1:28 PM, Jason Gerecke <killertofu@...> wrote: >>>>> On Sat, May 28, 2011 at 5:53 PM, Chris Bagwell <chris@...> wrote: >>>>>> On Sat, May 28, 2011 at 3:54 PM, Jason Gerecke <killertofu@...> wrote: >>>>>>> On Fri, May 27, 2011 at 9:11 PM, Chris Bagwell <chris@...> wrote: >>>>>>>> Hi Favux, >>>>>>>> >>>>>>>> For first bug report, it does sound same issue as I looked into a >>>>>>>> while back. The kernel driver is mistakenly telling userland that the >>>>>>>> PAD device has gone out of proximity when you use pen. From that >>>>>>>> point, buttons don't work. >>>>>>>> >>>>>>>> Something has changed in xf86-input-wacom that we must l trust kernel >>>>>>>> information more then we used to. My personal preference is to fix >>>>>>>> the kernel to give us good info instead of reverting back to old >>>>>>>> xf86-input-wacom behavior. >>>>>>>> >>>>>>>> Maybe when Ping gets back next month we can have some progress. Or >>>>>>>> hopefully we can find a user that doesn't mind hacking kernel drivers. >>>>>>>> I can give tons of guidance on patch to implement (its like 3 lines >>>>>>>> for simple solution) but ultimately I can't push forward much more >>>>>>>> since I don't have the device. >>>>>>>> >>>>>>>> For second bug report (X server crash), I've no idea. It sounds like >>>>>>>> its own issue. >>>>>>>> >>>>>>>> Chris >>>>>>>> >>>>>>> >>>>>>> Chris, I just happen to have a Graphire4 at home. If you have an idea >>>>>>> of where the bug may lie, I'd be happy to try patching up the kernel >>>>>>> code :) >>>>>>> >>>>>>> Jason >>>>>>> >>>>>> >>>>>> Cool. I've attached the patch I think that is needed. This is >>>>>> against Linus' git that was rebased at some random time in last month >>>>>> or two. >>>>>> >>>>>> Originally, I was going to give you a patch against input-wacom but it >>>>>> looks like that is different compared to upstream for graphire. >>>>>> Specifically, it is correctly setting MSC_SERIAL when switching over >>>>>> to pen. >>>>>> >>>>>> That means input-wacom may be working with graphire4. input-wacom is >>>>>> not ever sending BTN_TOOL_FINGER for some reason so if its not working >>>>>> then thats probably only change needed (add it back in to match >>>>>> kernel). >>>>>> >>>>>> Chris >>>>>> >>>>> >>>>> While I can confirm the bug under Ubuntu 11.04 64-bit >>>>> (2.6.38-8-generic), I can't under my 32-bit Arch Linux development >>>>> box. This was tested with the pre-installed "2.6.38-ARCH" kernel, as >>>>> well as the tarballs from kernel.org for 2.6.38.7 or 2.8.39 (with the >>>>> config from /proc/config used as the source). xf86-input-wacom was >>>>> from Git obviously :) >>>>> >>>> >>>> Strange. Must be distro's backporting patches. >>>> >>>>> There is a similar bug under these kernels (multiple presses to the >>>>> same pad button don't work while pen is in prox -- you either have to >>>>> press another button before the first works again, or take the pen out >>>>> of prox to press buttons repeatedly). >>>> >>>> Yeah, that sounds about right for this bug. When switching tools (PEN >>>> vs. PAD), we are not correctly changing serial # and that side affect >>>> can be seen a few different ways. >>>> >>>>> >>>>> I'll try setting up a build environment under my virtual Ubuntu box to >>>>> see what the official kernel sources do there. >>>> >>>> Since Graphire is generally stable, I look at git to see whats been >>>> changing. Here is immediately interesting one. Looks like a >>>> non-Tablet PC change snuck in this commit. >>>> >>>> commit ab687b18aa77aeda5472d9ea054bf92c45c49c0c >>>> Author: Ping Cheng <pingc@...> >>>> Date: Mon Apr 5 23:07:41 2010 -0700 >>>> >>>> Input: wacom - streamline 2-finger touch support >>>> >>>> Clean up 2-finger touch support. This still needs to be converted to >>>> proper multi-touch protocol. >>>> >>>> Signed-off-by: Ping Cheng <pingc@...> >>>> Signed-off-by: Dmitry Torokhov <dtor@...> >>>> >>>> diff --git a/drivers/input/tablet/wacom_wac.c b/drivers/input/tablet/wacom_wac.c >>>> index 950a81d..847fd01 100644 >>>> --- a/drivers/input/tablet/wacom_wac.c >>>> +++ b/drivers/input/tablet/wacom_wac.c >>>> @@ -236,13 +236,12 @@ static int wacom_graphire_irq(struct wacom_wac *wacom) >>>> rw = ((data[7] & 0x18) >> 3) - ((data[7] & 0x20) >> 3); >>>> input_report_rel(input, REL_WHEEL, rw); >>>> input_report_key(input, BTN_TOOL_FINGER, 0xf0); >>>> - input_report_abs(input, ABS_MISC, wacom->id[1]); >>>> if (!prox) >>>> wacom->id[1] = 0; >>>> input_report_abs(input, ABS_MISC, wacom->id[1]); >>>> input_event(input, EV_MSC, MSC_SERIAL, 0xf0); >>>> + retval = 1; >>>> } >>>> - retval = 1; >>>> break; >>>> >>>> >>>> There more in that patch but just wanted to show the part about >>>> ABS_MISC being removed. >>>> >>>> Here is my original email ton linuxwacom-devel to describe gist of >>>> problem. It contains reference to why removing that above ABS_MISC >>>> may have side affect of fixing graphire issue. >>>> >>>> http://sourceforge.net/mailarchive/message.php?msg_id=27202503 >>>> >>>> I prefer my patch I included in this thread alaready for its >>>> correctness but I think above happens to make things squeak by. >>>> >>>> Chris >>>> >>> >>> Looks like your patch works when applied to the ubuntu-natty git tree. >>> Buttons continue to work flawlessly after pen enters and exits >>> proximity. I haven't yet tested to see if your patch fixes the related >>> bug I was seeing on my development box, but I'll get around to that >>> soon(-ish). >>> >>> Jason >>> >>> --- >>> Day xee-nee-svsh duu-'ushtlh-ts'it; >>> nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it. >>> Huu-chan xuu naa~-gha. >>> >> >> Patch looks good on my Arch box with the kernel.org 2.6.38.7 release >> as well. Fixes the related bug I was experiencing. >> >> I assume Peter knows how to get this upstream? >> > > I can help with that part. Its just a matter of sending the patch in > to linux-input mailing list as a real git patch against their tree. > > If you want, you can give it a shot submitting this kernel patch and > put both our Signed-off-by:'s on it or if you you prefer I can send > the patch in with your Tested-by: attached to it. > > Just let me know. > > Chris > Sorry about the delay -- things have been busy over here. Go ahead and submit the patch with my Tested-by, since I'm not sure I'll be able to get around to doing it myself any time soon. Jason --- Day xee-nee-svsh duu-'ushtlh-ts'it; nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it. Huu-chan xuu naa~-gha. ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Linuxwacom-discuss mailing list Linuxwacom-discuss@... https://lists.sourceforge.net/lists/listinfo/linuxwacom-discuss |
|
|
Re: Graphire4 Pad Button freeze with 0.10.11.
by Ping Cheng-2
::
Rate this Message:
On Thu, Jun 9, 2011 at 8:56 AM, Jason Gerecke <killertofu@...> wrote:
I am back. But I haven't got the time to look into the code yet. Please give me a day or so to read and test the patch. We may be able to combine the fix and an update together. Thank you, Chris, for the support. Ping ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Linuxwacom-discuss mailing list Linuxwacom-discuss@... https://lists.sourceforge.net/lists/listinfo/linuxwacom-discuss |
ConnorCarney_Graphire4_pad-button.txt.zip (5K) | Free embeddable forum powered by Nabble | Forum Help |
