From: Dmitry Torokhov on
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


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
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
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
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/