Input updates for 2.6.34-rc6
in [Kernel]
|
Prev: HWPOISON for hugepage (v5)
Next: gta02: Use pcf50633 backlight driver instead of platform backlight driver.
From: Dmitry Torokhov on 13 May 2010 17:10 On Thursday 13 May 2010 12:40:43 pm Linus Torvalds wrote: > On Thu, 13 May 2010, Dmitry Torokhov wrote: > > You don't have anything plugged into the ports though, do you? > > No. It's a modern machine. But the port is there, and we've been very good > at booting up and finding keyboards later (I've done it myself - headless > machines that you hotplug a PS/2 keyboard into: it's not necessarily > technically something you're supposed to do, but it has worked fine for > me). > > > I wonder what your DSDT looks like. [... 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 13 May 2010 17:30 On Thu, 13 May 2010, Dmitry Torokhov wrote: > > 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? 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Matthew Garrett on 13 May 2010 19:50 On Thu, May 13, 2010 at 02:05:44PM -0700, Dmitry Torokhov wrote: > 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? Yeah, if _STA gives you 0 then the device won't be visible. That may not be optimal in this case. -- Matthew Garrett | mjg59(a)srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Eric W. Biederman on 14 May 2010 04:00 Linus Torvalds <torvalds(a)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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Matthew Garrett on 14 May 2010 11:00
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(a)srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |