Author Topic: USB - boot mode, NKRO, compatibility, etc... (Read 21422 times)

Soarer · « **on:** Fri, 03 December 2010, 10:20:42 »

I've been coding a Teensy based PS/2 to USB converter, and experimenting with different ways of structuring the reports that it sends. A lot of what I've done has been tried already, and I'm still finding relevant info on here that I haven't read before, but maybe some of this is new info. :-)

(I'm thinking about adding a wiki page to collect wisdom on this subject, probably with a similar title to this thread. To begin with, it may be little more than a glorified list of bookmarks, but that will be useful in itself because searching doesn't work very well for finding all the useful tidbits that have been posted in the past).

I tried simply making the reports longer by adding more bytes for key data, but this suffers from a bug in Windows. The bug also affects standard 6-key reports, as well as any with the same style but longer.

Anyway, once you get up to using a 23 byte report, there's enough space to store a complete array of bits, one bit per valid USB key code. So I tried that, and it works well. If the above bug affects it, it's not until you press a truly ridiculous number of keys.

But then there's boot compatibilty to consider... on my PC, with a nice modern BIOS, it's no problem. Its BIOS sends a SetProtocol command at the right time, and the adapter can use that to know which style of report to send. A few members have already been testing a Teensy++ based adapter on various PCs with mixed results (Kishy has a list of some).

One thing I discovered was that my BIOS doesn't care if the report is longer than 8 bytes, it simply ignores the rest. That might point the way towards slightly higher compatibility, with the following workaround (for cases where the BIOS doesn't issue a SetProtocol command, or gets it wrong)...

The report sent would consist of 32 bytes, with the standard boot mode 8 byte report first, followed by a complete bitmap of the USB codes (from 1 to 0xA0) and some padding.

The report descriptor, however, would define the report with the 6 key code slots of the boot mode section marked as 'constant'. That way the adapter can still fill them out, but a full HID stack would ignore them.

I'm going to code that up later and try it out on my PCs. They're all relatively recent though, so I'll probably have to deliberately ignore the SetProtocol command to test the kludged method.

Has anyone tried similar before?

woody · « **Reply #1 on:** Fri, 03 December 2010, 10:30:52 »

Quote from: ripster;256304

Isn't there a way to reverse engineer a Sidewinder X4?

Dump descriptors and decode them.

The method that Soarer suggests is creative, but it might fail because of the assumption that all BIOSes and likely embedded devices will read, yet ignore past the 8th byte.

Soarer · « **Reply #2 on:** Fri, 03 December 2010, 10:45:38 »

Well.. while I was quite impressed by Paul coming on here and being pretty open about the X4's limitations (and basically admitting the Windows bug, compared to the X4 FAQ page which blamed problems on 'some programs'), I'm not sure the X4's way of doing things is the best. For one thing, I don't think we know for sure whether it would actually work fine with a BIOS that doesn't send the SetProtocol command.

It would be interesting to find out though.

Soarer · « **Reply #3 on:** Fri, 03 December 2010, 10:56:00 »

Quote from: woody;256310

Dump descriptors and decode them.

Is there an easy way to do that?

Quote from: woody;256310

The method that Soarer suggests is creative, but it might fail because of the assumption that all BIOSes and likely embedded devices will read, yet ignore past the 8th byte.

I don't assume that all BIOS will cope with it, but hope that more will than just those that correctly send SetProtocol. And if that then includes most I'd be happy (as would most people, I guess).

I suspect that the PCs tested that failed by giving random keystrokes in the BIOS were accepting longer packets but interpreting them wrongly. They might well be fixed by this kludge.

In fact, I think that's the main thing we'd want to avoid... random BIOS manipulation... eeek!

woody · « **Reply #4 on:** Fri, 03 December 2010, 11:15:22 »

Quote from: Soarer;256331

Is there an easy way to do that?

On windows - dunno. I'll see whether "lsusb" dumps HID descriptors for linux.

Soarer · « **Reply #5 on:** Fri, 03 December 2010, 11:22:09 »

Cheers. Not that I actually have an X4 to test out.... who has one?

Actually, the first step in Windows would just be to find out what it shows up as in device manager - HID keyboard, two HID keyboards, HID composite device, or ...

edit: apparently, one HID keyboard. I guess that means it's not pretending to be two keyboards then.

Findecanor · « **Reply #6 on:** Fri, 03 December 2010, 12:01:13 »

Quote from: Soarer;256301

But then there's boot compatibilty to consider... on my PC, with a nice modern BIOS, it's no problem.

Yep, but not all "modern" PCs come with a modern BIOS. The BIOS in my Asus EeeBox of this year's model stays in boot mode... and none of my adapters support it, meaning that I can not use any of my PS/2 keyboards to change BIOS settings or even the boot menu.
On my HP PC at work: no problem at all.

woody · « **Reply #7 on:** Fri, 03 December 2010, 12:05:14 »

About dumping descriptors - found this one:
http://www.microchip.com/forums/tm.aspx?m=364987

EDIT: Here's output from G84-4400

Code: [Select]

Bus 002 Device 002: ID 046a:0008 Cherry GmbH 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0x046a Cherry GmbH
  idProduct          0x0008 
  bcdDevice            1.00
  iManufacturer           1 Cherry GmbH
  iProduct                2 Cherry Slim Line Trackball Keyboard
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           59
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      1 Boot Interface Subclass
      bInterfaceProtocol      1 Keyboard
      iInterface              0 
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.00
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      63
          Report Descriptor: (length is 63)
            Item(Global): Usage Page, data= [ 0x01 ] 1
                            Generic Desktop Controls
            Item(Local ): Usage, data= [ 0x06 ] 6
                            Keyboard
            Item(Main  ): Collection, data= [ 0x01 ] 1
                            Application
            Item(Global): Usage Page, data= [ 0x07 ] 7
                            Keyboard
            Item(Local ): Usage Minimum, data= [ 0xe0 ] 224
                            Control Left
            Item(Local ): Usage Maximum, data= [ 0xe7 ] 231
                            GUI Right
            Item(Global): Logical Minimum, data= [ 0x00 ] 0
            Item(Global): Logical Maximum, data= [ 0x01 ] 1
            Item(Global): Report Size, data= [ 0x01 ] 1
            Item(Global): Report Count, data= [ 0x08 ] 8
            Item(Main  ): Input, data= [ 0x02 ] 2
                            Data Variable Absolute No_Wrap Linear
                            Preferred_State No_Null_Position Non_Volatile Bitfield
            Item(Global): Report Count, data= [ 0x08 ] 8
            Item(Global): Report Size, data= [ 0x01 ] 1
            Item(Main  ): Input, data= [ 0x01 ] 1
                            Constant Array Absolute No_Wrap Linear
                            Preferred_State No_Null_Position Non_Volatile Bitfield
            Item(Global): Usage Page, data= [ 0x08 ] 8
                            LEDs
            Item(Local ): Usage Minimum, data= [ 0x01 ] 1
                            NumLock
            Item(Local ): Usage Maximum, data= [ 0x03 ] 3
                            Scroll Lock
            Item(Global): Report Count, data= [ 0x03 ] 3
            Item(Global): Report Size, data= [ 0x01 ] 1
            Item(Main  ): Output, data= [ 0x02 ] 2
                            Data Variable Absolute No_Wrap Linear
                            Preferred_State No_Null_Position Non_Volatile Bitfield
            Item(Global): Report Count, data= [ 0x01 ] 1
            Item(Global): Report Size, data= [ 0x05 ] 5
            Item(Main  ): Output, data= [ 0x01 ] 1
                            Constant Array Absolute No_Wrap Linear
                            Preferred_State No_Null_Position Non_Volatile Bitfield
            Item(Global): Usage Page, data= [ 0x07 ] 7
                            Keyboard
            Item(Local ): Usage Minimum, data= [ 0x00 ] 0
                            No Event
            Item(Local ): Usage Maximum, data= [ 0x68 ] 104
                            F13
            Item(Global): Logical Minimum, data= [ 0x00 ] 0
            Item(Global): Logical Maximum, data= [ 0x68 ] 104
            Item(Global): Report Count, data= [ 0x06 ] 6
            Item(Global): Report Size, data= [ 0x08 ] 8
            Item(Main  ): Input, data= [ 0x00 ] 0
                            Data Array Absolute No_Wrap Linear
                            Preferred_State No_Null_Position Non_Volatile Bitfield
            Item(Main  ): End Collection, data=none
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval              12
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      1 Boot Interface Subclass
      bInterfaceProtocol      2 Mouse
      iInterface              0 
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.00
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      50
          Report Descriptor: (length is 50)
            Item(Global): Usage Page, data= [ 0x01 ] 1
                            Generic Desktop Controls
            Item(Local ): Usage, data= [ 0x02 ] 2
                            Mouse
            Item(Main  ): Collection, data= [ 0x01 ] 1
                            Application
            Item(Local ): Usage, data= [ 0x01 ] 1
                            Pointer
            Item(Main  ): Collection, data= [ 0x00 ] 0
                            Physical
            Item(Global): Usage Page, data= [ 0x09 ] 9
                            Buttons
            Item(Local ): Usage Minimum, data= [ 0x01 ] 1
                            Button 1 (Primary)
            Item(Local ): Usage Maximum, data= [ 0x03 ] 3
                            Button 3 (Tertiary)
            Item(Global): Logical Minimum, data= [ 0x00 ] 0
            Item(Global): Logical Maximum, data= [ 0x01 ] 1
            Item(Global): Report Count, data= [ 0x03 ] 3
            Item(Global): Report Size, data= [ 0x01 ] 1
            Item(Main  ): Input, data= [ 0x02 ] 2
                            Data Variable Absolute No_Wrap Linear
                            Preferred_State No_Null_Position Non_Volatile Bitfield
            Item(Global): Report Count, data= [ 0x01 ] 1
            Item(Global): Report Size, data= [ 0x05 ] 5
            Item(Main  ): Input, data= [ 0x01 ] 1
                            Constant Array Absolute No_Wrap Linear
                            Preferred_State No_Null_Position Non_Volatile Bitfield
            Item(Global): Usage Page, data= [ 0x01 ] 1
                            Generic Desktop Controls
            Item(Local ): Usage, data= [ 0x30 ] 48
                            Direction-X
            Item(Local ): Usage, data= [ 0x31 ] 49
                            Direction-Y
            Item(Global): Logical Minimum, data= [ 0x81 ] 129
            Item(Global): Logical Maximum, data= [ 0x7f ] 127
            Item(Global): Report Count, data= [ 0x02 ] 2
            Item(Global): Report Size, data= [ 0x08 ] 8
            Item(Main  ): Input, data= [ 0x06 ] 6
                            Data Variable Relative No_Wrap Linear
                            Preferred_State No_Null_Position Non_Volatile Bitfield
            Item(Main  ): End Collection, data=none
            Item(Main  ): End Collection, data=none
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval              12
Device Status:     0x0000
  (Bus Powered)

Soarer · « **Reply #8 on:** Fri, 03 December 2010, 12:14:36 »

Quote from: Findecanor;256373

Yep, but not all "modern" PCs come with a modern BIOS. The BIOS in my Asus EeeBox of this year's model stays in boot mode... and none of my adapters support it, meaning that I can not use any of my PS/2 keyboards to change BIOS settings or even the boot menu.
On my HP PC at work: no problem at all.

That sounds like a different problem - perhaps it doesn't like the way adapters present themselves as a keyboard + mouse combination?

Soarer · « **Reply #9 on:** Fri, 03 December 2010, 12:35:18 »

Quote from: woody;256374

About dumping descriptors - found this one:
http://www.microchip.com/forums/tm.aspx?m=364987

EDIT: Here's output from G84-4400

Thanks. That's cool, it's got everything! I guess that's 'lsusb -v'...
I just tried UCVView on Windows but it doesn't give the report descriptors :-(

Findecanor · « **Reply #10 on:** Fri, 03 December 2010, 12:35:59 »

Well, it does not work with my Blue Cube either ... The "Blue Cube" being only for the keyboard.
And, would keyboard + mouse combination be any different from having a hub with two USB devices plugged in?

woody · « **Reply #11 on:** Fri, 03 December 2010, 12:49:30 »

Quote from: Soarer;256386

I guess that's 'lsusb -v'...

Yes. You just have to detach the interfaces or you won't be seeing the report descriptors.

Soarer · « **Reply #12 on:** Fri, 03 December 2010, 12:53:23 »

Quote from: Findecanor;256389

Well, it does not work with my Blue Cube either ... The "Blue Cube" being only for the keyboard.

Actually, the blue cube is a composite device, it just doesn't have a mouse socket :-)

Quote from: Findecanor;256389

And, would keyboard + mouse combination be any different from having a hub with two USB devices plugged in?

Yes. (longer answer is long!)

Soarer · « **Reply #13 on:** Fri, 03 December 2010, 22:28:27 »

Quote from: woody;256402

Yes. You just have to detach the interfaces or you won't be seeing the report descriptors.

I remembered that I had an OpenPeak Joggler, along with an SD card with Ubuntu, so I gave it a try. Hmm. Couldn't figure that out, it gave me the vague 'authentication token' error when trying to set the root password.

Then I tried a live CD of Damn Small Linux, but on that /sys/bus/ wasn't there.

lsusb was working fine on both (just not listing report descriptors).

So was the adapter, it was at least doing >6KRO.

So I gave up on that - it can wait until we have a victim with an X4 who's prepared to play

......

Tested a couple of machines for boot compatibility with the combi report:
Shuttle SK41G (Athlon XP, Award): works, and also works if SetProtocol is ignored
Asus eee PC 900 (Celeron M, AMI v2.58): works, does not work if SetProtocol is ignored

The adapter has sprouted some switches and a button!
Switch 1 - always use boot mode
Switch 2 - ignore SetProtocol commands (for testing)
Button - switch to boot mode (as if SetProtocol(0) command was recvd)

After pressing the button, it will work with ALL USB supporting BIOS, and then switch back to NKRO mode when the OS resets it. I'm tempted to say that's 'good enough'...

Soarer · « **Reply #14 on:** Sat, 04 December 2010, 13:16:14 »

Tested a few more machines in boot mode today... it worked on all of them :-)

IF the long report didn't begin with the standard boot mode report, then the two machines that didn't send a SetProtocol would've failed.

Two machines didn't accept long reports - I guess it's just chance that they happened to be ones that corrrectly sent a SetProtocol.

Code: [Select]

Machine or motherboard         Sends          Accepts      So...
  BIOS info                    SetProtocol    oversize     does it
  CPU info                     command?       reports?     work?
-------------------------------------------------------------------
DFI BloodIron P45-T2RS           Yes            Yes          Yes
  Phoenix Award v6.00PG
  Core 2 Quad Q9550 2.83GHz
-------------------------------------------------------------------
Dell Latitude D800               No             Yes          Yes
  Phoenix/Dell v.A11
  Pentium M 1.8GHz
-------------------------------------------------------------------
Shuttle SK41G (VIA KM266)        Yes            Yes          Yes
  Phoenix Award v6.00PG
  Athlon XP 2200+  
-------------------------------------------------------------------
ASUS eee PC 900                  Yes            No           Yes
  AMI v2.58
  Celeron M
-------------------------------------------------------------------
Gigabyte BX2000                  No             Yes          Yes
  Award Modular v4.51PG
  Celeron 850MHz
-------------------------------------------------------------------
Dell PowerEdge SC440             Yes            No [1]       Yes
  (Dell) v1.5.0
  Pentium E2180 2GHz
-------------------------------------------------------------------
DFI LanParty (nForce 4 Ultra)    Yes            Yes          Yes
  Phoenix Award v6.00PG
  Athlon X2 4200+
-------------------------------------------------------------------
Dell XPS 420                     Yes            Yes          Yes
  (Dell) A07
  Core 2 Quad Q6600 2.4GHz
--------------------------------------------------------------------
[1] hung when a key was pressed.

Overall, quite pleased with that straw poll. :-)
Of course there's likely to be machines out there that neither send SetProtocol, nor accept oversize reports, but this does show that compatibility is improved by having the boot mode report at the start of the long report.

But... when testing oversize reports, the SC440 hung when a key was pressed. It had sent a SetProtocol though, so normally the adapter would've switched to sending an 8 byte report. It was only by ignoring SetProtocol that I was able to test what happened with the oversize report. Presumably, a buffer overrun. :-(

JBert · « **Reply #15 on:** Sat, 04 December 2010, 18:26:52 »

Wait, do you use the "bit-mode descriptor" or the "extended legacy descriptor" for the default protocol?

Those BIOSes which don't send SetProtocol *could* have a lightweight USB HID stack on board. If this is true, you could still go for the dual report format option (the way the USB HID spec was intended).

Soarer · « **Reply #16 on:** Sat, 04 December 2010, 19:31:48 »

Quote from: JBert;257152

Wait, do you use the "bit-mode descriptor" or the "extended legacy descriptor" for the default protocol?

Default being the full NKRO protocol, it's both:

Quote from: Soarer;256301

The report sent would consist of 32 bytes, with the standard boot mode 8 byte report first, followed by a complete bitmap of the USB codes (from 1 to 0xA0) and some padding.

The report descriptor, however, would define the report with the 6 key code slots of the boot mode section marked as 'constant'. That way the adapter can still fill them out, but a full HID stack would ignore them.

That's pretty much what I've been trying out, except it's actually 164 bits in the bitmap, and a total of 29 bytes. edit: counted wrong, it's 32 bytes (there's 3 bytes of padding on the end).

Quote from: JBert;257152

Those BIOSes which don't send SetProtocol *could* have a lightweight USB HID stack on board. If this is true, you could still go for the dual report format option (the way the USB HID spec was intended).

The way the spec was intended, BIOSes would all send SetProtocol!! If they do, I only send the boot mode 8 byte report. I might well try out multiple endpoints sometime, but I've got no way to properly verify that it works here, since no machine failed to send SetProtocol AND failed to accept oversize reports :-/ I think the extent of a BIOS's HID stack is limited to scanning the configuration descriptor until it sees an interface with the boot keyboard flags set, then hooking an endpoint up to it.

Soarer · « **Reply #17 on:** Sat, 04 December 2010, 22:57:12 »

Two endpoints works :-) as in, if the adapter deliberately ignores SetProtocol, the keyboard still works in the BIOS (of the Dell SC440 that failed this test before, at least). In fact, with this method, there's no need to behave any differently w.r.t. the protocol that is set.

This is how I've set it up...

The two endpoints have an 'interface' each, because it's there that the boot compatible flags are set.

First interface is marked as boot compatible. Report descriptor is defined as all padding, so the OS will ignore its data. Data sent is standard 8 bytes. BIOS reads this.

Second is not marked as boot compatible. It sends a packet with a copy of the modifier byte, plus the bitmap of all keys from 1 to 0xA4, plus padding. The report descriptor correctly defines this packet, so the OS can read it. It's 22 bytes.

I'd post the code but it's a right mess of conditional compilation directives at the moment, what with trying different things out. And I have to choose - do I tidy this PJRC code up and add suspend support to it, or do I move to using LUFA?

woody · « **Reply #18 on:** Sun, 05 December 2010, 07:49:07 »

Quote from: Soarer;256756

lsusb was working fine on both (just not listing report descriptors).

If your main keyboard is PS/2, or you have some other means of control (ssh), you could just "rmmod usbhid" and the likes. Of course if they were compiled as modules. Worked for me.

EDIT: So the two interface approach works with everything? That's good news. What a hodge-podge they created out of a simple thing like keyboard.

Soarer · « **Reply #19 on:** Sun, 05 December 2010, 08:21:38 »

Quote from: woody;257465

If your main keyboard is PS/2, or you have some other means of control (ssh), you could just "rmmod usbhid" and the likes. Of course if they were compiled as modules. Worked for me.

On Damn Small Linux, it seems they aren't

I'll try a different live cd later - any suggestions which?
At least that command is a lot simpler than figuring out which bus, port, configuration and interface to unbind! That'll help persuade a guinea pig to give it a try

EDIT: figured it out... on DSL I just needed to do 'rmmod hid' - then I see report descriptors

Quote from: woody;257465

EDIT: So the two interface approach works with everything? That's good news. What a hodge-podge they created out of a simple thing like keyboard.

I dunno, I don't have everything! Sure looks like it would, or at least it's about as compatible as you can get. I'll make it so the NKRO data isn't sent over the second endpoint when the first endpoint has been told to use boot mode - I doubt that makes any difference, but it'll be one less thing that might confuse a bios.

The only downside is that it makes it a composite device - which is what appears to confuse Findecanor's eee Box. Maybe some DIP switches are in order after all, to switch between the different methods.

JBert · « **Reply #20 on:** Sun, 05 December 2010, 08:38:35 »

Quote from: Soarer;257191

The way the spec was intended, BIOSes would all send SetProtocol!! If they do, I only send the boot mode 8 byte report. I might well try out multiple endpoints sometime, but I've got no way to properly verify that it works here, since no machine failed to send SetProtocol AND failed to accept oversize reports :-/ I think the extent of a BIOS's HID stack is limited to scanning the configuration descriptor until it sees an interface with the boot keyboard flags set, then hooking an endpoint up to it.

Actually, you're reading it backwards: SetProtocol was added to the spec so that BIOSes didn't need to include a full Report descriptor parser and could just run off a very strictly defined report by putting the keyboard in boot mode. If the BIOS authors were crazy enough to put a full-fledged USB stack in their code, they would never need to call SetProtocol.

It is unlikely though, so that's why I want to know if those BIOSes which don't send SetProtocol can actually use the bit-only report.

woody · « **Reply #21 on:** Sun, 05 December 2010, 08:52:09 »

Quote from: Soarer;257467

EDIT: figured it out... on DSL I just needed to do 'rmmod hid' - then I see report descriptors

Yup, that's the "and the likes" part I mentioned.

Quote

The only downside is that it makes it a composite device - which is what appears to confuse Findecanor's eee Box.

Filco's Holtek MCU presents itself as a composite keyboard/mouse, as others I've checked do, too. Is it the specific case of two keyboard interfaces that stumbles EEE box? I suppose you meant the BIOS on EEE box.

Soarer · « **Reply #22 on:** Sun, 05 December 2010, 09:01:08 »

Quote from: JBert;257472

Actually, you're reading it backwards: SetProtocol was added to the spec so that BIOSes didn't need to include a full Report descriptor parser and could just run off a very strictly defined report by putting the keyboard in boot mode. If the BIOS authors were crazy enough to put a full-fledged USB stack in their code, they would never need to call SetProtocol.

It is unlikely though, so that's why I want to know if those BIOSes which don't send SetProtocol can actually use the bit-only report.

I don't think I am reading it backwards, I just don't believe that any BIOS with a full HID stack exists! So I didn't bother qualifying what I said explicitly, perhaps I should've said:

Quote from: Soarer;257191

The way the spec was intended, BIOSes would all send SetProtocol when required!! If they do, I only send the boot mode 8 byte report. I might well try out multiple endpoints sometime, but I've got no way to properly verify that it works here, since no machine failed to send SetProtocol AND failed to accept oversize reports :-/ I think the extent of a typical BIOS's HID stack is limited to scanning the configuration descriptor until it sees an interface with the boot keyboard flags set, then hooking an endpoint up to it.

Although, IF a bios did parse the report descriptors, it would end up reading the bitmap of keys I guess.

Soarer · « **Reply #23 on:** Sun, 05 December 2010, 09:06:38 »

Quote from: woody;257475

Filco's Holtek MCU presents itself as a composite keyboard/mouse, as others I've checked do, too. Is it the specific case of two keyboard interfaces that stumbles EEE box? I suppose you meant the BIOS on EEE box.

Yep, the BIOS. It's a blue cube that does it (keyboard and mouse, despite not having a mouse socket). Maybe it's peculiar to the blue cube - the mouse part could be breaking it, if it's not fully implemented. (Just guessing, no idea really).

woody · « **Reply #24 on:** Sun, 05 December 2010, 09:33:30 »

There will always be broken firmware. Don't get worried too much about it.
I had to live in pain with broken BIOS on ASUS board for more than half a year, before they released something better. Stupid advice, but just check for newer BIOS.

Soarer · « **Reply #25 on:** Sun, 05 December 2010, 09:48:09 »

Quote from: woody;257505

There will always be broken firmware. Don't get worried too much about it.
I had to live in pain with broken BIOS on ASUS board for more than half a year, before they released something better. Stupid advice, but just check for newer BIOS.

Oh, I won't

Can't second guess every possible bug in the bios, after all.

hasu · « **Reply #26 on:** Wed, 08 December 2010, 23:10:46 »

Quote from: Soarer;256301

(I'm thinking about adding a wiki page to collect wisdom on this subject, probably with a similar title to this thread. To begin with, it may be little more than a glorified list of bookmarks, but that will be useful in itself because searching doesn't work very well for finding all the useful tidbits that have been posted in the past).

It is nice.
We should have a wiki page to share information with others.
It will help people to understand USB NKRO.

This is my memo about USB NKRO at this time.

Code: [Select]


USB NKRO MEMO
=============
2010/12/09


References
----------
USB - boot mode, NKRO, compatibility, etc...
    http://geekhack.org/showthread.php?t=13162
NKey Rollover - Overview, Testing Methodology, and Results
    http://geekhack.org/showwiki.php?title=NKey+Rollover+-+Overview+Testing+Methodology+and+Results
dfj's NKRO(2010/06)
    http://geekhack.org/showpost.php?p=191195&postcount=251
    http://geekhack.org/showthread.php?p=204389#post204389


Terminogy
---------
NKRO
ghost
matrix
mechanical with diodes
membrane


OS Support Status
-----------------
USB NKRO is possible *without* a custom driver.
At least following OSes supports.
    Windows7 64bit
    WindowsXP
    Windows2000 SP4
    Ubuntu10.4(Linux 2.6)
    MacOSX(To be tested)


Custom Driver for USB NKRO
--------------------------
NOT NEEDED
at least when using fllowing report formats on Windows, Linux or MacOSX.


USB NKRO methods
----------------
1. Virtual keyboards
    Keyboard can increase its KRO by using virtual keyboards with Standard or Extended report.
    If the keyboard has 2 virtual keyboard with Standard report(6KRO), it gets 12KRO.
    Using this method means the keyboard is a composite device.

2. Exteded report
    It needs large report size for this method to achive NKRO.
    If a keyboard has 101keys, it needs 103byte report. It seems to be inefficient.

3. Bitmap report
    If the keyboard has less than 128keys, 16byte report will be enough for NKRO.
    The 16byte report seems to be reasonable cost to get NKRO.


Report Format
-------------
Other report formats than followings are possible, though these format are typical one.

1. Standard             8bytes
    modifiers(bitmap)       1byte
    reserved                1byte(not used)
    keys(array)             1byte*6
Standard report can send 6keys plus 8modifiers simultaneously.
Standard report is used by most keyboards in the marketplace.
Standard report is identical to boot protocol report.
Standard report is hard to suffer from compatibility problems.

2. Extended standard    16,32,64bytes
    modifiers(bitmap)       1byte
    reserved                1byte(not used)
    keys(array)             1byte*(14,32,62)
Extended report can send N-keys by using N+2bytes.
Extended report is expected to be compatible with boot protocol.

3. Bitmap               16,32,64bytes
    keys(bitmap)            (16,32)bytes
Bitmap report can send at most 128keys by 16bytes and 256keys by 32bytes.
Bitmap report can achieve USB NKRO efficiently in terms of report size.
Bitmap report needs a deliberation for boot protocol implementation.
Bitmap report descriptor sample:
        0x05, 0x01,                     // Usage Page (Generic Desktop),
        0x09, 0x06,                     // Usage (Keyboard),
        0xA1, 0x01,                     // Collection (Application),
        // bitmap of modifiers
        0x75, 0x01,                     //   Report Size (1),
        0x95, 0x08,                     //   Report Count (8),
        0x05, 0x07,                     //   Usage Page (Key Codes),
        0x19, 0xE0,                     //   Usage Minimum (224),
        0x29, 0xE7,                     //   Usage Maximum (231),
        0x15, 0x00,                     //   Logical Minimum (0),
        0x25, 0x01,                     //   Logical Maximum (1),
        0x81, 0x02,                     //   Input (Data, Variable, Absolute), ;Modifier byte
        // LED output report
        0x95, 0x05,                     //   Report Count (5),
        0x75, 0x01,                     //   Report Size (1),
        0x05, 0x08,                     //   Usage Page (LEDs),
        0x19, 0x01,                     //   Usage Minimum (1),
        0x29, 0x05,                     //   Usage Maximum (5),
        0x91, 0x02,                     //   Output (Data, Variable, Absolute),
        0x95, 0x01,                     //   Report Count (1),
        0x75, 0x03,                     //   Report Size (3),
        0x91, 0x03,                     //   Output (Constant),
        // bitmap of keys
        0x95, (REPORT_BYTES-1)*8,       //   Report Count (),
        0x75, 0x01,                     //   Report Size (1),
        0x15, 0x00,                     //   Logical Minimum (0),
        0x25, 0x01,                     //   Logical Maximum(1),
        0x05, 0x07,                     //   Usage Page (Key Codes),
        0x19, 0x00,                     //   Usage Minimum (0),
        0x29, (REPORT_BYTES-1)*8-1,     //   Usage Maximum (),
        0x81, 0x02,                     //   Input (Data, Variable, Absolute),
        0xc0                            // End Collection
where REPORT_BYTES is a report size in bytes.


Considerations
--------------
Compatibility
    boot protocol
    minor/old system
        Some BIOS doesn't send SET_PROTCOL request, a keyboard can't switch to boot protocol mode.
        This may cuase a problem on a keyboard which uses other report than Standard.
Reactivity
    USB polling time
    OS/Driver processing time


Windows Problem
---------------
1. Windows accepts only 6keys  in case of Standard report.
        It should be able to send 6keys plus 8modifiers.
2. Windows accepts only 10keys in case of 16bytes Extended report.
        It should be able to send 14keys plus 8modifiers.
3. Windows accepts only 18keys in case of 32bytes Extended report.
        It should be able to send 30keys plus 8modifiers.
If keys are pressed in excess of the number, wrong keys are registered on Windows.

This problem will be reportedly fixed soon.(2010/12/05)
    http://forums.anandtech.com/showpost.php?p=30873364&postcount=17

Moogle Stiltzkin · « **Reply #27 on:** Thu, 09 December 2010, 01:03:58 »

Uh so i am guessing you guys are working on a USB NKRO firmware

Ripster mentioned that for the topre realforce, if you set the dip switch to 4, and use custom firmware you could possibly get USB NKRO to work.

I hope someone manages to do that

Or since i'm already getting a Ducky DK-9008; would this custom firmware work for that as well ??

hasu · « **Reply #28 on:** Thu, 09 December 2010, 01:52:10 »

Quote from: Moogle Stiltzkin;259979

Uh so i am guessing you guys are working on a USB NKRO firmware

I added the feature on my firmware of HHKB. My HHKB Mod is NKRO now.

And soarer is working on his own PS/2-USB adapter.

Quote

Ripster mentioned that for the topre realforce, if you set the dip switch to 4, and use custom firmware you could possibly get USB NKRO to work.

I hope someone manages to do that

Or since i'm already getting a Ducky DK-9008; would this custom firmware work for that as well ??

If you can replace Ducky controller with AVR, you can use my firmware.

Realforce keyswitch matrix is NKRO capable, it is possible technically.
But I think it is not easy job because the firmware of Realfoce is not open and minor MCU is used.

From this pic, I found 87U uses [strike]Renesus[/strike] Fujitsu MCU M90F377.

Moogle Stiltzkin · « **Reply #29 on:** Thu, 09 December 2010, 02:24:03 »

Oh so your firmware is dependent on using your controller ? What is AVR ?

Hm :x

But my keyboard has 4 extra media keys; and it uses the FN key to switch some keys and also disable the windows key.

So using another controller may break those other features.

PS: i am also unsure what the ramifications/cons of using a USB NKRO. Is there some noticeable latency or some major issue when USB NKRO ?

Moogle Stiltzkin · « **Reply #30 on:** Thu, 09 December 2010, 02:32:31 »

Quote from: hasu;259988

I added the feature on my firmware of HHKB. My HHKB Mod is NKRO now.

And soarer is working on his own PS/2-USB adapter.

If you can replace Ducky controller with AVR, you can use my firmware.

Realforce keyswitch matrix is NKRO capable, it is possible technically.
But I think it is not easy job because the firmware of Realfoce is not open and minor MCU is used.

From this pic, I found 87U uses [strike]Renesus[/strike] Fujitsu MCU M90F377.
Show Image

PS: You talk alot about bios support but does your mod take into account UEFI ?

hasu · « **Reply #31 on:** Thu, 09 December 2010, 07:07:51 »

Unfortunately at this time, you need some elementary skills to get NKRO on USB: soldering, programming, reverse engineering.

There are few keyboards which has programmable controller AFAIK. You need to replace your keyboard's controller with programmable one to use custom firmware.

Quote from: Moogle Stiltzkin;260004

Oh so your firmware is dependent on using your controller ? What is AVR ?

Hm :x

But my keyboard has 4 extra media keys; and it uses the FN key to switch some keys and also disable the windows key.

So using another controller may break those other features.

PS: i am also unsure what the ramifications/cons of using a USB NKRO. Is there some noticeable latency or some major issue when USB NKRO ?

I don't know UEFI at all. And I don't take into account it on my firmware.

Quote from: Moogle Stiltzkin;260007

PS: You talk alot about bios support but does your mod take into account UEFI ?

Moogle Stiltzkin · « **Reply #32 on:** Thu, 09 December 2010, 08:20:05 »

Quote from: hasu;260077

Unfortunately at this time, you need some elementary skills to get NKRO on USB: soldering, programming, reverse engineering.

There are few keyboards which has programmable controller AFAIK. You need to replace your keyboard's controller with programmable one to use custom firmware.

I don't know UEFI at all. And I don't take into account it on my firmware.

Well i really don't know if UEFI would have any affect at all.

All i know is; their gonna have to have them soon for new motherboards as there is a transition to 3tb + hard drives beginning now :X

From an article at tomshardware i believe; they mentioned how bios recognized a hardware as a keyboard via atapi was it ? And UEFI somehow made it easier to identify keyboards without the messy programming or some such :X

Soarer · « **Reply #33 on:** Thu, 09 December 2010, 09:33:19 »

I haven't got enough time to consider all these points right now, I'll try to reply more fully later tonight, but...

Hasu, thanks for your memo, I hope start the Wiki page at the weekend.

Moogle, don't worry about UEFI, HID keyboards will still work, what they were probably talking about was that it will be easier to enable support for touchscreens etc during boot. If your keyboard can output PS2, maybe my converter would be suitable. I plan to support media keys as far as possible. It isn't finished yet though!

Soarer · « **Reply #34 on:** Thu, 09 December 2010, 19:14:28 »

Quote from: Moogle Stiltzkin;259979

Ripster mentioned that for the topre realforce, if you set the dip switch to 4, and use custom firmware you could possibly get USB NKRO to work.

I hope someone manages to do that

Sounds like a joke about dip switches! But, if a keyboard allowed for firmware updates, then it would theoretically be feasible.
Not with my software though, because I don't have, or plan to get, a Realforce :-)

Quote from: Moogle Stiltzkin;260004

Oh so your firmware is dependent on using your controller ? What is AVR ?

Atmel AVR. I'm using a Teensy for my PS2->USB converter, and hasu's modified HHKB is using a Teensy++ as the controller.

Quote from: Moogle Stiltzkin;260004

PS: i am also unsure what the ramifications/cons of using a USB NKRO. Is there some noticeable latency or some major issue when USB NKRO ?

Most USB keyboards are low speed and send an 8 byte report up to once per millisecond. The Teensy and Teensy++ are full speed USB devices so can send 64 bytes in the same time. My NKRO implementation sends an 8 byte report plus a 22 byte report. For comparison, ps2 takes over a millisecond to send a 'make' code (and twice that for a 'break').

Well, you asked :-)

Short answer is no, no issues with latency or anything else... that we've spotted yet.

JBert · « **Reply #35 on:** Fri, 10 December 2010, 13:47:58 »

Quote from: Moogle Stiltzkin;260097

Well i really don't know if UEFI would have any affect at all.

UEFI just does away with the hardware-firmware interfacing of BIOS.

In the end, the piece of UEFI boot code still needs to support keyboards, and seeing how USB HID is the current standard, this keyboard should work just fine.

Moogle Stiltzkin · « **Reply #36 on:** Fri, 10 December 2010, 14:49:40 »

Hm interesting.... *still reading

News:

Author Topic: USB - boot mode, NKRO, compatibility, etc... (Read 21422 times)

woody

woody

woody

woody

woody

woody

woody