login
Search
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
--
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 --
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. --
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 --
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 --
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 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 --
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 --
From Jan. 20, on lkml. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** --
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 --
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 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, -- Dmitry --
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 --
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 --
I think on the newer hardware PNP (or rather ACPI mapped onto PNP) usually 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 Well, they got PNP tables right ;) -- Dmitry --
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 --
You don't have anything plugged into the ports though, do you? I wonder Is there an interface a driver can use to query the style of boot used? -- Dmitry --
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 --
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 --
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 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 --
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 --
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 --
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 --
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 --
[... pulling LKML back in...]
Lookie, lookie:
Device (PS2K)
{
Name (_HID, EisaId ("PNP0303"))
Name (_CID, EisaId ("PNP030B"))
Method (_STA, 0, NotSerialized)
{
ShiftLeft (One, 0x0A, Local0)
If (And (IOST, Local0))
{
Return (0x0F)
}
Return (Zero)
}
...
Device (PS2M)
{
Name (_HID, EisaId ("PNP0F03"))
Name (_CID, EisaId ("PNP0F13"))
Method (_STA, 0, NotSerialized)
{
But I guess because there are no devices plugged in ACPI they are "inactive"
and thus ACPI drop them. I was always wondered by ACPI did that. Len?
--
Dmitry
--
Btw, even without actual physically plugging in the device, at least the really early KVM boxes used to basically just _physically_ switch between keyboard ports, and so using such a KVM switch is essentially also going to plug it in after boot time. Some slightly more fancier KVM devices (probably most of them by now - if you want auto-switching etc) have real electronics and actually emulate a keyboard, needed for computers that require a keyboard to even boot up ("Keyboard not detected. Press F1 to continue"). But the hard-switching ones were at least at some point way more reliable: the "smart" ones would have trouble with any "fancy" features like scroll-wheels etc. Probably not an issue any more. Of course, these days few people use PS/2 keyboards any more, but it would still be a shame to break a perfectly reasonable setup. Linus --
Yeah, if _STA gives you 0 then the device won't be visible. That may not be optimal in this case. -- Matthew Garrett | mjg59@srcf.ucam.org --
I guess only a Windows person could answer this -- since it is really a Windows-ism, rather than something that makes any sense based on what is in the ACPI spec itself. cheers, Len Brown, Intel Open Source Technology Center --
Then we should probably revisit this? I am not saying that we need to try evaluating more than Windows does but we still should add the devices into the tree so their presence can be detected. -- Dmitry --
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 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 --
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 --
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, 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 ...
On Thu, May 27, 2010 at 11:06 AM, Linus Torvalds 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 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 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.. --
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 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 --
On May 27, 2010, at 5:46 PM, Linus Torvalds <torvalds@linux-foundation.org Except that it _does_. But _our_ ACPI implementation drops all inactive devices so our PNP layer does not see your mouse and keyboard -- Dmitry --
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 --
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 --
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 --
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 --
FWIW we also using active multiplexing while windows does not as far as -- Dmitry --
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 --
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 --
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 --
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 --
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 --
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 --
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 --
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. -- Dmitry --
I was wondering if we should be matching for _CID instead of _HID for mouse and keyboard. -- Dmitry --
I'm pretty sure the PNP layer will bind to either _HID or _CID. -- Matthew Garrett | mjg59@srcf.ucam.org --
