View Single Post
  #3   (View Single Post)  
Old 7th October 2011
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,983
Default

Poking through CVS logs, I did not find anything directly addressing your question. I found the following patches.

1) USB keyboard support was initially added for ddb(4) in 2001:
Code:
CVSROOT:    /cvs
Module name:    src
Changes by:    drahn@cvs.openbsd.org    2001/10/25 09:20:07

Modified files:
    sys/dev/usb    : ukbd.c 

Log message:
ddb entry support using usb (console) keyboard.
Do not send characters directly from usb interrupt handler for
console keyboard. entering ddb from within the usb interrupt handler
is _bad_. Instead delay until next timeout check and deliver characters
then. Tested on mappc.
From NetBSD.
Support for usb keyboard management for i386/amd64 architectures without PS/2 keyboard interfaces was put in place in 2009:
Code:
CVSROOT:    /cvs
Module name:    src
Changes by:    miod@cvs.openbsd.org    2009/08/25 13:16:36

Modified files:
    sys/arch/amd64/amd64: wscons_machdep.c 
    sys/arch/i386/i386: wscons_machdep.c 
    sys/dev/ic     : pckbc.c 
    sys/dev/pckbc  : pckbd.c 

Log message:
Legacy-free PC hardware do not have a real PS/2 keyboard controller, but
rather have the USB HCI emulate it during boot, while legacy mode is enabled.

This causes pckbd0 to attach as the console device, but is lost as soon as
the USB HCI driver attaches.

The disappearance of the emulated PS/2 controller can however be detected
in pckbc(4) - which is supposed to attach after [eou]hci(4), with the controller
refusing to ack commands and replying ``please resend'' instead.

In that case, the kernel will now no longer attach pckbd, and will perform a
new console input device selection, allowing the (real) usb keyboard to
become the console.

Thanks to krw@ for countless tests on legacy-free hardware; also tested on
more conventional hardware by naddy@ and I.

Only amd64 and i386 platforms are affected by this change.
If you have the time, you should test with -current; it may be that your problem has already been addressed. If not, a complete problem report will be accepted by the Project. Use misc@ for informal queries, bugs@ for a formal report. FYI: the Project's problem reporting database is currently offline and is not expected to return.

http://www.openbsd.org/report.html
http://www.openbsd.org/mail.html

Edited to add: For formal reporting, since the database (gnats@) is inoperative, if this were me I would use sendbug(1) but manually edit the template, then post the result to bugs@ via Email.
Code:
# sendbug -P > myreport
# $EDITOR myreport
# grep -v SENDBUG myreport > final.report.for.mailing

Last edited by jggimi; 7th October 2011 at 10:25 PM.
Reply With Quote