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.
Is there an easy way to do that?
But then there's boot compatibilty to consider... on my PC, with a nice modern BIOS, it's no problem.
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)
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.
About dumping descriptors - found this one:
http://www.microchip.com/forums/tm.aspx?m=364987
EDIT: Here's output from G84-4400
I guess that's 'lsusb -v'...
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?
Yes. You just have to detach the interfaces or you won't be seeing the report descriptors.
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.
Wait, do you use the "bit-mode descriptor" or the "extended legacy descriptor" for the default protocol?
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.
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).
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.
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?
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 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.
EDIT: figured it out... on DSL I just needed to do 'rmmod hid' - then I see report descriptors :)
The only downside is that it makes it a composite device - which is what appears to confuse Findecanor's eee Box.
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.
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.
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.
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.
(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).
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
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 :D
Or since i'm already getting a Ducky DK-9008; would this custom firmware work for that as well ??
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(http://farm5.static.flickr.com/4092/5061319335_a9cd332d59_z.jpg)
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 ?
PS: You talk alot about bios support but does your mod take into account UEFI ?
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.
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 :D
Oh so your firmware is dependent on using your controller ? What is AVR ?
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 ?
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.