Leaving space for less than 6 scancodes in a keyboard report?

[Renate]

HID keyboard reports use 1 byte modifiers, 1 byte reserved (wasted) and 6 bytes for scancodes.
If you are sharing an interface for multiple reports, there's an extra byte at the front for 9 total.

Ok, this is all pretty petty, but going to 9 bytes forces me into allocating a bigger buffer on the ATMega32u4.
Moreover, since I'm using this for key injection, I really don't need N-key rollover.
Besides, how many matrixed keyboards actually support 6 regular keys at a time (plus modifiers)?

I've chopped down the report count for the scancodes to 5 which makes the total report size (with Id) 8 bytes.
Yes, it works fine. It works on everything that I've tested.
I'm just wondering, if this is just something to avoid?
Have people had success deleting the "reserved" byte?
Which computers ignore/misparse keyboard HID descriptors?

Just wondering...

[grantb5]

I'm no expert on reports (is anyone?), but I think if your report accurately specifies what you are sending then you can adjust it however you like, within reason.  You could probably do 1 key scan code if you wanted. Where you will get into trouble is if you say you support Boot Protocol, because it's my understanding that is where the common format is more fixed. Another place you might find trouble is in Embedded hosts as they tend to be stripped down stacks. But on a PC I'm pretty sure you can be more creative.

[Jan Axelson]

I agree with grantb5.

[Renate]

Thank you both for your responses.
I would really have bet that the answer would have been:
"Oh, no! If you change any aspect of this it will break 50% of all implementations."
Thanks.

[Bret]

I've seen keyboards that do all kinds of strange things.  Some claim to be able to handle all 6 keystrokes at the same time, but actually only do about three or four.  If you do more than the "bad" keyboard can handle, it turns everything to zeroes (as if you weren't pressing anything on the keyboard at all).  I've also seen some that can actually do as many as 14 buttons at the same time, and others that don't support the boot protocol at all.  If you're going to call yourself a keyboard you MUST support the boot protocol according to the spec, and if you support the boot protocol you MUST support 6 simultaneous keystrokes (in addition to the modifier keys: Shift, Control, ...).  So, what you are doing is not compliant with the spec, but is unlikely to cause problems with most actual implementations.

[Barry Twycross]

if you support the boot protocol you MUST support 6 simultaneous keystrokes

I'd disagree with that, Appendix F of the HID spec says:

The Boot Keyboard shall report “Keyboard ErrorRollOver” in all array fields when combination of keys pressed cannot be accurately determined by the device, such as ghost key or rollover errors.

You have to support a report with 6 keys, but you don't have to support 6 key rollover. You do have to know if your rollover has been exceeded and report this.

[Bret]

In the particular keyboard I saw, it didn't report any error -- it just acted like no keys were pressed at all.  Also, I interpret the spec to mean that you must support six simultaneous keys (there would be no point in requiring space for six if you aren't actually required to support six), and the error occurs when you press seven.  But, maybe I'm interpreting it incorrectly.

[Barry Twycross]

The point in requiring 6 keys in the report is to give a uniform report size for the boot interface. The important thing is a boot driver can understand the report without having to use a parser. Its not a requirement for the hardware to support anything, apart from a 6 key report.