Logitech G510s keyboard fail.

[Zaphod Beeblebrox]

So... The Logitech G510 keyboard fails. It is one of the Logitech
keyboards with the small display incorporated in it...

when I attache it, I get the following dmesg:

ukbd2: <Logitech G510s Gaming Keyboard, class 0/0, rev 2.00/11.72, addr 10>
on usbus0
kbd4 at ukbd2
hid_get_item: Number of items(991) truncated to 255
hid_get_item: Number of items(257) truncated to 255
hid_get_item: Number of items(991) truncated to 255
hid_get_item: Number of items(257) truncated to 255
uhid1: <Logitech G510s Gaming Keyboard, class 0/0, rev 2.00/11.72, addr 10>
on usbus0
hid_get_item: Number of items(991) truncated to 255
hid_get_item: Number of items(257) truncated to 255
hid_get_item: Number of items(991) truncated to 255
hid_get_item: Number of items(257) truncated to 255
hid_get_item: Number of items(991) truncated to 255
hid_get_item: Number of items(257) truncated to 255

2:27:327]root@hit:/home/dgilbert/Downloads> usbconfig -d ugen0.5
dump_device_desc
ugen0.5: <G510s Gaming Keyboard Logitech> at usbus0, cfg=0 md=HOST spd=FULL
(12Mbps) pwr=ON (500mA)

bLength = 0x0012
bDescriptorType = 0x0001
bcdUSB = 0x0200
bDeviceClass = 0x0000 <Probed by interface class>
bDeviceSubClass = 0x0000
bDeviceProtocol = 0x0000
bMaxPacketSize0 = 0x0008
idVendor = 0x046d
idProduct = 0xc22d
bcdDevice = 0x1172
iManufacturer = 0x0001 <Logitech>
iProduct = 0x0002 <G510s Gaming Keyboard>
iSerialNumber = 0x0000 <no string>
bNumConfigurations = 0x0001

.. notably, it works under BIOS and (of course) windows.
_______________________________________________
freebsd...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"

[Hans Petter Selasky]

> ... notably, it works under BIOS and (of course

Try:

usbconfig -d ugen0.5 add_quirk UQ_KBD_BOOTPROTO

Then replug your device.

--HPS

[Eitan Adler]

On 28 September 2016 at 10:29, Hans Petter Selasky <h...@selasky.org> wrote:

>
> Try:
>
> usbconfig -d ugen0.5 add_quirk UQ_KBD_BOOTPROTO
>
> Then replug your device.
>

> Educational question. Can you describe what this quirk actually does?

--
Eitan Adler

[Hans Petter Selasky]

On 09/28/16 09:41, Eitan Adler wrote:
> On 28 September 2016 at 10:29, Hans Petter Selasky <h...@selasky.org> wrote:
>
>>
>> Try:
>>
>> usbconfig -d ugen0.5 add_quirk UQ_KBD_BOOTPROTO
>>
>> Then replug your device.
>>

> Educational question. Can you describe what this quirk actually does?

This quirk makes the UKBD driver send a request for BOOT-compatible
mode, before attaching.

--HPS

[Zaphod Beeblebrox]

Ok... that makes the keyboard attach. It still says the following on dmesg:

uhid1: <Logitech G510s Gaming Keyboard, class 0/0, rev 2.00/11.72, addr 10>
on usbus0
hid_get_item: Number of items(991) truncated to 255
hid_get_item: Number of items(257) truncated to 255
hid_get_item: Number of items(991) truncated to 255
hid_get_item: Number of items(257) truncated to 255
hid_get_item: Number of items(991) truncated to 255
hid_get_item: Number of items(257) truncated to 255

How do I make this permanent?


On Wed, Sep 28, 2016 at 4:05 AM, Hans Petter Selasky <h...@selasky.org>

[Hans Petter Selasky]

On 09/28/16 20:46, Zaphod Beeblebrox wrote:
> Ok... that makes the keyboard attach. It still says the following on dmesg:
>
> uhid1: <Logitech G510s Gaming Keyboard, class 0/0, rev 2.00/11.72, addr 10>
> on usbus0
> hid_get_item: Number of items(991) truncated to 255
> hid_get_item: Number of items(257) truncated to 255
> hid_get_item: Number of items(991) truncated to 255
> hid_get_item: Number of items(257) truncated to 255
> hid_get_item: Number of items(991) truncated to 255
> hid_get_item: Number of items(257) truncated to 255
>
> How do I make this permanent?
>

Make a patch for sys/dev/usb/quirk/usb_quirk.c . Look at existing
keyboard quirks.

[Zaphod Beeblebrox]

On Wed, Sep 28, 2016 at 4:01 PM, Hans Petter Selasky <h...@selasky.org>
wrote:

> On 09/28/16 20:46, Zaphod Beeblebrox wrote:
>
>> Ok... that makes the keyboard attach. It still says the following on
>> dmesg:
>>
>> uhid1: <Logitech G510s Gaming Keyboard, class 0/0, rev 2.00/11.72, addr
>> 10>
>> on usbus0
>> hid_get_item: Number of items(991) truncated to 255
>> hid_get_item: Number of items(257) truncated to 255
>> hid_get_item: Number of items(991) truncated to 255
>> hid_get_item: Number of items(257) truncated to 255
>> hid_get_item: Number of items(991) truncated to 255
>> hid_get_item: Number of items(257) truncated to 255
>>
>> How do I make this permanent?
>>
>>
> Make a patch for sys/dev/usb/quirk/usb_quirk.c . Look at existing keyboard
> quirks.
>
>

OK. I get that. And you're correct about assuming that this is within my
ability...

.. but what are the hid_get_item truncated stuff about ... ?

[Hans Petter Selasky]

On 09/29/16 07:20, Zaphod Beeblebrox wrote:
> ... but what are the hid_get_item truncated stuff about ... ?

It is just an innocent warning, parsing the hid descriptors.

--HPS

[Hans Petter Selasky]

On 09/29/16 09:21, Hans Petter Selasky wrote:
> On 09/29/16 07:20, Zaphod Beeblebrox wrote:
>> ... but what are the hid_get_item truncated stuff about ... ?
>
> It is just an innocent warning, parsing the hid descriptors.
>

It might look like the keyboard is presenting all the keys like a
bitmap. Currently we need to extend the limit for number of bits from
255 to something higher to be able to support that.

[Zaphod Beeblebrox]

In this case, 10 bits (1024) would seem right. 16 bits would seem a good
use of bits. If I were to develop a patch along the lines of 10 or 16
bits, is there a good chance it would be adopted?

On Thu, Sep 29, 2016 at 3:24 AM, Hans Petter Selasky <h...@selasky.org>
wrote:

[Hans Petter Selasky]

On 09/29/16 17:52, Zaphod Beeblebrox wrote:
> In this case, 10 bits (1024) would seem right. 16 bits would seem a good
> use of bits. If I were to develop a patch along the lines of 10 or 16
> bits, is there a good chance it would be adopted?
>

It is the opposite. 1024 bits. One bit for every possible key press, so
that you can press multiple keys at the same time.

[Zaphod Beeblebrox]

The largest number it was "skipping" was 993 ... awfully close to 10 bits.
was thinking that 16 bits (a short int) was a more appropriate size, was
all?

On Thu, Sep 29, 2016 at 12:00 PM, Hans Petter Selasky <h...@selasky.org>
wrote:

[Eitan Adler]

On 30 September 2016 at 01:49, Zaphod Beeblebrox <zbe...@gmail.com> wrote:

> The largest number it was "skipping" was 993 ... awfully close to 10
> bits. was thinking that 16 bits (a short int) was a more appropriate size,
> was all?
>

Unless there is a particualr reason to keep it small (such as memory
pressure) lets use a fairly large number of bits.



--
Eitan Adler

[Kurt Lidl]

On 30 September 2016 at 4:35, Eitan Adler wrote:
> On 30 September 2016 at 01:49, Zaphod Beeblebrox <zbe...@gmail.com> wrote:
>
>> The largest number it was "skipping" was 993 ... awfully close to 10
>> bits. was thinking that 16 bits (a short int) was a more appropriate size,
>> was all?
>>
>
> Unless there is a particualr reason to keep it small (such as memory
> pressure) lets use a fairly large number of bits.

As I understand it, the way the USB keyboards with true N-key-rollover
work is that they send a bitmap of which keys are pressed in each
usb packet. (My terminology might be a little off here...)

The most basic mode is the "BOOT" (aka "standard") mode, where each
packet is 8 bytes in length, so you only get an array of up to six
simultaneous key-presses.

There's an "extended" mode, that can be either 16/32/64 bytes in length.
In the extended mode, there's a 2 byte overhead, so you get N-2
simultaneous key-presses in each packet.

Finally, there's the "bitmap" mode, where keyboard sends a packet
with a bunch of control data, and also 16/32/64 bytes of bitmap
data. The bitmap represents all the keys that are pressed
simultaneously.

The number of simultaneous keypresses one can track is related to
the size of the bitmap. With the 16 bytes of bitmap, you get up
up to 128 simultaneous key-presses, etc... The 32 bytes of bitmap
get you up to 256 bits of presence detection. I don't know if
there's a 128 byte variant of the bitmap support packet or not.
Someone would have to do some usb low-level debugging to figure that
out... It seems straightforward - there's just a byte in the middle
of the bitmap packet support that says how many bytes of bitmap
data there are present.

There's some relevant data here:

https://github.com/tmk/tmk_keyboard/blob/master/tmk_core/doc/USB_NKRO.txt

-Kurt

[Hans Petter Selasky]

On 09/30/16 17:29, Kurt Lidl wrote:
>
> The number of simultaneous keypresses one can track is related to
> the size of the bitmap. With the 16 bytes of bitmap, you get up
> up to 128 simultaneous key-presses, etc... The 32 bytes of bitmap
> get you up to 256 bits of presence detection. I don't know if
> there's a 128 byte variant of the bitmap support packet or not.
> Someone would have to do some usb low-level debugging to figure that
> out... It seems straightforward - there's just a byte in the middle
> of the bitmap packet support that says how many bytes of bitmap
> data there are present.

Hi Kurt,

Typically USB full speed does not go beyond 64-bytes per packet.

Possibly we should add support for the bitmap mode of USB keyboards.

Your understanding is correct.

--HPS

[Lars Engels]

On Wed, Sep 28, 2016 at 10:01:18PM +0200, Hans Petter Selasky wrote:
> On 09/28/16 20:46, Zaphod Beeblebrox wrote:
> > Ok... that makes the keyboard attach. It still says the following on dmesg:
> >
> > uhid1: <Logitech G510s Gaming Keyboard, class 0/0, rev 2.00/11.72, addr 10>
> > on usbus0
> > hid_get_item: Number of items(991) truncated to 255
> > hid_get_item: Number of items(257) truncated to 255
> > hid_get_item: Number of items(991) truncated to 255
> > hid_get_item: Number of items(257) truncated to 255
> > hid_get_item: Number of items(991) truncated to 255
> > hid_get_item: Number of items(257) truncated to 255
> >
> > How do I make this permanent?
> >
>
> Make a patch for sys/dev/usb/quirk/usb_quirk.c . Look at existing
> keyboard quirks.

There are plenty of patches for the USB quirks coming in much faster
than new FreeBSD releases are made. Would it be possible to swap out the
quirks in a port? We could still have the quirks in base but if you
install the port it would override them?

[Mehmet Erol Sanliturk]

I have another idea ( I am sorry that I can not do it now ) :


Move all of the existent device definitions arrays into XML files .
When a device is detected , load its definition from related XML file
Find its "index" .
By using that "index" , in a case statement do whatever is required such as
obtained from now from internal arrays : load a driver , etc.

This may have two parts : Existing device drivers in FreeBSD and XML
definition specified above .
These will be stored into FreeBSD base directories .


If device definition is not found in FreeBSD base XML definition files ,
the system
will look into following files defined below : If it is found , it will use
it , if it is not found , it will not "panic" but display a proper error
message ( in sufficient detail to be understandable by user ) .


For user devices which they are not in the above XML files :


System will search a predefined device directory in user space for a
possible XML file having definition of the device dedicated to the device
detected : In this file , a driver name should be specified .
FreeBSD will load this driver into user space and execute it .


Sources reading XML files is already present in the FreeBSD .
The only required part is to decode loaded XML file with respect to
elements .


The above structure will allow the companies to produce related XML files
and device drivers and let the users to use them without requiring
modifications into FreeBSD base system .


If they are not open source , it is the responsibility of the user whether
she/he will use it or not use it .


Such a structure will not require continuous modification in kernel sources
, and recompiling them .
It will move new device drivers into user space .

Later on , on new releases , if it is found useful , such drivers may be
moved into FreeBSD base .



Thank you very much .


Mehmet Erol Sanliturk