When testing Moblin on various netbooks, we've got reports that many
MSI Wind clones need the i8042 reset quirks for the keyboard and/or
touchpad's proper function.
Signed-off-by: Yan Li <[email protected]>
---
drivers/input/serio/i8042-x86ia64io.h | 28 ++++++++++++++++++++++++++++
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/drivers/input/serio/i8042-x86ia64io.h b/drivers/input/serio/i8042-x86ia64io.h
index fb8a3cd..924e8ed 100644
--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -392,6 +392,34 @@ static struct dmi_system_id __initdata i8042_dmi_reset_table[] = {
DMI_MATCH(DMI_BOARD_VENDOR, "LG Electronics Inc."),
},
},
+ {
+ .ident = "Acer Aspire One 150",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "AOA150"),
+ },
+ },
+ {
+ .ident = "Advent 4211",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "DIXONSXP"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Advent 4211"),
+ },
+ },
+ {
+ .ident = "Medion Akoya Mini E1210",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "MEDION"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "E1210"),
+ },
+ },
+ {
+ .ident = "Mivvy M310",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "VIOOO"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "N10"),
+ },
+ },
{ }
};
--
1.6.3.1
--
Best regards,
Li, Yan
Moblin Team, Opensource Technology Center, SSG, Intel
Office tel.: +86-10-82171695 (inet: 8-758-1695)
OpenPGP key: 5C6C31EF
IRC: yanli on network irc.freenode.net
On Mon, Jun 15, 2009 at 10:16:13PM +0800, Yan Li wrote:
> When testing Moblin on various netbooks, we've got reports that many
> MSI Wind clones need the i8042 reset quirks for the keyboard and/or
> touchpad's proper function.
Why are we not doing this unconditionally?
--
Matthew Garrett | [email protected]
On Mon, Jun 15, 2009 at 03:34:46PM +0100, Matthew Garrett wrote:
> On Mon, Jun 15, 2009 at 10:16:13PM +0800, Yan Li wrote:
> > When testing Moblin on various netbooks, we've got reports that many
> > MSI Wind clones need the i8042 reset quirks for the keyboard and/or
> > touchpad's proper function.
>
> Why are we not doing this unconditionally?
For the majority of sane machines this is not necessary.
--
Li, Yan
On Mon, Jun 15, 2009 at 10:47:48PM +0800, Li, Yan wrote:
> On Mon, Jun 15, 2009 at 03:34:46PM +0100, Matthew Garrett wrote:
> > On Mon, Jun 15, 2009 at 10:16:13PM +0800, Yan Li wrote:
> > > When testing Moblin on various netbooks, we've got reports that many
> > > MSI Wind clones need the i8042 reset quirks for the keyboard and/or
> > > touchpad's proper function.
> >
> > Why are we not doing this unconditionally?
>
> For the majority of sane machines this is not necessary.
So? If the alternative is machines that don't work until they're added
to a blacklist, then the correct thing to do is to do it
unconditionally.
--
Matthew Garrett | [email protected]
> So? If the alternative is machines that don't work until they're added
> to a blacklist, then the correct thing to do is to do it
> unconditionally.
I would disagree: that breaks a whole pile of other machines
Alan
On Tue, Jun 16, 2009 at 05:36:18PM +0100, Alan Cox wrote:
> > So? If the alternative is machines that don't work until they're added
> > to a blacklist, then the correct thing to do is to do it
> > unconditionally.
>
> I would disagree: that breaks a whole pile of other machines
I was under the impression that this was the reset path that Windows
followed. If not then that suggests that we're fixing it wrong in the
first place?
--
Matthew Garrett | [email protected]
On Tue, 16 Jun 2009 17:43:51 +0100
Matthew Garrett <[email protected]> wrote:
> On Tue, Jun 16, 2009 at 05:36:18PM +0100, Alan Cox wrote:
> > > So? If the alternative is machines that don't work until they're added
> > > to a blacklist, then the correct thing to do is to do it
> > > unconditionally.
> >
> > I would disagree: that breaks a whole pile of other machines
>
> I was under the impression that this was the reset path that Windows
> followed. If not then that suggests that we're fixing it wrong in the
> first place?
You need to magically divine what various random windows driver
patches do and also allow for the fact that your i8042 may be completely
faked SMM, partially faked, or just randomly confused. Resetting loses
various bits of config/status that get put back by windows drivers we
don't have enough info on and in machine specific ways.
Alan
On Tue, Jun 16, 2009 at 06:15:49PM +0100, Alan Cox wrote:
> On Tue, 16 Jun 2009 17:43:51 +0100
> Matthew Garrett <[email protected]> wrote:
>
> > On Tue, Jun 16, 2009 at 05:36:18PM +0100, Alan Cox wrote:
> > > > So? If the alternative is machines that don't work until they're added
> > > > to a blacklist, then the correct thing to do is to do it
> > > > unconditionally.
> > >
> > > I would disagree: that breaks a whole pile of other machines
> >
> > I was under the impression that this was the reset path that Windows
> > followed. If not then that suggests that we're fixing it wrong in the
> > first place?
>
> You need to magically divine what various random windows driver
> patches do and also allow for the fact that your i8042 may be completely
> faked SMM, partially faked, or just randomly confused. Resetting loses
> various bits of config/status that get put back by windows drivers we
> don't have enough info on and in machine specific ways.
So the touchpad on these machines doesn't work with generic Windows? I'm
interested in the specifics, not general issues with i8042
implementations. We've repeatedly seen that these quirk tables end up
inadequately comprehensive and in several cases have masked the actual
problem.
--
Matthew Garrett | [email protected]
On Wed, Jun 17, 2009 at 01:17:32AM +0800, Matthew Garrett wrote:
> So the touchpad on these machines doesn't work with generic Windows? I'm
> interested in the specifics, not general issues with i8042
> implementations. We've repeatedly seen that these quirk tables end up
> inadequately comprehensive and in several cases have masked the actual
> problem.
Now we have more than 99% machines work well with current i8042 code
path, and less than 1% of machines (those MSI Wind & clones) that
don't work unless being added to this list.
If we do multiple-resetting unconditionally (for all machines), we are
effectively:
1. fixing things that works well
2. make >99% machines (the good citizens) untested
This seems a change too aggressive for me. Do we have a good reason
for taking this risk?
Of course if we found the "actual problem" we'd conjure up a better
fix. But before that, I'd prefer the conservative way.
--
Best regards,
Li, Yan
Moblin Team, Opensource Technology Center, SSG, Intel
Office tel.: +86-10-82171695 (inet: 8-758-1695)
OpenPGP key: 5C6C31EF
IRC: yanli on network irc.freenode.net
On Wed, Jun 17, 2009 at 09:01:40AM +0800, Li, Yan I wrote:
> This seems a change too aggressive for me. Do we have a good reason
> for taking this risk?
It's generally much easier to find regressions (people complain) than it
is to find things that have never worked (people just assume Linux is
broken).
> Of course if we found the "actual problem" we'd conjure up a better
> fix. But before that, I'd prefer the conservative way.
Does stock Windows work on the machine? I think this really ought to be
a pretty obvious minimal test before adding quirks to the kernel.
--
Matthew Garrett | [email protected]
On Wed, Jun 17, 2009 at 03:51:01AM +0100, Matthew Garrett wrote:
> On Wed, Jun 17, 2009 at 09:01:40AM +0800, Li, Yan I wrote:
> > This seems a change too aggressive for me. Do we have a good reason
> > for taking this risk?
>
> It's generally much easier to find regressions (people complain) than it
> is to find things that have never worked (people just assume Linux is
> broken).
That's true. But we are not sure how many regressions we'll meet and
whether the efforts devoted to handle them is worthy. (How to handle
regressions? Perhaps, ironically, we'll need another 'whitelist' for
them!)
> > Of course if we found the "actual problem" we'd conjure up a better
> > fix. But before that, I'd prefer the conservative way.
>
> Does stock Windows work on the machine? I think this really ought to be
> a pretty obvious minimal test before adding quirks to the kernel.
Does this matter? Does whether Windows fail or not affect our
decision here? (Worse that I have no "stock Windows XP" for
testing. All I have are those companion Windows Recovery CDs that
include all drivers).
--
Li, Yan
On Thu, Jun 18, 2009 at 08:08:09AM +0800, Li, Yan wrote:
> On Wed, Jun 17, 2009 at 03:51:01AM +0100, Matthew Garrett wrote:
> > On Wed, Jun 17, 2009 at 09:01:40AM +0800, Li, Yan I wrote:
> > > This seems a change too aggressive for me. Do we have a good reason
> > > for taking this risk?
> >
> > It's generally much easier to find regressions (people complain) than it
> > is to find things that have never worked (people just assume Linux is
> > broken).
>
> That's true. But we are not sure how many regressions we'll meet and
> whether the efforts devoted to handle them is worthy. (How to handle
> regressions? Perhaps, ironically, we'll need another 'whitelist' for
> them!)
If we hit regressions then it's the wrong fix and would have to be
reverted. Better a small blacklist than a large whitelist (though, in
the general case, the presence of either is an indication of a bug)
> > > Of course if we found the "actual problem" we'd conjure up a better
> > > fix. But before that, I'd prefer the conservative way.
> >
> > Does stock Windows work on the machine? I think this really ought to be
> > a pretty obvious minimal test before adding quirks to the kernel.
>
> Does this matter? Does whether Windows fail or not affect our
> decision here? (Worse that I have no "stock Windows XP" for
> testing. All I have are those companion Windows Recovery CDs that
> include all drivers).
Yes. If Windows works without hardware specific drivers then there's a
flaw in our i8042 setup code that's affecting an unknown number of
machines, and adding more entries to a static table tells us nothing
about what proportion of those machines are now fixed - it just tells us
that we've worked around the issue for the ones that Intel happen to be
testing.
--
Matthew Garrett | [email protected]
On Thu, Jun 18, 2009 at 11:42:50PM +0800, Matthew Garrett wrote:
> On Thu, Jun 18, 2009 at 08:08:09AM +0800, Li, Yan wrote:
> > That's true. But we are not sure how many regressions we'll meet and
> > whether the efforts devoted to handle them is worthy. (How to handle
> > regressions? Perhaps, ironically, we'll need another 'whitelist' for
> > them!)
>
> If we hit regressions then it's the wrong fix and would have to be
> reverted.
Still, I don't think we have enough reason to enable multi-reset of
i8042 for all machines: the old code (sane and following specs) has
been working well since long ago for most machines, and not until
recently we have seen special cases, no more than half a dozen
machines that needs special treating. These few glitches can't
justify a global move.
Without a good reason, your move (try and revert if hit regressions)
seems to be the trial-and-error approach, and not very good for the
stable release (though perfectly safe for some testing branches).
> Better a small blacklist than a large whitelist (though, in
> the general case, the presence of either is an indication of a bug)
We have no way to know which one is smaller one, the current list is
very small (5 entries). I'll change my mind if this
i8042_dmi_reset_table[] keeps growing.
The presence of {black,white}list (or more generally, quirks) is the
software reflection of the complexity of the world, not necessarily a
bug. They are popular (if not ubiquitous) among the kernel.
> > Does this matter? Does whether Windows fail or not affect our
> > decision here? (Worse that I have no "stock Windows XP" for
> > testing. All I have are those companion Windows Recovery CDs that
> > include all drivers).
>
> Yes. If Windows works without hardware specific drivers then there's a
> flaw in our i8042 setup code that's affecting an unknown number of
> machines, and adding more entries to a static table tells us nothing
> about what proportion of those machines are now fixed - it just tells us
> that we've worked around the issue for the ones that Intel happen to be
> testing.
Not necessarily if we had followed the spec (I'm not sure of this) of
using i8042.
Hope someone can help us do this test. I have already found loads of
touchpad drivers on net so I guess Windows can't drive a touchpad
until a driver is installed. Pure guess.
--
Best regards,
Li, Yan
Moblin Team, Opensource Technology Center, SSG, Intel
Office tel.: +86-10-82171695 (inet: 8-758-1695)
OpenPGP key: 5C6C31EF
IRC: yanli on network irc.freenode.net
On Fri, Jun 19, 2009 at 03:16:55PM +0800, Li, Yan I wrote:
> Not necessarily if we had followed the spec (I'm not sure of this) of
> using i8042.
The spec is irrelevant. What matters is what's implemented. Canonical
found a case where our i8042 setup code varied from Windows and which
fixed some hardware. Our ACPI implementation deviates wildly from the
spec in some places because that's what the implemented platforms
expect. The kernel exists to drive hardware, not adhere to some platonic
ideal of how the hardware should behave.
> Hope someone can help us do this test. I have already found loads of
> touchpad drivers on net so I guess Windows can't drive a touchpad
> until a driver is installed. Pure guess.
Touchpads typically present as a PS/2 mouse until a specific driver is
loaded, at which point they switch to a protocol that provides absolute
cooirdinates and pressure. It would be virtually impossible to install
most operating systems otherwise.
--
Matthew Garrett | [email protected]
Would now be a good time to trollishly point at
http://bugzilla.kernel.org/show_bug.cgi?id=13540 ?
We broke "an old Pentium 90 machine" some time after 2.6.18.