[PATCH] Input: add HP Compaq 2710p to 'noloop' table
Jiri Kosina
to not report properly to AUX_LOOP command time-to-time, causing
non-working keyboard due to messed up i8042.
Signed-off-by: Jiri Kosina <jko...@suse.cz>
---
The relevant i8042.debug output from the failing case is
drivers/input/serio/i8042.c: 20 -> i8042 (command) [0]
drivers/input/serio/i8042.c: 65 <- i8042 (return) [0]
drivers/input/serio/i8042.c: 60 -> i8042 (command) [0]
drivers/input/serio/i8042.c: 74 -> i8042 (parameter) [0]
drivers/input/serio/i8042.c: d3 -> i8042 (command) [0]
drivers/input/serio/i8042.c: 5a -> i8042 (parameter) [0]
drivers/input/serio/i8042.c: 5a <- i8042 (return) [0]
drivers/input/serio/i8042.c: a7 -> i8042 (command) [0]
drivers/input/serio/i8042.c: 20 -> i8042 (command) [0]
drivers/input/serio/i8042.c: 74 <- i8042 (return) [0]
drivers/input/serio/i8042.c: a8 -> i8042 (command) [0]
drivers/input/serio/i8042.c: 20 -> i8042 (command) [0]
drivers/input/serio/i8042.c: 54 <- i8042 (return) [1]
drivers/input/serio/i8042.c: 60 -> i8042 (command) [1]
drivers/input/serio/i8042.c: 56 -> i8042 (parameter) [1]
drivers/input/serio/i8042.c: d3 -> i8042 (command) [1]
drivers/input/serio/i8042.c: a5 -> i8042 (parameter) [1]
drivers/input/serio/i8042.c: 60 -> i8042 (command) [1]
drivers/input/serio/i8042.c: 74 -> i8042 (parameter) [1]
drivers/input/serio/i8042.c: d3 -> i8042 (command) [1]
drivers/input/serio/i8042.c: f0 -> i8042 (parameter) [1]
drivers/input/serio/i8042.c: 00 <- i8042 (return) [1]
drivers/input/serio/i8042.c: 60 -> i8042 (command) [1]
drivers/input/serio/i8042.c: 56 -> i8042 (parameter) [1]
drivers/input/serio/i8042.c: 60 -> i8042 (command) [1]
drivers/input/serio/i8042.c: 47 -> i8042 (parameter) [1]
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
drivers/input/serio/i8042.c: f2 -> i8042 (kbd-data) [1]
...
drivers/input/serio/i8042.c: ed -> i8042 (kbd-data) [52]
drivers/input/serio/i8042-x86ia64io.h | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/input/serio/i8042-x86ia64io.h b/drivers/input/serio/i8042-x86ia64io.h
index ead0494..d2c7cf0 100644
--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -172,6 +172,13 @@ static const struct dmi_system_id __initconst i8042_dmi_noloop_table[] = {
DMI_MATCH(DMI_PRODUCT_VERSION, "Rev 1"),
},
},
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "HP Compaq 2710p (#ABD)"),
+ DMI_MATCH(DMI_PRODUCT_VERSION, "F.14"),
+ },
+ },
{ }
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Matthew Garrett
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "HP Compaq 2710p (#ABD)"),
> + DMI_MATCH(DMI_PRODUCT_VERSION, "F.14"),
Is this really the only BIOS version affected? It seems unlikely. It's
also a pretty good indication that we're doing something wrong.
--
Matthew Garrett | mj...@srcf.ucam.org
Jiri Kosina
> On Wed, Apr 14, 2010 at 02:16:25PM +0200, Jiri Kosina wrote:
> > + .matches = {
> > + DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
> > + DMI_MATCH(DMI_PRODUCT_NAME, "HP Compaq 2710p (#ABD)"),
> > + DMI_MATCH(DMI_PRODUCT_VERSION, "F.14"),
>
> Is this really the only BIOS version affected? It seems unlikely.
I don't know, it's the only one I have received the report against (I
don't own the machine myself).
> It's also a pretty good indication that we're doing something wrong.
What do you mean exactly?
Sending AUX_LOOP is valid thing to do with i8042 controller. If it causes
such confusion that the controller doesn't function properly any more,
it's clearly broken.
--
Jiri Kosina
SUSE Labs, Novell Inc.
Matthew Garrett
> Sending AUX_LOOP is valid thing to do with i8042 controller. If it causes
> such confusion that the controller doesn't function properly any more,
> it's clearly broken.
Does Windows send AUX_LOOP? If so, why does it not break the device? If
not, how does it obtain the same level of functionality?
--
Matthew Garrett | mj...@srcf.ucam.org
Alan Cox
Jiri Kosina <jko...@suse.cz> wrote:
> On Wed, 14 Apr 2010, Matthew Garrett wrote:
>
> > On Wed, Apr 14, 2010 at 02:16:25PM +0200, Jiri Kosina wrote:
> > > + .matches = {
> > > + DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
> > > + DMI_MATCH(DMI_PRODUCT_NAME, "HP Compaq 2710p (#ABD)"),
> > > + DMI_MATCH(DMI_PRODUCT_VERSION, "F.14"),
> >
> > Is this really the only BIOS version affected? It seems unlikely.
>
> I don't know, it's the only one I have received the report against (I
> don't own the machine myself).
>
> > It's also a pretty good indication that we're doing something wrong.
>
> What do you mean exactly?
>
> Sending AUX_LOOP is valid thing to do with i8042 controller. If it causes
> such confusion that the controller doesn't function properly any more,
> it's clearly broken.
You are assuming there is anything resembling an i8042 in the system.
There may not be, and even if there is there may be SMM code running in
front of it.
It's not really that unlikely that an AUX handling bug exists and only on
one BIOS version given we've seen things as neat as i8042 emulation that
only works on CPU #0 8)
Alan
Matthew Garrett
> It's not really that unlikely that an AUX handling bug exists and only on
> one BIOS version given we've seen things as neat as i8042 emulation that
> only works on CPU #0 8)
Doubtless, but on the other hand these machines work with versions of
Windows that were released well before them, so if there's a difference
in behaviour then we have a bug regardless of what the spec says.
--
Matthew Garrett | mj...@srcf.ucam.org
Matthew Garrett
> I think in this case you are in cloud cuckoo land. Windows doesn't
> autoprobe all these mouse types, and some years of careful
> experimentation seems to indicate the best you can do is select which
> devices break without blacklists.
Blacklists which have to vary based on BIOS version? It's pretty obvious
that this doesn't scale.
Alan Cox
Matthew Garrett <mj...@srcf.ucam.org> wrote:
> On Wed, Apr 14, 2010 at 01:53:50PM +0100, Alan Cox wrote:
>
> > It's not really that unlikely that an AUX handling bug exists and only on
> > one BIOS version given we've seen things as neat as i8042 emulation that
> > only works on CPU #0 8)
>
> Doubtless, but on the other hand these machines work with versions of
> Windows that were released well before them, so if there's a difference
> in behaviour then we have a bug regardless of what the spec says.
I think in this case you are in cloud cuckoo land. Windows doesn't
autoprobe all these mouse types, and some years of careful
experimentation seems to indicate the best you can do is select which
devices break without blacklists.
--
Matthew Garrett
> Ask vendors, who are shipping specialized windows drivers for their mice,
> to be please so kind and always include a linux driver as well, and nuke
> all the probing logic from in-kernel driver?
Well, in this case we know that there's a synaptics (it's in ACPIPNP)
and we know that an internal synaptics places pretty heavy constraints
on what else is going to be attached to the machine.
Jiri Kosina
> > I think in this case you are in cloud cuckoo land. Windows doesn't
> > autoprobe all these mouse types, and some years of careful
> > experimentation seems to indicate the best you can do is select which
> > devices break without blacklists.
>
> Blacklists which have to vary based on BIOS version? It's pretty obvious
> that this doesn't scale.
... and your proposal is?
Ask vendors, who are shipping specialized windows drivers for their mice,
to be please so kind and always include a linux driver as well, and nuke
all the probing logic from in-kernel driver?
--
Jiri Kosina
SUSE Labs, Novell Inc.
Dmitry Torokhov
On Wed, Apr 14, 2010 at 02:16:25PM +0200, Jiri Kosina wrote:
> Add HP Compaq 2710p to 'noloop' table. Otherwsie this machine is reported
> to not report properly to AUX_LOOP command time-to-time, causing
> non-working keyboard due to messed up i8042.
>
What is the chassis type for the box in DMI? I am curious why it isn't
caought up by the generic "portable" test...
Thanks.
--
Dmitry
Dmitry Torokhov
> On Wed, Apr 14, 2010 at 03:40:14PM +0200, Jiri Kosina wrote:
>
> > Ask vendors, who are shipping specialized windows drivers for their mice,
> > to be please so kind and always include a linux driver as well, and nuke
> > all the probing logic from in-kernel driver?
>
> Well, in this case we know that there's a synaptics (it's in ACPIPNP)
> and we know that an internal synaptics places pretty heavy constraints
> on what else is going to be attached to the machine.
>
As in... anything? Many boxes still have external PS/2 ports that can
have pretty much any type of mouse attached. Especially those HPs that
have active multiplexor.
--
Dmitry
Jiri Kosina
> > Add HP Compaq 2710p to 'noloop' table. Otherwsie this machine is reported
> > to not report properly to AUX_LOOP command time-to-time, causing
> > non-working keyboard due to messed up i8042.
> >
>
> What is the chassis type for the box in DMI? I am curious why it isn't
> caought up by the generic "portable" test...
Hmm, you are right, I completely forgot that we are now completely
bypassing AUX IRQ delivery on Portable/Laptop/(Sub-)Notebook chasis types.
I was going through my older patchqueue and flushing it, and this one
slipped through, as it is apparently not necessary for current mainline
(the machine in question has chasis type "Notebook"), but only for older
kernels.
Sorry for the fuss.
Thanks,
--
Jiri Kosina
SUSE Labs, Novell Inc.
Dmitry Torokhov
> On Wed, 14 Apr 2010, Dmitry Torokhov wrote:
>
> > > Add HP Compaq 2710p to 'noloop' table. Otherwsie this machine is reported
> > > to not report properly to AUX_LOOP command time-to-time, causing
> > > non-working keyboard due to messed up i8042.
> > >
> >
> > What is the chassis type for the box in DMI? I am curious why it isn't
> > caought up by the generic "portable" test...
>
> Hmm, you are right, I completely forgot that we are now completely
> bypassing AUX IRQ delivery on Portable/Laptop/(Sub-)Notebook chasis types.
>
> I was going through my older patchqueue and flushing it, and this one
> slipped through, as it is apparently not necessary for current mainline
> (the machine in question has chasis type "Notebook"), but only for older
> kernels.
>
OK, thanks.
--
Dmitry