[git pull] Input updates for 2.6.34-rc6

[git pull] Input updates for 2.6.34-rc6

[Dmitry Torokhov]

Hi Linus,

Please pull from:

	git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
or
	master.kernel.org:/pub/scm/linux/kernel/git/dtor/input.git for-linus

to receive a few last minute changes to the input subsystem.

Changelog:
---------

Bastien Nocera (1):
      Input: i8042 - do not try to probe ports on Intel Apple Macs

Dmitry Torokhov (2):
      Input: elantech - use all 3 bytes when checking version
      Input: psmouse - reset all types of mice before reconnecting

Marek Vasut (2):
      Input: iforce - add Guillemot Jet Leader Force Feedback
      Input: iforce - fix Guillemot Jet Leader 3D entry

Oskar Schirmer (1):
      Input: ad7877 - keep dma rx buffers in seperate cache lines


Diffstat:
--------

 drivers/input/joystick/iforce/iforce-main.c |    6 ++++-
 drivers/input/joystick/iforce/iforce-usb.c  |    1 +
 drivers/input/mouse/elantech.c              |   24 ++++++++++----------
 drivers/input/mouse/elantech.h              |    5 +--
 drivers/input/mouse/psmouse-base.c          |   14 +++++++++---
 drivers/input/serio/i8042-x86ia64io.h       |   30 ++++++++++++++++++++++++++-
 drivers/input/touchscreen/ad7877.c          |   15 ++++++++++--
 7 files changed, 71 insertions(+), 24 deletions(-)

-- 
Dmitry

Re: [git pull] Input updates for 2.6.34-rc6

[Linus Torvalds]

On Thu, 13 May 2010, Dmitry Torokhov wrote:
> 
> Bastien Nocera (1):
>       Input: i8042 - do not try to probe ports on Intel Apple Macs

I pulled, but I skipped the last commit, because I think this one is 
fundamentally _wrong_.

It is _not_ maintainable to create random tables of exceptions ("DMI 
tables"), and it's actively _wrong_ to do for something like this where we 
not only have historically worked perfectly well, and this apparently 
tries to hide some other bug (the commit says "could potentially lock 
up/hang/wait for timeout for long periods of time").

We should fix the problems instead of hiding them for specific machines. 
Does anybody really think that Apple machines are the only ones with no 
legacy keyboard? Hello? Does anybody seriously think that it's ok to add 
entries to DMI tables for random new machines coming out?

So I think that commit was (a) totally inappropriate to send at this point 
in the late -rc series _anyway_ (it sure as hell isn't a refression fix), 
and that makes me wonder about the other ones. But (b) I don't think I 
want to ever see anything like that during a merge window either, because 
it's quite seriously the wrong thing to do.

What are the _actual_ problems on legacy-free machines? And keep in mind 
that I ask that exactly because I actually _have_ two Apple Mac Mini's in 
my household, and have never seen any problems with keyboard/mouse 
handling. 

So if somebody saw "could potentially lock up/hang/wait" issues, then 
dangit, say what those issues are, AND LET'S FIX THEM! And not like this, 
trying to hide them for some particular machines, rather than fixing the 
actual underlying detection bug.

			Linus

Re: [git pull] Input updates for 2.6.34-rc6

[Bastien Nocera]

On Thu, 2010-05-13 at 07:35 -0700, Linus Torvalds wrote:
> 
> On Thu, 13 May 2010, Dmitry Torokhov wrote:
> > 
> > Bastien Nocera (1):
> >       Input: i8042 - do not try to probe ports on Intel Apple Macs
> 
> I pulled, but I skipped the last commit, because I think this one is 
> fundamentally _wrong_.
> 
> It is _not_ maintainable to create random tables of exceptions ("DMI 
> tables"), and it's actively _wrong_ to do for something like this where we 
> not only have historically worked perfectly well, and this apparently 
> tries to hide some other bug (the commit says "could potentially lock 
> up/hang/wait for timeout for long periods of time").
<snip>
> So if somebody saw "could potentially lock up/hang/wait" issues, then 
> dangit, say what those issues are, AND LET'S FIX THEM! And not like this, 
> trying to hide them for some particular machines, rather than fixing the 
> actual underlying detection bug.

I'm waiting for your debug instructions on that one, because we already
looked at that with Dmitry.

I already got that patch in my distribution, and now my machine boots up
uninterrupted. The lock is somewhat random, and will go away as soon as
I press the power button on my machine.

Maybe you didn't update to the latest firmwares on you Mac Mini, and
didn't see the problem with the updated BIOSes, I don't know.

Re: [git pull] Input updates for 2.6.34-rc6

[Linus Torvalds]

On Thu, 13 May 2010, Bastien Nocera wrote:
> 
> Maybe you didn't update to the latest firmwares on you Mac Mini, and
> didn't see the problem with the updated BIOSes, I don't know.

I can't update the firmware, since it's some random OS X program that does 
it (and I don't have OS X on the machine).

But where does it lock up? During the boot probing? Or does it probe as 
having a keyboard because Apple added some crazy SMM code to try to 
emulate one with USB? 

Afaik, the Apple hardware actually does _physically_ have a keyboard 
controller (it's on the regular intel southbridge silicon, afaik), it just 
isn't connected to anything. And I think it is turned off in some of the 
southbridge control registers. The control registers also allow trapping 
into SMI when accessing the keyboard control registers, and maybe Apple 
screwed up there somewhere.

On one of my Mac Mini's (didn't check the other), I get this:

	[    2.955087] PNP: No PS/2 controller found. Probing ports directly.
	[    2.958475] i8042.c: No controller found.
	[    2.960998] mice: PS/2 mouse device common for all mice

what do you get?

The thing is, there's a _lot_ of machines out there with no legacy 
keyboard support. They tend to work. We have timeouts for the i8042 
commands we do during init, but maybe we missed some case. And maybe we 
could easily add some extra tests too.

A few printk's in the i8042 init routines to show where it locks up would 
be good.. I assume you did that already if you and Dmitry already tried to 
debug this. Where's the original thread?

			Linus

Re: [git pull] Input updates for 2.6.34-rc6

[Linus Torvalds]

On Thu, 13 May 2010, Linus Torvalds wrote:
> 
> On one of my Mac Mini's (didn't check the other), I get this:
> 
> 	[    2.955087] PNP: No PS/2 controller found. Probing ports directly.
> 	[    2.958475] i8042.c: No controller found.
> 	[    2.960998] mice: PS/2 mouse device common for all mice
> 
> what do you get?

Hah. On the other one, I get

	PNP: No PS/2 controller found. Probing ports directly.
	mice: PS/2 mouse device common for all mice

but that works fine too. As mentioned, the controller hardware should all 
be there - whether it's then enabled or not is a firmware issue.

At the same time, I do think our detection is likely pretty dang weak too. 
Do you get any interesting messages if you just enable DEBUG in 
drivers/input/serio/i8042.h?

			Linus

Re: [git pull] Input updates for 2.6.34-rc6

[Dmitry Torokhov]

On Thu, May 13, 2010 at 08:04:15AM -0700, Linus Torvalds wrote:
> 
> 
> On Thu, 13 May 2010, Bastien Nocera wrote:
> > 
> > Maybe you didn't update to the latest firmwares on you Mac Mini, and
> > didn't see the problem with the updated BIOSes, I don't know.
> 
> I can't update the firmware, since it's some random OS X program that does 
> it (and I don't have OS X on the machine).
> 
> But where does it lock up? During the boot probing? Or does it probe as 
> having a keyboard because Apple added some crazy SMM code to try to 
> emulate one with USB? 
> 
> Afaik, the Apple hardware actually does _physically_ have a keyboard 
> controller (it's on the regular intel southbridge silicon, afaik), it just 
> isn't connected to anything. And I think it is turned off in some of the 
> southbridge control registers. The control registers also allow trapping 
> into SMI when accessing the keyboard control registers, and maybe Apple 
> screwed up there somewhere.
> 
> On one of my Mac Mini's (didn't check the other), I get this:
> 
> 	[    2.955087] PNP: No PS/2 controller found. Probing ports directly.
> 	[    2.958475] i8042.c: No controller found.
> 	[    2.960998] mice: PS/2 mouse device common for all mice
> 
> what do you get?
> 
> The thing is, there's a _lot_ of machines out there with no legacy 
> keyboard support. They tend to work.

Indeed most of them do just work. My Dell T110 for example boots just
fine and it only has USB, no PS/2 ports. However there is a rather
important difference I think - these other boxes are supposed to work
with multiple versions of Windows which, as far as I know, do probe for
the i8042. Apple only supports bootcamp on certain BIOSes and does not
really expect anything to touch these ports.

> We have timeouts for the i8042 
> commands we do during init, but maybe we missed some case. And maybe we 
> could easily add some extra tests too.
> 
> A few printk's in the i8042 init routines to show where it locks up would 
> be good.. I assume you did that already if you and Dmitry already tried to 
> debug this. Where's the original thread?
> 

>From what I remember (it was a few weeks old thread) we were hanging
when trying to read from the controller in i8042_flush(). Normally, if
controller isn't there we'd get a stream of 0xff which will never
"clear" and so after 32 reads we give up and abort controller
initialization. But on Bastien's box it just sits there.

-- 
Dmitry

Re: [git pull] Input updates for 2.6.34-rc6

[Linus Torvalds]

On Thu, 13 May 2010, Dmitry Torokhov wrote:
> 
> From what I remember (it was a few weeks old thread) we were hanging
> when trying to read from the controller in i8042_flush(). Normally, if
> controller isn't there we'd get a stream of 0xff which will never
> "clear" and so after 32 reads we give up and abort controller
> initialization. But on Bastien's box it just sits there.

Is there a web interface to some archive for linux-input (or was this 
thread on lkml)?

Anyway, the fact that apparently pressing the power button makes it come 
alive again implies that it's likely SCI/SMI-related. Which is not 
entirely unexpected if there is some crazy SMM thing going on. But 
presumably whatever buggy Apple code is _supposed_ to work for Windows, so 
I wonder what bug that quite simple status/data register read could 
possibly trigger.

Is it the status read or the data read that causes problems, and is it the 
first one or after doing a few? A couple of printk's in that i8042_flush() 
routine should tell us.

			Linus

Re: [git pull] Input updates for 2.6.34-rc6

[Randy Dunlap]

On Thu, 13 May 2010 09:16:31 -0700 (PDT) Linus Torvalds wrote:

> 
> 
> On Thu, 13 May 2010, Dmitry Torokhov wrote:
> > 
> > From what I remember (it was a few weeks old thread) we were hanging
> > when trying to read from the controller in i8042_flush(). Normally, if
> > controller isn't there we'd get a stream of 0xff which will never
> > "clear" and so after 32 reads we give up and abort controller
> > initialization. But on Bastien's box it just sits there.
> 
> Is there a web interface to some archive for linux-input (or was this 
> thread on lkml)?

>From Jan. 20, on lkml.
See http://lkml.org/lkml/2010/1/20/254


> Anyway, the fact that apparently pressing the power button makes it come 
> alive again implies that it's likely SCI/SMI-related. Which is not 
> entirely unexpected if there is some crazy SMM thing going on. But 
> presumably whatever buggy Apple code is _supposed_ to work for Windows, so 
> I wonder what bug that quite simple status/data register read could 
> possibly trigger.
> 
> Is it the status read or the data read that causes problems, and is it the 
> first one or after doing a few? A couple of printk's in that i8042_flush() 
> routine should tell us.


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: [git pull] Input updates for 2.6.34-rc6

[Matthew Garrett]

On Thu, May 13, 2010 at 08:50:31AM -0700, Dmitry Torokhov wrote:

> Indeed most of them do just work. My Dell T110 for example boots just
> fine and it only has USB, no PS/2 ports. However there is a rather
> important difference I think - these other boxes are supposed to work
> with multiple versions of Windows which, as far as I know, do probe for
> the i8042. Apple only supports bootcamp on certain BIOSes and does not
> really expect anything to touch these ports.

If you're not using bootcamp then you're booting via EFI, and in that 
case I think it's probably reasonable to require that the keyboard be 
provided via PNP or flagged in the XDST.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [git pull] Input updates for 2.6.34-rc6

[Dmitry Torokhov]

On Thu, May 13, 2010 at 07:35:02AM -0700, Linus Torvalds wrote:
> 
> 
> On Thu, 13 May 2010, Dmitry Torokhov wrote:
> > 
> > Bastien Nocera (1):
> >       Input: i8042 - do not try to probe ports on Intel Apple Macs
> 
> I pulled, but I skipped the last commit, because I think this one is 
> fundamentally _wrong_.
> 
> It is _not_ maintainable to create random tables of exceptions ("DMI 
> tables"), and it's actively _wrong_ to do for something like this where we 
> not only have historically worked perfectly well, and this apparently 
> tries to hide some other bug (the commit says "could potentially lock 
> up/hang/wait for timeout for long periods of time").
> 
> We should fix the problems instead of hiding them for specific machines. 
> Does anybody really think that Apple machines are the only ones with no 
> legacy keyboard? Hello? Does anybody seriously think that it's ok to add 
> entries to DMI tables for random new machines coming out?
> 
> So I think that commit was (a) totally inappropriate to send at this point 
> in the late -rc series _anyway_ (it sure as hell isn't a refression fix), 
> and that makes me wonder about the other ones.

I will freely admit that none of the fixes would qualify as strictly regression
fixes. The cacheline issue on ad7877 was there in the very first version
of the driver being committed, iforce got 1 new product ID and a fix to another
product ID which was there for ages, psmouse changes tries to work
around issue on a laptop that is not out yet as far as I know... All of
these however are very small, with low risk of disturbing anyone, and
making users life better. That is why I thought that rather than having
them wait for another 3 months we sould get the fixes out earlier.

> But (b) I don't think I 
> want to ever see anything like that during a merge window either, because 
> it's quite seriously the wrong thing to do.
>

Sometimes we do need to resort to DMI quirks because we do not have
anything else to go on and i8042 is littered with such cases. Half of
the boxes claim to support active multiplexing but don't. HOwever when
it works it is a useful thing (on laptop both touchpad and external mice
can work independently with their full protocols instead of degrading
both to Intellimouse, like Dells do). Some BIOSes hang if you use AUX LOOP.
And so on.

Apple does proper thing in BIOS and omits keyboard and mouse PNP
devices, but because of other players we do not really trust PNP BIOS
and resort to banding on ports directly - there are cases when box has
mouse and/or keyboard but they are not present in BIOS. Damed if you do,
damned if you don't...


> What are the _actual_ problems on legacy-free machines? And keep in mind 
> that I ask that exactly because I actually _have_ two Apple Mac Mini's in 
> my household, and have never seen any problems with keyboard/mouse 
> handling. 
> 
> So if somebody saw "could potentially lock up/hang/wait" issues, then 
> dangit, say what those issues are, AND LET'S FIX THEM! And not like this, 
> trying to hide them for some particular machines, rather than fixing the 
> actual underlying detection bug.
> 
> 			Linus

-- 
Dmitry

Re: [git pull] Input updates for 2.6.34-rc6

[Linus Torvalds]

On Thu, 13 May 2010, Dmitry Torokhov wrote:
> 
> Apple does proper thing in BIOS and omits keyboard and mouse PNP
> devices, but because of other players we do not really trust PNP BIOS
> and resort to banding on ports directly - there are cases when box has
> mouse and/or keyboard but they are not present in BIOS. Damed if you do,
> damned if you don't...

Umm. No.

PnP information _commonly_ doesn't inclure PS/2 ports, even when they 
exist. Lack of PnP information about the keyboard port means absolutely 
nothing, and anybody who tells you otherwise is totally and utterly wrong. 

So don't confuse this with PnP issues. That's a total red herring, and 
Apple is _not_at_all_ "doing the proper thing in the BIOS". 

Quite the reverse. Apple is very clearly doing something horribly _wrong_ 
in their BIOS. Don't give them kudos for being incompetent morons.

Just google for

	"Probing ports directly" "i8042 KBD port"

and you'll get a lot of hits. That's not because those machines have wrong 
PnP tables - it's because fundamentally PNP is a joke, and on PC's what is 
much more important is "standard IO ports". 

For example, in that thread, Bastien is quoted:

	> In other words, on x86, if PNP and/or ACPI don't indicate any PS/2 
	> controller exists, we randomly bang on the ports in the expectation 
	> they'll be there anyway. This seems rather misguided.

and all that tells me is that Bastien doesn't know what he is doing. It is 
_not_ "randomly bang" - it's called standard PC hardware.  And it's not 
"misguided" - it's very much correct and required, exactly because PnP 
itself is the misguided aborted fetus of a braindamaged mind.

We do not trust BIOS tables, because BIOS writers are invariably totally 
incompetent crack-addicted monkeys. If they weren't, they wouldn't be BIOS 
writers. QED. And in fact the Apple problem is an _example_ of this BIOS 
writer incompetence, not some shining example of them doing something 
right.

			Linus

Re: [git pull] Input updates for 2.6.34-rc6

[Linus Torvalds]

On Thu, 13 May 2010, Linus Torvalds wrote:
> 
> PnP information _commonly_ doesn't inclure PS/2 ports, even when they 
> exist. Lack of PnP information about the keyboard port means absolutely 
> nothing, and anybody who tells you otherwise is totally and utterly wrong. 
> 
> So don't confuse this with PnP issues. That's a total red herring, and 
> Apple is _not_at_all_ "doing the proper thing in the BIOS". 

Btw, was this an EFI boot?

I could easily see bootcamp working (it's been tested with Windows, after 
all), but not EFI (I've heard rumors of Windows booting from EFI, but I 
don't know if those are actually correct). 

And I'd be a _lot_ more open to saying "if you booted from EFI, then we're 
going to ignore any legacy devices that aren't in PnP tables".

In fact, we effectively do that today by having different code-paths for 
ia64 (which was EFI) and x86 (which is obviously traditionally not EFI).

			Linus

Re: [git pull] Input updates for 2.6.34-rc6

[Dmitry Torokhov]

On Thu, May 13, 2010 at 09:54:00AM -0700, Linus Torvalds wrote:
> 
> 
> On Thu, 13 May 2010, Dmitry Torokhov wrote:
> > 
> > Apple does proper thing in BIOS and omits keyboard and mouse PNP
> > devices, but because of other players we do not really trust PNP BIOS
> > and resort to banding on ports directly - there are cases when box has
> > mouse and/or keyboard but they are not present in BIOS. Damed if you do,
> > damned if you don't...
> 
> Umm. No.
> 
> PnP information _commonly_ doesn't inclure PS/2 ports, even when they 
> exist. Lack of PnP information about the keyboard port means absolutely 
> nothing, and anybody who tells you otherwise is totally and utterly wrong. 
>

I think on the newer hardware PNP (or rather ACPI mapped onto PNP) usually 
matches the reality.

> So don't confuse this with PnP issues. That's a total red herring, and 
> Apple is _not_at_all_ "doing the proper thing in the BIOS". 
> 
> Quite the reverse. Apple is very clearly doing something horribly _wrong_ 
> in their BIOS. Don't give them kudos for being incompetent morons.
> 
> Just google for
> 
> 	"Probing ports directly" "i8042 KBD port"
> 
> and you'll get a lot of hits. That's not because those machines have wrong 
> PnP tables - it's because fundamentally PNP is a joke, and on PC's what is 
> much more important is "standard IO ports". 
> 
> For example, in that thread, Bastien is quoted:
> 
> 	> In other words, on x86, if PNP and/or ACPI don't indicate any PS/2 
> 	> controller exists, we randomly bang on the ports in the expectation 
> 	> they'll be there anyway. This seems rather misguided.
> 
> and all that tells me is that Bastien doesn't know what he is doing. It is 
> _not_ "randomly bang" - it's called standard PC hardware.

Do Macs qualify to be called "standard PC hardware" though? Again, there
are BootCamp BIOSes that allow you booting XP on them, and most likely
newer models already have that ironed out, but we can't expect older
ones to survive port probing.

>  And it's not 
> "misguided" - it's very much correct and required, exactly because PnP 
> itself is the misguided aborted fetus of a braindamaged mind.
> 
> We do not trust BIOS tables, because BIOS writers are invariably totally 
> incompetent crack-addicted monkeys. If they weren't, they wouldn't be BIOS 
> writers. QED. And in fact the Apple problem is an _example_ of this BIOS 
> writer incompetence, not some shining example of them doing something 
> right.

Well, they got PNP tables right ;)

-- 
Dmitry

Re: [git pull] Input updates for 2.6.34-rc6

[Linus Torvalds]

On Thu, 13 May 2010, Dmitry Torokhov wrote:
> 
> I think on the newer hardware PNP (or rather ACPI mapped onto PNP) usually 
> matches the reality.

Dmitry, you're just making things up.

I have in front of me a Core i5-670. You can't get much newer than that. 
And yes, it has a PS/2 connector at the back. And lookie here:

	[    1.756777] PNP: No PS/2 controller found. Probing ports directly.
	[    1.760645] serio: i8042 KBD port at 0x60,0x64 irq 1
	[    1.762087] serio: i8042 AUX port at 0x60,0x64 irq 12
	[    1.763591] mice: PS/2 mouse device common for all mice

so let it go. You're wrong. PS/2 is a legacy device, and exactly like the 
legacy IO memory region in 0xa000-0xffff (or the motherboard IO port 
region 0x00-0xff) it may not be mentioned by the BIOS tables. But it's 
still there.

This is also why I think it _would_ be acceptable to say that if you boot 
from EFI, you have to find the PnP devices. The whole (and only, as far as 
I know) point of EFI was that "legacy-free" thing.

		Linus

Re: [git pull] Input updates for 2.6.34-rc6

[Dmitry Torokhov]

On Thu, May 13, 2010 at 10:30:23AM -0700, Linus Torvalds wrote:
> 
> 
> On Thu, 13 May 2010, Dmitry Torokhov wrote:
> > 
> > I think on the newer hardware PNP (or rather ACPI mapped onto PNP) usually 
> > matches the reality.
> 
> Dmitry, you're just making things up.
> 
> I have in front of me a Core i5-670. You can't get much newer than that. 
> And yes, it has a PS/2 connector at the back. And lookie here:
> 
> 	[    1.756777] PNP: No PS/2 controller found. Probing ports directly.
> 	[    1.760645] serio: i8042 KBD port at 0x60,0x64 irq 1
> 	[    1.762087] serio: i8042 AUX port at 0x60,0x64 irq 12
> 	[    1.763591] mice: PS/2 mouse device common for all mice
>

You don't have anything plugged into the ports though, do you? I wonder
what your DSDT looks like.
 
> so let it go. You're wrong. PS/2 is a legacy device, and exactly like the 
> legacy IO memory region in 0xa000-0xffff (or the motherboard IO port 
> region 0x00-0xff) it may not be mentioned by the BIOS tables. But it's 
> still there.
> 
> This is also why I think it _would_ be acceptable to say that if you boot 
> from EFI, you have to find the PnP devices. The whole (and only, as far as 
> I know) point of EFI was that "legacy-free" thing.

Is there an interface a driver can use to query the style of boot used?

-- 
Dmitry

Re: [git pull] Input updates for 2.6.34-rc6

[Linus Torvalds]

On Thu, 13 May 2010, Dmitry Torokhov wrote:
> 
> Is there an interface a driver can use to query the style of boot used?

Maybe 'efi_enabled' will do. I haven't checked exact semantics of that 
flag. And right now we don't even know if Bastien even uses EFI, or boots 
a traditional kernel image through bootcamp.

		Linus

Re: [git pull] Input updates for 2.6.34-rc6

[Eric W. Biederman]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Thu, 13 May 2010, Dmitry Torokhov wrote:
>> 
>> Is there an interface a driver can use to query the style of boot used?
>
> Maybe 'efi_enabled' will do. I haven't checked exact semantics of that 
> flag. And right now we don't even know if Bastien even uses EFI, or boots 
> a traditional kernel image through bootcamp.

efi_enabled is a guard on efi calls.  If it is true it tells you that
you can make runtime efi calls.  If it is false you can't use runtime
efi calls. efi_enabled does not tell you about the presence of efi
on a system.

efi_enabled is generally uninteresting because there is an agreement
that you should be able to all of the runtime work that matters with
acpi.

This is reinforced by the fact that efi comes in two different flavors
on x86 32bit and 64bit, and 64bit efi does not have a 32bit
compatibility layer (too many hard coded pointers in the interface).
You can't make 32bit efi calls from from a 64bit kernel or 64bit efi
calls from a 32bit kernel.

All of which means in the normal case pay attention to acpi.  That is
more likely to be correct and usable than EFI anything.

Eric

Re: [git pull] Input updates for 2.6.34-rc6

[Linus Torvalds]

On Fri, 14 May 2010, Eric W. Biederman wrote:
> 
> efi_enabled is a guard on efi calls.  If it is true it tells you that
> you can make runtime efi calls.  If it is false you can't use runtime
> efi calls. efi_enabled does not tell you about the presence of efi
> on a system.

We don't really want to know about the "presense". What we want to know 
about is whether we were _loaded_ with EFI or not.

IOW, even if the system is EFI-capable, if we actually booted through the 
legacy BIOS interfaces, we would consider ourselves in "legacy" mode.

> All of which means in the normal case pay attention to acpi.  That is
> more likely to be correct and usable than EFI anything.

Oh yes. ACPI is actually _tested_, so while it's buggy, it's unlikely to 
be quite as spectacularly buggy as any EFI interfaces probably are.

But the issue here is that on a "legacy PC", we can't just say "ACPI 
doesn't mention this device, so it can't exist". Because in a legacy PC 
model, that simply isn't true. All those motherboard devices can easily 
exist (and do!) even if ACPI/PnP don't mention them.

But if we live in a non-legacy world (ie we were loaded through EFI), I 
think it's much more reasonable to say "we'll ignore any devices not 
mentioned by ACPI".

			Linus

Re: [git pull] Input updates for 2.6.34-rc6

[Matthew Garrett]

On Fri, May 14, 2010 at 07:54:53AM -0700, Linus Torvalds wrote:

> But the issue here is that on a "legacy PC", we can't just say "ACPI 
> doesn't mention this device, so it can't exist". Because in a legacy PC 
> model, that simply isn't true. All those motherboard devices can easily 
> exist (and do!) even if ACPI/PnP don't mention them.

I think that's true except in the case where the Leading Other OS won't 
use a device unless it's present in ACPI - that kind of enforcement 
tends to concentrate vendors' minds, even if they'd otherwise be busy 
filling data tables with garbage.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [git pull] Input updates for 2.6.34-rc6

[Linus Torvalds]

On Fri, 14 May 2010, Matthew Garrett wrote:
> 
> I think that's true except in the case where the Leading Other OS won't 
> use a device unless it's present in ACPI - that kind of enforcement 
> tends to concentrate vendors' minds, even if they'd otherwise be busy 
> filling data tables with garbage.

Largely true. That said, nobody uses Windows in a headless environment, 
the way people _do_ use Linux and then later plug in a keyboard. 

Also, even with Windows, I do wonder if they have things like cut-off 
dates for trusting ACPI. We certainly do.

		Linus

Re: [git pull] Input updates for 2.6.34-rc6

[Matthew Garrett]

On Fri, May 14, 2010 at 08:42:59AM -0700, Linus Torvalds wrote:

> Also, even with Windows, I do wonder if they have things like cut-off 
> dates for trusting ACPI. We certainly do.

Yeah, I think they cut off around 2000 or so. I should try feeding it 
different DMI strings to see what happens.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [git pull] Input updates for 2.6.34-rc6

[Len Brown]

> Also, even with Windows, I do wonder if they have things like cut-off 
> dates for trusting ACPI. We certainly do.

Upstream Linux's main ACPI cutoff, CONFIG_ACPI_BLACKLIST_YEAR
has been disabled by default since Linux-2.6.9.
So if a platform claims to support ACPI,
upstream Linux has run in ACPI mode on it for many years.

The idea was that we'd harvest and debug ACPI failures
using the upstream kernels, while the distros could play it safe
and set the cutoff to 1999 or even later.

But a funny thing happened a few years ago.
The distros stopped setting this cutoff, and nobody complained.
Of course, it could simply be that few people are using machines
that old anymore...

In any case, I expect that versions of Windows around 1999 or 2000
had to check, but that like Linux, they don't really need to anymore.

cheers,
Len Brown, Intel Open Source Technology Center

Re: [git pull] Input updates for 2.6.34-rc6

[Robert Hancock]

On 05/13/2010 10:54 AM, Linus Torvalds wrote:
>
>
> On Thu, 13 May 2010, Dmitry Torokhov wrote:
>>
>> Apple does proper thing in BIOS and omits keyboard and mouse PNP
>> devices, but because of other players we do not really trust PNP BIOS
>> and resort to banding on ports directly - there are cases when box has
>> mouse and/or keyboard but they are not present in BIOS. Damed if you do,
>> damned if you don't...
>
> Umm. No.
>
> PnP information _commonly_ doesn't inclure PS/2 ports, even when they
> exist. Lack of PnP information about the keyboard port means absolutely
> nothing, and anybody who tells you otherwise is totally and utterly wrong.
>
> So don't confuse this with PnP issues. That's a total red herring, and
> Apple is _not_at_all_ "doing the proper thing in the BIOS".
>
> Quite the reverse. Apple is very clearly doing something horribly _wrong_
> in their BIOS. Don't give them kudos for being incompetent morons.

I don't think they did anything wrong in their BIOS, it's working 
exactly as the spec intended. There is no PS/2 controller, and the ACPI 
PnP tables do not list one. I wouldn't argue that it was a good decision 
of them to have the hardware somehow blow up if something poked those 
ports anyway, but from a BIOS point of view they did the right thing.

>
> Just google for
>
> 	"Probing ports directly" "i8042 KBD port"
>
> and you'll get a lot of hits. That's not because those machines have wrong
> PnP tables - it's because fundamentally PNP is a joke, and on PC's what is
> much more important is "standard IO ports".
>
> For example, in that thread, Bastien is quoted:
>
> 	>  In other words, on x86, if PNP and/or ACPI don't indicate any PS/2
> 	>  controller exists, we randomly bang on the ports in the expectation
> 	>  they'll be there anyway. This seems rather misguided.
>
> and all that tells me is that Bastien doesn't know what he is doing. It is
> _not_ "randomly bang" - it's called standard PC hardware.  And it's not
> "misguided" - it's very much correct and required, exactly because PnP
> itself is the misguided aborted fetus of a braindamaged mind.

I think that may have been me, actually, not Bastien. Misguided may have 
been a too strong term, but in this case I think the PnP information is 
quite trustable because Windows trusts it. Definitely for the PS/2 mouse 
controller (quite likely the keyboard too), if Windows is in ACPI mode 
and the PnP tables do not list it, it will not detect or use it.

Now, many BIOSes seem to have have code (like an "auto" mode for the 
PS/2 port, which may or may not be always set) which disables the PnP 
entry if it doesn't detect a mouse or keyboard connected on boot. If 
memory serves, this is because I think at least on some versions, if 
Windows finds a controller but no mouse is responding then it shows up 
with an error indication in Device Manager, which tends to make people 
unhappy. This is likely what's responsible for most of those cases where 
Linux detects devices after "probing ports directly", because the BIOS 
hid the device but we were too "clever" for it and found it anyway.

In fact on a lot of boards, Linux still detects the port even if set as 
"disabled" in the BIOS, because all that does is disable the PnP entry.

Long and the short of it is, it seems pretty safe to say that on any 
ACPI machine, if there's no PnP entry for PS/2 devices, the BIOS does 
not intend for the OS to use them. There may be cases where you might 
want to try to locate ports anyway (maybe you really want to hotplug a 
mouse in after boot, or you have an ancient KVM which doesn't emulate a 
device presence on the non-selected machine), but those seem like very 
much the exception rather than the rule.

>
> We do not trust BIOS tables, because BIOS writers are invariably totally
> incompetent crack-addicted monkeys. If they weren't, they wouldn't be BIOS
> writers. QED. And in fact the Apple problem is an _example_ of this BIOS
> writer incompetence, not some shining example of them doing something
> right.
>
> 			Linus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: [git pull] Input updates for 2.6.34-rc6

[Dmitry Torokhov]

On Thu, May 27, 2010 at 12:22:35AM -0600, Robert Hancock wrote:
> On 05/13/2010 10:54 AM, Linus Torvalds wrote:
> >
> >
> >On Thu, 13 May 2010, Dmitry Torokhov wrote:
> >>
> >>Apple does proper thing in BIOS and omits keyboard and mouse PNP
> >>devices, but because of other players we do not really trust PNP BIOS
> >>and resort to banding on ports directly - there are cases when box has
> >>mouse and/or keyboard but they are not present in BIOS. Damed if you do,
> >>damned if you don't...
> >
> >Umm. No.
> >
> >PnP information _commonly_ doesn't inclure PS/2 ports, even when they
> >exist. Lack of PnP information about the keyboard port means absolutely
> >nothing, and anybody who tells you otherwise is totally and utterly wrong.
> >
> >So don't confuse this with PnP issues. That's a total red herring, and
> >Apple is _not_at_all_ "doing the proper thing in the BIOS".
> >
> >Quite the reverse. Apple is very clearly doing something horribly _wrong_
> >in their BIOS. Don't give them kudos for being incompetent morons.
> 
> I don't think they did anything wrong in their BIOS, it's working
> exactly as the spec intended. There is no PS/2 controller, and the
> ACPI PnP tables do not list one. I wouldn't argue that it was a good
> decision of them to have the hardware somehow blow up if something
> poked those ports anyway, but from a BIOS point of view they did the
> right thing.
> 
> >
> >Just google for
> >
> >	"Probing ports directly" "i8042 KBD port"
> >
> >and you'll get a lot of hits. That's not because those machines have wrong
> >PnP tables - it's because fundamentally PNP is a joke, and on PC's what is
> >much more important is "standard IO ports".
> >
> >For example, in that thread, Bastien is quoted:
> >
> >	>  In other words, on x86, if PNP and/or ACPI don't indicate any PS/2
> >	>  controller exists, we randomly bang on the ports in the expectation
> >	>  they'll be there anyway. This seems rather misguided.
> >
> >and all that tells me is that Bastien doesn't know what he is doing. It is
> >_not_ "randomly bang" - it's called standard PC hardware.  And it's not
> >"misguided" - it's very much correct and required, exactly because PnP
> >itself is the misguided aborted fetus of a braindamaged mind.
> 
> I think that may have been me, actually, not Bastien. Misguided may
> have been a too strong term, but in this case I think the PnP
> information is quite trustable because Windows trusts it. Definitely
> for the PS/2 mouse controller (quite likely the keyboard too), if
> Windows is in ACPI mode and the PnP tables do not list it, it will
> not detect or use it.
> 
> Now, many BIOSes seem to have have code (like an "auto" mode for the
> PS/2 port, which may or may not be always set) which disables the
> PnP entry if it doesn't detect a mouse or keyboard connected on
> boot. If memory serves, this is because I think at least on some
> versions, if Windows finds a controller but no mouse is responding
> then it shows up with an error indication in Device Manager, which
> tends to make people unhappy. This is likely what's responsible for
> most of those cases where Linux detects devices after "probing ports
> directly", because the BIOS hid the device but we were too "clever"
> for it and found it anyway.
> 
> In fact on a lot of boards, Linux still detects the port even if set
> as "disabled" in the BIOS, because all that does is disable the PnP
> entry.
> 
> Long and the short of it is, it seems pretty safe to say that on any
> ACPI machine, if there's no PnP entry for PS/2 devices, the BIOS
> does not intend for the OS to use them. There may be cases where you
> might want to try to locate ports anyway (maybe you really want to
> hotplug a mouse in after boot, or you have an ancient KVM which
> doesn't emulate a device presence on the non-selected machine), but
> those seem like very much the exception rather than the rule.
>

I would be much more happy if ACPI would add devices to the device tree
even if they happen to be disabled. Then we could really trust DSDTs and
not bang i8042 ports if the controller is truly not there (newer Dell
servers, Apple, etc) but still woudl detect the controller just fine if
BIOS decided to hide it from Windows.

-- 
Dmitry

Re: [git pull] Input updates for 2.6.34-rc6

[Linus Torvalds]

On Thu, 27 May 2010, Robert Hancock wrote:
> 
> I don't think they did anything wrong in their BIOS, it's working exactly as
> the spec intended. There is no PS/2 controller, and the ACPI PnP tables do not
> list one.

You seem to be unable to read. 

First off, there _is_ a PS2 controller. You can't get any normal Intel 
chips without one, as far as I can tell. The lines may not be brought out, 
but that's immaterial.

Secondly, even if there wasn't any - or the controller is actively 
disabled, Linux handles that situation perfectly fine. The fact is, the 
low ports (< 0x100) are reserved for motherboard devices, and Linux probes 
the things fine.

Thirdly, the thing is, PnP tables are incomplete. Always. They don't prove 
a negative. Deal with it. It's a _fact_.

So Apple must have actively screwed things up. If you can't admit that, 
it's your problem.

> Long and the short of it is, it seems pretty safe to say that on any ACPI
> machine, if there's no PnP entry for PS/2 devices, the BIOS does not intend
> for the OS to use them. 

And your argument is pure and utter sh*t. I don't know why I even bother 
replying to it, but I'll try one more time:

 - BIOS writers are incompetent drug-addled morons. Your argument that 
   "the BIOS does not intend for the OS to use them" is a totally idiotic 
   argument, for the simple reason that it's not up to the BIOS writers, 
   and even if it _was_ up to them, they always screw things up.

The thing boils down to: we cannot trust the firmware anyway (this is a 
simple _fact_, not some random opinion), and no, the BIOS writers do not 
have some magic powers that allow them to determine how hardware should be 
used.

Should we always use PIO mode for IDE just because the BIOS may have set 
it up that way? Even if we know better? It's the exact same issue: 
firmware simply isn't the last word. It shouldn't be in the first place, 
but more importantly, it _cannot_ be, because the BIOS writers have shown 
themselves to be inevitably incompetent.

And Apple BIOS writers seem to be worse than average. The _average_ BIOS 
writer tends to still result in working keyboards (or properly disabled 
ones). The incompetent ones do bad things with SMM and actively break the 
keyboard. Apple is not alone in this, although I think this is the first 
time I hear of somebody breaking it quite _that_ badly (normally it's just 
"horribly bad latency due to SMM traps").

		Linus

Re: [git pull] Input updates for 2.6.34-rc6

[Robert Hancock]

On Thu, May 27, 2010 at 11:06 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> On Thu, 27 May 2010, Robert Hancock wrote:
>>
>> I don't think they did anything wrong in their BIOS, it's working exactly as
>> the spec intended. There is no PS/2 controller, and the ACPI PnP tables do not
>> list one.
>
> You seem to be unable to read.
>
> First off, there _is_ a PS2 controller. You can't get any normal Intel
> chips without one, as far as I can tell. The lines may not be brought out,
> but that's immaterial.

I believe the PS/2 controller is normally on the LPC SuperIO chip, not
the chipset itself. It's entirely possible that Apple used a chip that
didn't include any such controller at all. It's also possible they
reused the IO ports normally assigned to it for something else (which
would be a questionable decision, yes), which is why the machine blows
up when the ports get probed.

>
> Secondly, even if there wasn't any - or the controller is actively
> disabled, Linux handles that situation perfectly fine. The fact is, the
> low ports (< 0x100) are reserved for motherboard devices, and Linux probes
> the things fine.
>
> Thirdly, the thing is, PnP tables are incomplete. Always. They don't prove
> a negative. Deal with it. It's a _fact_.

It's highly unlikely that they are incomplete in this respect, as
since I mentioned, Windows would fail to recognize the PS/2 controller
that people would expect to work, which would most likely get
noticed..

>
> So Apple must have actively screwed things up. If you can't admit that,
> it's your problem.
>
>> Long and the short of it is, it seems pretty safe to say that on any ACPI
>> machine, if there's no PnP entry for PS/2 devices, the BIOS does not intend
>> for the OS to use them.
>
> And your argument is pure and utter sh*t. I don't know why I even bother
> replying to it, but I'll try one more time:
>
>  - BIOS writers are incompetent drug-addled morons. Your argument that
>   "the BIOS does not intend for the OS to use them" is a totally idiotic
>   argument, for the simple reason that it's not up to the BIOS writers,
>   and even if it _was_ up to them, they always screw things up.
>
> The thing boils down to: we cannot trust the firmware anyway (this is a
> simple _fact_, not some random opinion), and no, the BIOS writers do not
> have some magic powers that allow them to determine how hardware should be
> used.

I think this is a case where it has to be trusted, because that's what
Windows does. Experience has shown time and again that deviating from
Windows behavior with these kinds of ACPI platform-related issues is
fraught with problems, since hardware vendors test only with Windows.
If Linux behaved the same as Windows here, and left the PS/2 IO ports
alone since there was no PNP device defined for it, this problem
presumably wouldn't have come up.

Since many machines are moving towards no longer including legacy PS/2
ports, this kind of thing seems likely to come up elsewhere..

Re: [git pull] Input updates for 2.6.34-rc6

[Linus Torvalds]

On Thu, 27 May 2010, Robert Hancock wrote:
> 
> It's highly unlikely that they are incomplete in this respect, as
> since I mentioned, Windows would fail to recognize the PS/2 controller
> that people would expect to work, which would most likely get
> noticed..

Did you miss the part where I actually quoted my own modern Core i5 
machine that _does_ have a keyboard controller, and _does_ have a keyboard 
port, and that does _not_ mention them in the PnP tables?

> I think this is a case where it has to be trusted, because that's what
> Windows does.

The thing is, Windows isn't used for things like headless machines. Which 
we went over extensively in the thread. There's a _reason_ why Linux 
probes the dang thing.

			Linus

Re: [git pull] Input updates for 2.6.34-rc6

[Dmitry Torokhov]

On May 27, 2010, at 5:46 PM, Linus Torvalds <torvalds@linux-foundation.org 
 > wrote:

>
>
> On Thu, 27 May 2010, Robert Hancock wrote:
>>
>> It's highly unlikely that they are incomplete in this respect, as
>> since I mentioned, Windows would fail to recognize the PS/2  
>> controller
>> that people would expect to work, which would most likely get
>> noticed..
>
> Did you miss the part where I actually quoted my own modern Core i5
> machine that _does_ have a keyboard controller, and _does_ have a  
> keyboard
> port, and that does _not_ mention them in the PnP tables?

Except that it _does_. But _our_ ACPI implementation drops all  
inactive devices so our PNP layer does not see your mouse and keyboard  
ports.


>
>> I think this is a case where it has to be trusted, because that's  
>> what
>> Windows does.
>
> The thing is, Windows isn't used for things like headless machines.  
> Which
> we went over extensively in the thread. There's a _reason_ why Linux
> probes the dang thing.


-- 
Dmitry

Re: [git pull] Input updates for 2.6.34-rc6

[Robert Hancock]

On 05/27/2010 07:03 PM, Dmitry Torokhov wrote:
> On May 27, 2010, at 5:46 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>
>>
>>
>> On Thu, 27 May 2010, Robert Hancock wrote:
>>>
>>> It's highly unlikely that they are incomplete in this respect, as
>>> since I mentioned, Windows would fail to recognize the PS/2 controller
>>> that people would expect to work, which would most likely get
>>> noticed..
>>
>> Did you miss the part where I actually quoted my own modern Core i5
>> machine that _does_ have a keyboard controller, and _does_ have a
>> keyboard
>> port, and that does _not_ mention them in the PnP tables?
>
> Except that it _does_. But _our_ ACPI implementation drops all inactive
> devices so our PNP layer does not see your mouse and keyboard ports.

That's likely true - my machine works similarly, it doesn't list any 
keyboard or mouse controller in PnP and Windows doesn't see them if no 
device is plugged in at boot. The PnP devices for them are still 
defined, but they are marked as disabled (the _STA method in the DSDT 
returns 0). So we could likely detect that case and say "hey, the device 
is there, just turned off, maybe we should try and see if it works 
anyway". Whereas if the device is not there at all, we'd likely be 
better off leaving it alone, by default anyway.

>
>
>>
>>> I think this is a case where it has to be trusted, because that's what
>>> Windows does.
>>
>> The thing is, Windows isn't used for things like headless machines. Which
>> we went over extensively in the thread. There's a _reason_ why Linux
>> probes the dang thing.
>
>

Re: [git pull] Input updates for 2.6.34-rc6

[Dmitry Torokhov]

On Thu, May 27, 2010 at 10:05:52PM -0600, Robert Hancock wrote:
> On 05/27/2010 07:03 PM, Dmitry Torokhov wrote:
> >On May 27, 2010, at 5:46 PM, Linus Torvalds
> ><torvalds@linux-foundation.org> wrote:
> >
> >>
> >>
> >>On Thu, 27 May 2010, Robert Hancock wrote:
> >>>
> >>>It's highly unlikely that they are incomplete in this respect, as
> >>>since I mentioned, Windows would fail to recognize the PS/2 controller
> >>>that people would expect to work, which would most likely get
> >>>noticed..
> >>
> >>Did you miss the part where I actually quoted my own modern Core i5
> >>machine that _does_ have a keyboard controller, and _does_ have a
> >>keyboard
> >>port, and that does _not_ mention them in the PnP tables?
> >
> >Except that it _does_. But _our_ ACPI implementation drops all inactive
> >devices so our PNP layer does not see your mouse and keyboard ports.
> 
> That's likely true - 

This was not a guess - I have seen DSDT from Linus' box.

That is why I said I'd be happy applying Metthew's patch if our ACPI did
not drop inactive devices - it would leave Apple and newer boxes alone
while still allowing plugging in keyboard/mouse in boxes that do have
i8042 even if BIOS decided to hide it from Windows.

-- 
Dmitry

Re: [git pull] Input updates for 2.6.34-rc6

[Matthew Garrett]

I've done some experimentation under qemu. On ACPI systems, Windows will 
*only* touch the keyboard controller if there's a device with an 
appropriate PNP HID or CID and if _STA evaluates to 0x0b or 0x0f. 
Otherwise it'll simply ignore the hardware entirely. By the looks of it 
their keyboard probing is also somewhat different to ours, but that's 
probably another story.

However, I did find a couple of device IDs that machines may produce 
which we don't currently check for. I'll send a patch.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [git pull] Input updates for 2.6.34-rc6

[Linus Torvalds]

On Fri, 14 May 2010, Matthew Garrett wrote:
>
> I've done some experimentation under qemu. On ACPI systems, Windows will 
> *only* touch the keyboard controller if there's a device with an 
> appropriate PNP HID or CID and if _STA evaluates to 0x0b or 0x0f. 
> Otherwise it'll simply ignore the hardware entirely. By the looks of it 
> their keyboard probing is also somewhat different to ours, but that's 
> probably another story.

Well, I'd hate to lose the keyboard hotplug capability, but at the same 
time, it _is_ 2010, and while I have personally used it historically, I 
don't really foresee ever using it again.

So we _could_ decide to just try it, and see if anybody screams. If nobody 
does, that would be a very simple solution to the problem.

			Linus

Re: [git pull] Input updates for 2.6.34-rc6

[Dmitry Torokhov]

On Fri, May 14, 2010 at 08:16:34AM -0700, Linus Torvalds wrote:
> 
> 
> On Fri, 14 May 2010, Matthew Garrett wrote:
> >
> > I've done some experimentation under qemu. On ACPI systems, Windows will 
> > *only* touch the keyboard controller if there's a device with an 
> > appropriate PNP HID or CID and if _STA evaluates to 0x0b or 0x0f. 
> > Otherwise it'll simply ignore the hardware entirely. By the looks of it 
> > their keyboard probing is also somewhat different to ours, but that's 
> > probably another story.
> 
> Well, I'd hate to lose the keyboard hotplug capability, but at the same 
> time, it _is_ 2010, and while I have personally used it historically, I 
> don't really foresee ever using it again.
> 

FWIW we also using active multiplexing while windows does not as far as
I know. I'd like us to be better than them.

> So we _could_ decide to just try it, and see if anybody screams. If nobody 
> does, that would be a very simple solution to the problem.
> 
> 			Linus

-- 
Dmitry

Re: [git pull] Input updates for 2.6.34-rc6

[david]

On Fri, 14 May 2010, Linus Torvalds wrote:

> On Fri, 14 May 2010, Matthew Garrett wrote:
>>
>> I've done some experimentation under qemu. On ACPI systems, Windows will
>> *only* touch the keyboard controller if there's a device with an
>> appropriate PNP HID or CID and if _STA evaluates to 0x0b or 0x0f.
>> Otherwise it'll simply ignore the hardware entirely. By the looks of it
>> their keyboard probing is also somewhat different to ours, but that's
>> probably another story.
>
> Well, I'd hate to lose the keyboard hotplug capability, but at the same
> time, it _is_ 2010, and while I have personally used it historically, I
> don't really foresee ever using it again.

this is actually fairly common in datacenter environments where people 
plug in crash carts to problem machines.

yes, everything has USB ports, so they could use USB keyboards, but it's 
actually pretty common to still use PS/2 keyboards (and while the systems 
all support USB, it's not uncommon to have KVM systems, including pretty 
expensive 'enterprise' KVM systems that still require PS/2 keyboards be 
used to plug into the KVM, so those are the keyboards that are in the 
datacenter that someone will grab to plug into a problem machine)

David Lang

Re: [git pull] Input updates for 2.6.34-rc6

[Matthew Garrett]

On Fri, May 14, 2010 at 11:47:43AM -0700, david@lang.hm wrote:

> yes, everything has USB ports, so they could use USB keyboards, but it's  
> actually pretty common to still use PS/2 keyboards (and while the systems 
> all support USB, it's not uncommon to have KVM systems, including pretty  
> expensive 'enterprise' KVM systems that still require PS/2 keyboards be  
> used to plug into the KVM, so those are the keyboards that are in the  
> datacenter that someone will grab to plug into a problem machine)

The server hardware I've looked at will all declare the ports regardless 
of whether or not there's something plugged in.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [git pull] Input updates for 2.6.34-rc6

[david]

On Fri, 14 May 2010, Matthew Garrett wrote:

> On Fri, May 14, 2010 at 11:47:43AM -0700, david@lang.hm wrote:
>
>> yes, everything has USB ports, so they could use USB keyboards, but it's
>> actually pretty common to still use PS/2 keyboards (and while the systems
>> all support USB, it's not uncommon to have KVM systems, including pretty
>> expensive 'enterprise' KVM systems that still require PS/2 keyboards be
>> used to plug into the KVM, so those are the keyboards that are in the
>> datacenter that someone will grab to plug into a problem machine)
>
> The server hardware I've looked at will all declare the ports regardless
> of whether or not there's something plugged in.

remember that many people use systems in datacenters that are not 'server 
hardware'.

when a desktop PC can have 4-6 cores with 8G+ of ram and a couple TB of 
storage, a lot of people will end up using those systems for production.

As they grow into bigger companies they will shift to 'server class' 
hardware, but startups tend to use whatever they can scrounge (or buy 
_really_ cheap)

David Lang

Re: [git pull] Input updates for 2.6.34-rc6

[Matthew Garrett]

On Fri, May 14, 2010 at 11:55:43AM -0700, david@lang.hm wrote:

> remember that many people use systems in datacenters that are not 'server 
> hardware'.

And if they happen to have one of the (not terribly common) machines 
that don't claim device presence when there's no keyboard plugged in, 
they can pass the boot option.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [git pull] Input updates for 2.6.34-rc6

[david]

On Fri, 14 May 2010, david@lang.hm wrote:

> On Fri, 14 May 2010, Matthew Garrett wrote:
>
>> On Fri, May 14, 2010 at 11:47:43AM -0700, david@lang.hm wrote:
>> 
>>> yes, everything has USB ports, so they could use USB keyboards, but it's
>>> actually pretty common to still use PS/2 keyboards (and while the systems
>>> all support USB, it's not uncommon to have KVM systems, including pretty
>>> expensive 'enterprise' KVM systems that still require PS/2 keyboards be
>>> used to plug into the KVM, so those are the keyboards that are in the
>>> datacenter that someone will grab to plug into a problem machine)
>> 
>> The server hardware I've looked at will all declare the ports regardless
>> of whether or not there's something plugged in.
>
> remember that many people use systems in datacenters that are not 'server 
> hardware'.
>
> when a desktop PC can have 4-6 cores with 8G+ of ram and a couple TB of 
> storage, a lot of people will end up using those systems for production.
>
> As they grow into bigger companies they will shift to 'server class' 
> hardware, but startups tend to use whatever they can scrounge (or buy 
> _really_ cheap)

By the way, for what it's worth I think it's a very bad idea to hot-plug 
PS/2 keyboards. The hardware may be better nowadays, but back when I was a 
PC repair tech I made very good money replacing the fuses on motherboards 
that would blow because someone hot-plugged the keyboard.

That said, there are times when it happens, and many people don't see any 
problem with it.

David Lang

Re: [git pull] Input updates for 2.6.34-rc6

[Mike Frysinger]

On Fri, May 14, 2010 at 11:16, Linus Torvalds wrote:
> On Fri, 14 May 2010, Matthew Garrett wrote:
>> I've done some experimentation under qemu. On ACPI systems, Windows will
>> *only* touch the keyboard controller if there's a device with an
>> appropriate PNP HID or CID and if _STA evaluates to 0x0b or 0x0f.
>> Otherwise it'll simply ignore the hardware entirely. By the looks of it
>> their keyboard probing is also somewhat different to ours, but that's
>> probably another story.
>
> Well, I'd hate to lose the keyboard hotplug capability, but at the same
> time, it _is_ 2010, and while I have personally used it historically, I
> don't really foresee ever using it again.
>
> So we _could_ decide to just try it, and see if anybody screams. If nobody
> does, that would be a very simple solution to the problem.

i still actively use it on my linux router (normally headless and no
input), as well as my main desktop from time to time :x.  although
"actively" might not be the correct term as i dont usually have to
poke my linux router anymore ... it doesnt break very often anymore
which means i dont plug in anything at all.
-mike

Re: [git pull] Input updates for 2.6.34-rc6

[Dmitry Torokhov]

On Fri, May 14, 2010 at 08:16:34AM -0700, Linus Torvalds wrote:
> 
> 
> On Fri, 14 May 2010, Matthew Garrett wrote:
> >
> > I've done some experimentation under qemu. On ACPI systems, Windows will 
> > *only* touch the keyboard controller if there's a device with an 
> > appropriate PNP HID or CID and if _STA evaluates to 0x0b or 0x0f. 
> > Otherwise it'll simply ignore the hardware entirely. By the looks of it 
> > their keyboard probing is also somewhat different to ours, but that's 
> > probably another story.
> 
> Well, I'd hate to lose the keyboard hotplug capability, but at the same 
> time, it _is_ 2010, and while I have personally used it historically, I 
> don't really foresee ever using it again.
> 
> So we _could_ decide to just try it, and see if anybody screams. If nobody 
> does, that would be a very simple solution to the problem.
> 

OK, time to ressurect the topic ;)

There is another report (from Anisse - CCed) - MSI AE2220 stops for 10
seconds when we try to see if "AUX DISABLE" command took effect (it
doesn't). While we should reduce the time we wait and retry to something
more reasonable it woudl not fix this issue completely.

The box does not have any PS/2 ports but in this case BIOS writers _did_
some crack and put PS/2 devices in DSDT. While the devices are most
likely not active and thus Matthew's patch would help Anisse I do hate
to loose the option of plugging PS/2 mouse/keyboard after boot and
having chance of them working. I would still like to add a few blacklist
entries instead.

Thanks.

-- 
Dmitry

Re: [git pull] Input updates for 2.6.34-rc6

[Dmitry Torokhov]

On Tue, Aug 03, 2010 at 11:20:22PM -0700, Dmitry Torokhov wrote:
> On Fri, May 14, 2010 at 08:16:34AM -0700, Linus Torvalds wrote:
> > 
> > 
> > On Fri, 14 May 2010, Matthew Garrett wrote:
> > >
> > > I've done some experimentation under qemu. On ACPI systems, Windows will 
> > > *only* touch the keyboard controller if there's a device with an 
> > > appropriate PNP HID or CID and if _STA evaluates to 0x0b or 0x0f. 
> > > Otherwise it'll simply ignore the hardware entirely. By the looks of it 
> > > their keyboard probing is also somewhat different to ours, but that's 
> > > probably another story.
> > 
> > Well, I'd hate to lose the keyboard hotplug capability, but at the same 
> > time, it _is_ 2010, and while I have personally used it historically, I 
> > don't really foresee ever using it again.
> > 
> > So we _could_ decide to just try it, and see if anybody screams. If nobody 
> > does, that would be a very simple solution to the problem.
> > 
> 
> OK, time to ressurect the topic ;)
> 
> There is another report (from Anisse - CCed) - MSI AE2220 stops for 10
> seconds when we try to see if "AUX DISABLE" command took effect (it
> doesn't). While we should reduce the time we wait and retry to something
> more reasonable it woudl not fix this issue completely.
> 

Hm, I take it back.. We won't be able to reduce timeout because we don't
hit that code yet. Here is the excerpt from dmesg:

[    0.500931] drivers/input/serio/i8042.c: a7 -> i8042 (command) [9]
[    0.502950] drivers/input/serio/i8042.c: 20 -> i8042 (command) [10]
[    0.502950] drivers/input/serio/i8042.c:      -- i8042 (timeout) [10]
[   11.045100] Failed to disable AUX port, but continuing anyway... Is this a SiS?
[   11.049741] If AUX port is really absent please use the 'i8042.noaux' option.
[   11.055417] drivers/input/serio/i8042.c: a8 -> i8042 (command) [13]
[   11.057436] drivers/input/serio/i8042.c: 20 -> i8042 (command) [14]
[   11.057436] drivers/input/serio/i8042.c:      -- i8042 (timeout) [14]

We try do disable AUX and then read back the control register. We see
there isn't any data coming and then box goes away for 10 seconds.
And if we don't touch AUX port all is good...

> The box does not have any PS/2 ports but in this case BIOS writers _did_
> some crack and put PS/2 devices in DSDT. While the devices are most
> likely not active and thus Matthew's patch would help Anisse I do hate
> to loose the option of plugging PS/2 mouse/keyboard after boot and
> having chance of them working. I would still like to add a few blacklist
> entries instead.
> 

-- 
Dmitry

Re: [git pull] Input updates for 2.6.34-rc6

[Dmitry Torokhov]

On Fri, May 14, 2010 at 03:55:39PM +0100, Matthew Garrett wrote:
> I've done some experimentation under qemu. On ACPI systems, Windows will 
> *only* touch the keyboard controller if there's a device with an 
> appropriate PNP HID or CID and if _STA evaluates to 0x0b or 0x0f. 
> Otherwise it'll simply ignore the hardware entirely. By the looks of it 
> their keyboard probing is also somewhat different to ours, but that's 
> probably another story.
> 
> However, I did find a couple of device IDs that machines may produce 
> which we don't currently check for. I'll send a patch.
> 

I was wondering if we should be matching for _CID instead of _HID for
mouse and keyboard.

-- 
Dmitry

Re: [git pull] Input updates for 2.6.34-rc6

[Matthew Garrett]

On Fri, May 14, 2010 at 09:29:52AM -0700, Dmitry Torokhov wrote:
> On Fri, May 14, 2010 at 03:55:39PM +0100, Matthew Garrett wrote:
> > I've done some experimentation under qemu. On ACPI systems, Windows will 
> > *only* touch the keyboard controller if there's a device with an 
> > appropriate PNP HID or CID and if _STA evaluates to 0x0b or 0x0f. 
> > Otherwise it'll simply ignore the hardware entirely. By the looks of it 
> > their keyboard probing is also somewhat different to ours, but that's 
> > probably another story.
> > 
> > However, I did find a couple of device IDs that machines may produce 
> > which we don't currently check for. I'll send a patch.
> > 
> 
> I was wondering if we should be matching for _CID instead of _HID for
> mouse and keyboard.

I'm pretty sure the PNP layer will bind to either _HID or _CID.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

[git pull] Input updates for 2.6.34-rc6

[Dmitry Torokhov]

Hi Linus,

Please pull from:

	git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
or
	master.kernel.org:/pub/scm/linux/kernel/git/dtor/input.git for-linus

to receive updates for the input subsystem. Nothing super exciting but
owners of newer touchpads will get a bit happier.

Changelog:
---------

Christoph Fritz (1):
      Input: joydev - allow binding to button-only devices

Daniel Mack (1):
      Input: eeti_ts - cancel pending work when going to suspend

Dmitry Torokhov (2):
      Input: psmouse - ignore parity error for basic protocols
      Revert "Input: ALPS - add signature for HP Pavilion dm3 laptops"

Florian Ragwitz (3):
      Input: elantech - fix firmware version check
      Input: elantech - allow forcing Elantech protocol
      Input: elantech - ignore high bits in the position coordinates

Jarod Wilson (1):
      Input: ati_remote - add some missing devices from lirc_atiusb

Takashi Iwai (1):
      Input: Add support of Synaptics Clickpad device


Diffstat:
--------

 Documentation/input/elantech.txt    |    8 ++--
 drivers/input/joydev.c              |   18 +++++++
 drivers/input/misc/ati_remote.c     |   14 ++++--
 drivers/input/mouse/alps.c          |    1 -
 drivers/input/mouse/elantech.c      |   84 +++++++++++++++++++++++------------
 drivers/input/mouse/psmouse-base.c  |   18 ++++++-
 drivers/input/mouse/psmouse.h       |    1 +
 drivers/input/mouse/synaptics.c     |   35 ++++++++++++--
 drivers/input/mouse/synaptics.h     |    4 ++
 drivers/input/touchscreen/eeti_ts.c |   56 +++++++++++++++++++----
 10 files changed, 183 insertions(+), 56 deletions(-)

-- 
Dmitry