Hello,
My D610 ALPS Glide Point is unresponsive with 2.6.21-mm1 patch.
No problem noticed with 2.6.21.
The culprit seems to be git-input. I have applied 2.6.21-mm1 on top of 2.6.21
and then removed git-input patch. It is ok since then.
>From what i can see, no interrupt is raised from the GlidePoint with git-input
applied. IRQ count 12 does not increase. It is when using the touchpad.
CPU0
0: 160 IO-APIC-edge timer
1: 935 IO-APIC-edge i8042
7: 0 IO-APIC-edge parport0
8: 1 IO-APIC-edge rtc
9: 2 IO-APIC-fasteoi acpi
=> 12: 114 IO-APIC-edge i8042 <=
14: 3223 IO-APIC-edge libata
15: 5 IO-APIC-edge libata
16: 0 IO-APIC-fasteoi uhci_hcd:usb1, ehci_hcd:usb5, Intel ICH6
17: 1 IO-APIC-fasteoi uhci_hcd:usb2, ipw2200, Intel ICH6 Modem
18: 0 IO-APIC-fasteoi uhci_hcd:usb3
19: 1 IO-APIC-fasteoi uhci_hcd:usb4, yenta
NMI: 0
LOC: 4051
ERR: 0
MIS: 0
I have also tried to disable the ALPS driver in the .config file. IRQ 12 are
then raised when using the Glide Point. X refuses to start.
Any idea?
Remi Colinet
On Thu, 10 May 2007 15:05:25 +0200
Remi Colinet <[email protected]> wrote:
> My D610 ALPS Glide Point is unresponsive with 2.6.21-mm1 patch.
> No problem noticed with 2.6.21.
>
> The culprit seems to be git-input. I have applied 2.6.21-mm1 on top of 2.6.21
> and then removed git-input patch. It is ok since then.
>
> >From what i can see, no interrupt is raised from the GlidePoint with git-input
> applied. IRQ count 12 does not increase. It is when using the touchpad.
>
> CPU0
> 0: 160 IO-APIC-edge timer
> 1: 935 IO-APIC-edge i8042
> 7: 0 IO-APIC-edge parport0
> 8: 1 IO-APIC-edge rtc
> 9: 2 IO-APIC-fasteoi acpi
> => 12: 114 IO-APIC-edge i8042 <=
> 14: 3223 IO-APIC-edge libata
> 15: 5 IO-APIC-edge libata
> 16: 0 IO-APIC-fasteoi uhci_hcd:usb1, ehci_hcd:usb5, Intel ICH6
> 17: 1 IO-APIC-fasteoi uhci_hcd:usb2, ipw2200, Intel ICH6 Modem
> 18: 0 IO-APIC-fasteoi uhci_hcd:usb3
> 19: 1 IO-APIC-fasteoi uhci_hcd:usb4, yenta
> NMI: 0
> LOC: 4051
> ERR: 0
> MIS: 0
>
> I have also tried to disable the ALPS driver in the .config file. IRQ 12 are
> then raised when using the Glide Point. X refuses to start.
>
Are you able to test 2.6.21-mm2?
Thanks.
Hi Remi,
On Thursday 10 May 2007 21:50, Andrew Morton wrote:
> On Thu, 10 May 2007 15:05:25 +0200
> Remi Colinet <[email protected]> wrote:
>
> > My D610 ALPS Glide Point is unresponsive with 2.6.21-mm1 patch.
> > No problem noticed with 2.6.21.
> >
> > The culprit seems to be git-input. I have applied 2.6.21-mm1 on top of 2.6.21
> > and then removed git-input patch. It is ok since then.
Have you tried any other -mm? Also, does it help if you stick
ps2_command(&psmouse->ps2dev, NULL, PSMOUSE_CMD_SETSTREAM);
at the very beginning of psmouse_initialize() in
drivers/input/mouse/psmouse-base.c?
--
Dmitry
Selon Andrew Morton <[email protected]>:
> On Thu, 10 May 2007 15:05:25 +0200
> Remi Colinet <[email protected]> wrote:
>
> > My D610 ALPS Glide Point is unresponsive with 2.6.21-mm1 patch.
> > No problem noticed with 2.6.21.
> >
> > The culprit seems to be git-input. I have applied 2.6.21-mm1 on top of
> 2.6.21
> > and then removed git-input patch. It is ok since then.
> >
> > >From what i can see, no interrupt is raised from the GlidePoint with
> git-input
> > applied. IRQ count 12 does not increase. It is when using the touchpad.
> >
> > CPU0
> > 0: 160 IO-APIC-edge timer
> > 1: 935 IO-APIC-edge i8042
> > 7: 0 IO-APIC-edge parport0
> > 8: 1 IO-APIC-edge rtc
> > 9: 2 IO-APIC-fasteoi acpi
> > => 12: 114 IO-APIC-edge i8042 <=
> > 14: 3223 IO-APIC-edge libata
> > 15: 5 IO-APIC-edge libata
> > 16: 0 IO-APIC-fasteoi uhci_hcd:usb1, ehci_hcd:usb5, Intel
> ICH6
> > 17: 1 IO-APIC-fasteoi uhci_hcd:usb2, ipw2200, Intel ICH6
> Modem
> > 18: 0 IO-APIC-fasteoi uhci_hcd:usb3
> > 19: 1 IO-APIC-fasteoi uhci_hcd:usb4, yenta
> > NMI: 0
> > LOC: 4051
> > ERR: 0
> > MIS: 0
> >
> > I have also tried to disable the ALPS driver in the .config file. IRQ 12
> are
> > then raised when using the Glide Point. X refuses to start.
> >
>
> Are you able to test 2.6.21-mm2?
>
>
I have tried with the lastest mm broken-out snapshot, i.e 2.6.21-mm3.
The GlidePoint is still unresponsive.
2.6.21-git13 works fine with the GlidePoint.
So I'am bisecting 2.6.21-mm3. It works just with the origin.patch applied.
Thanks,
Remi Colinet
Selon Dmitry Torokhov <[email protected]>:
> Hi Remi,
>
> On Thursday 10 May 2007 21:50, Andrew Morton wrote:
> > On Thu, 10 May 2007 15:05:25 +0200
> > Remi Colinet <[email protected]> wrote:
> >
> > > My D610 ALPS Glide Point is unresponsive with 2.6.21-mm1 patch.
> > > No problem noticed with 2.6.21.
> > >
> > > The culprit seems to be git-input. I have applied 2.6.21-mm1 on top of
> 2.6.21
> > > and then removed git-input patch. It is ok since then.
>
> Have you tried any other -mm? Also, does it help if you stick
>
Tried 2.6.21-mm3. The GlidePoint is still unresponsive.
> ps2_command(&psmouse->ps2dev, NULL, PSMOUSE_CMD_SETSTREAM);
>
> at the very beginning of psmouse_initialize() in
> drivers/input/mouse/psmouse-base.c?
>
Going to try it ...
In fact, I already added the following line at the begining of each function in
drivers/input/mouse/alps.c
printk(KERN_ERR "start of function ...\n");
But no message is displayed when using the Glide Point. Interrupt are not
raised. The alps driver is not called by the i8042 handler.
Remi Colinet
> --
> Dmitry
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
And Dmitry Torokhov writes:
> Have you tried any other -mm? Also, does it help if you stick
> ps2_command(&psmouse->ps2dev, NULL, PSMOUSE_CMD_SETSTREAM);
> at the very beginning of psmouse_initialize() in
> drivers/input/mouse/psmouse-base.c?
Seems to fix it for me on a D620.
Bisecting on mainline gave commit
f42649e84831efc69d5f621f1c36a39b4e384a99 (Input: ALPS - handle
errors from input_register_device()) as the place where the
trackpoint half stopped working. I don't necessarily believe it,
unless the psmouse_reset on failure caused problems without
logging anything.
Jason
On Saturday 12 May 2007 23:58, Jason Riedy wrote:
> And Dmitry Torokhov writes:
> > Have you tried any other -mm? Also, does it help if you stick
> > ps2_command(&psmouse->ps2dev, NULL, PSMOUSE_CMD_SETSTREAM);
> > at the very beginning of psmouse_initialize() in
> > drivers/input/mouse/psmouse-base.c?
>
> Seems to fix it for me on a D620.
>
Ok, thanks.
> Bisecting on mainline gave commit
> f42649e84831efc69d5f621f1c36a39b4e384a99 (Input: ALPS - handle
> errors from input_register_device()) as the place where the
> trackpoint half stopped working. I don't necessarily believe it,
> unless the psmouse_reset on failure caused problems without
> logging anything.
>
I don't think so. Could you please try the patch below? Thanks!
--
Dmitry
Input: ALPS - force stream mode
ALPS appears to need SETSTREAM command after reset, otherwise it
does not produce any data. Now that we do not request stream mode
by default individual drivers need to take care of it.
Signed-off-by: Dmitry Torokhov <[email protected]>
---
drivers/input/mouse/alps.c | 55 +++++++++++++++++++++++----------------------
1 files changed, 29 insertions(+), 26 deletions(-)
Index: work/drivers/input/mouse/alps.c
===================================================================
--- work.orig/drivers/input/mouse/alps.c
+++ work/drivers/input/mouse/alps.c
@@ -251,11 +251,15 @@ static const struct alps_model_info *alp
dbg("E7 report: %2.2x %2.2x %2.2x", param[0], param[1], param[2]);
- for (i = 0; i < ARRAY_SIZE(rates) && param[2] != rates[i]; i++);
- *version = (param[0] << 8) | (param[1] << 4) | i;
+ if (version) {
+ for (i = 0; i < ARRAY_SIZE(rates) && param[2] != rates[i]; i++)
+ /* empty */;
+ *version = (param[0] << 8) | (param[1] << 4) | i;
+ }
for (i = 0; i < ARRAY_SIZE(alps_model_data); i++)
- if (!memcmp(param, alps_model_data[i].signature, sizeof(alps_model_data[i].signature)))
+ if (!memcmp(param, alps_model_data[i].signature,
+ sizeof(alps_model_data[i].signature)))
return alps_model_data + i;
return NULL;
@@ -380,32 +384,46 @@ static int alps_poll(struct psmouse *psm
return 0;
}
-static int alps_reconnect(struct psmouse *psmouse)
+static int alps_hw_init(struct psmouse *psmouse, int *version)
{
struct alps_data *priv = psmouse->private;
- int version;
-
- psmouse_reset(psmouse);
- if (!(priv->i = alps_get_model(psmouse, &version)))
+ priv->i = alps_get_model(psmouse, version);
+ if (!priv->i)
return -1;
if ((priv->i->flags & ALPS_PASS) && alps_passthrough_mode(psmouse, 1))
return -1;
if (alps_tap_mode(psmouse, 1)) {
- printk(KERN_WARNING "alps.c: Failed to reenable hardware tapping\n");
+ printk(KERN_WARNING "alps.c: Failed to enable hardware tapping\n");
return -1;
}
if (alps_absolute_mode(psmouse)) {
- printk(KERN_ERR "alps.c: Failed to reenable absolute mode\n");
+ printk(KERN_ERR "alps.c: Failed to enable absolute mode\n");
return -1;
}
if ((priv->i->flags & ALPS_PASS) && alps_passthrough_mode(psmouse, 0))
return -1;
+ /* ALPS needs stream mode, otherwise it won't report any data */
+ if (ps2_command(&psmouse->ps2dev, NULL, PSMOUSE_CMD_SETSTREAM)) {
+ printk(KERN_ERR "alps.c: Failed to enable stream mode\n");
+ return -1;
+ }
+
+ return 0;
+}
+
+static int alps_reconnect(struct psmouse *psmouse)
+{
+ psmouse_reset(psmouse);
+
+ if (alps_hw_init(psmouse, NULL))
+ return -1;
+
return 0;
}
@@ -431,22 +449,7 @@ int alps_init(struct psmouse *psmouse)
priv->dev2 = dev2;
- priv->i = alps_get_model(psmouse, &version);
- if (!priv->i)
- goto init_fail;
-
- if ((priv->i->flags & ALPS_PASS) && alps_passthrough_mode(psmouse, 1))
- goto init_fail;
-
- if (alps_tap_mode(psmouse, 1))
- printk(KERN_WARNING "alps.c: Failed to enable hardware tapping\n");
-
- if (alps_absolute_mode(psmouse)) {
- printk(KERN_ERR "alps.c: Failed to enable absolute mode\n");
- goto init_fail;
- }
-
- if ((priv->i->flags & ALPS_PASS) && alps_passthrough_mode(psmouse, 0))
+ if (alps_hw_init(psmouse, &version))
goto init_fail;
dev1->evbit[LONG(EV_KEY)] |= BIT(EV_KEY);
And Dmitry Torokhov writes:
> I don't think so. Could you please try the patch below? Thanks!
The appended patch on top of yours fixes the too-early access of
psmouse->private. I don't know the expected lifetime of
psmouse->private, so I chickened out of simply assigning priv
earlier.
BTW, why do you pass psmouse down through the initializations
rather than ps2dev and private?
Jason, using git's index, dammit...
diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
index 2aeb299..990d2a5 100644
--- a/drivers/input/mouse/alps.c
+++ b/drivers/input/mouse/alps.c
@@ -384,10 +384,9 @@ static int alps_poll(struct psmouse *psmouse)
return 0;
}
-static int alps_hw_init(struct psmouse *psmouse, int *version)
+static int alps_hw_init(struct psmouse *psmouse, struct alps_data *priv,
+ int *version)
{
- struct alps_data *priv = psmouse->private;
-
priv->i = alps_get_model(psmouse, version);
if (!priv->i)
return -1;
@@ -421,7 +420,7 @@ static int alps_reconnect(struct psmouse *psmouse)
{
psmouse_reset(psmouse);
- if (alps_hw_init(psmouse, NULL))
+ if (alps_hw_init(psmouse, (struct alps_data *)psmouse->private, NULL))
return -1;
return 0;
@@ -449,7 +448,7 @@ int alps_init(struct psmouse *psmouse)
priv->dev2 = dev2;
- if (alps_hw_init(psmouse, &version))
+ if (alps_hw_init(psmouse, priv, &version))
goto init_fail;
dev1->evbit[LONG(EV_KEY)] |= BIT(EV_KEY);