Updated Kamvas Pro 19 descriptor check
This fixes #43 (closed) for me, works a treat, and should also still work for the older firmware with the smaller descriptor.
To duplicate some info in that issue for context:
It seems newer firmware has a hid descriptor that is 438
bytes long, not the 328
the check is looking for, I don't know how to dump the firmware version on linux, but I suspect because my units hardware is newer that it's running an updated firmware.
Comparing against the hid recording in #36 (closed), it seems the following has been added:
# 0x05, 0x01, // Usage Page (Generic Desktop) 328
# 0x09, 0x01, // Usage (Pointer) 330
# 0xa1, 0x01, // Collection (Application) 332
# 0x09, 0x01, // Usage (Pointer) 334
# 0xa1, 0x00, // Collection (Physical) 336
# 0x05, 0x09, // Usage Page (Button) 338
# 0x19, 0x01, // UsageMinimum (1) 340
# 0x29, 0x03, // UsageMaximum (3) 342
# 0x15, 0x00, // Logical Minimum (0) 344
# 0x25, 0x01, // Logical Maximum (1) 346
# ┅ 0x85, 0x02, // Report ID (2) 348
# 0x95, 0x03, // Report Count (3) 350
# 0x75, 0x01, // Report Size (1) 352
# ┇ 0x81, 0x02, // Input (Data,Var,Abs) 354
# 0x95, 0x01, // Report Count (1) 356
# 0x75, 0x05, // Report Size (5) 358
# ┇ 0x81, 0x01, // Input (Cnst,Arr,Abs) 360
# 0x05, 0x01, // Usage Page (Generic Desktop) 362
# 0x09, 0x30, // Usage (X) 364
# 0x09, 0x31, // Usage (Y) 366
# 0x15, 0x81, // Logical Minimum (-127) 368
# 0x25, 0x7f, // Logical Maximum (127) 370
# 0x75, 0x08, // Report Size (8) 372
# 0x95, 0x02, // Report Count (2) 374
# ┇ 0x81, 0x06, // Input (Data,Var,Rel) 376
# 0x95, 0x04, // Report Count (4) 378
# 0x75, 0x08, // Report Size (8) 380
# ┇ 0x81, 0x01, // Input (Cnst,Arr,Abs) 382
# 0xc0, // End Collection 384
# 0xc0, // End Collection 385
# 0x05, 0x0d, // Usage Page (Digitizers) 386
# 0x09, 0x05, // Usage (Touch Pad) 388
# 0xa1, 0x01, // Collection (Application) 390
# 0x06, 0x00, 0xff, // Usage Page (Vendor Defined Page FF00) 392
# 0x09, 0x0c, // Usage (Vendor Usage 0x0c) 395
# 0x15, 0x00, // Logical Minimum (0) 397
# 0x26, 0xff, 0x00, // Logical Maximum (255) 399
# 0x75, 0x08, // Report Size (8) 402
# 0x95, 0x10, // Report Count (16) 404
# ┅ 0x85, 0x3f, // Report ID (63) 406
# ┇ 0x81, 0x22, // Input (Data,Var,Abs,NoPref) 408
# 0xc0, // End Collection 410
# 0x06, 0x00, 0xff, // Usage Page (Vendor Defined Page FF00) 411
# 0x09, 0x0c, // Usage (Vendor Usage 0x0c) 414
# 0xa1, 0x01, // Collection (Application) 416
# 0x06, 0x00, 0xff, // Usage Page (Vendor Defined Page FF00) 418
# 0x09, 0x0c, // Usage (Vendor Usage 0x0c) 421
# 0x15, 0x00, // Logical Minimum (0) 423
# 0x26, 0xff, 0x00, // Logical Maximum (255) 425
# ┅ 0x85, 0x44, // Report ID (68) 428
# 0x75, 0x08, // Report Size (8) 430
# 0x96, 0x6b, 0x05, // Report Count (1387) 432
# ┇ 0x81, 0x00, // Input (Data,Arr,Abs) 435
# 0xc0, // End Collection 437
This PR updates the descriptor check to look for both the 328
and the 438
length descriptors, I'm not 100% sure the proper way to cross the probe
boundary into the bpf machinery with the info needed, so i'm just using a bool, extended_descriptor
which is used to control the memcpy
size to truncate the descriptor if it's not the extended variant.
Anynyan, let me know if this looks decent or not~
Closes #43 (closed)
edit by @whot: add closes tag
Merge request reports
Activity
mentioned in issue #43 (closed)
- Resolved by Benjamin Tissoires
- Resolved by Benjamin Tissoires
I don't know how to dump the firmware version on linux, but I suspect because my units hardware is newer that it's running an updated firmware.
If you run
huion-switcher
from here it'll print the firmware version including the date - which you could then use via theHUION_FIRMWARE_ID
udev property (see the keydial kd20 sources for example).- Resolved by Benjamin Tissoires
Hey,
Yeah I'll try to do the fixups when I get a chance, I'm a little busy the next few days but I should be able to get to it around Wed if that's okay.
- Resolved by Benjamin Tissoires
- Resolved by Benjamin Tissoires
- Resolved by Benjamin Tissoires
Couple of nitpicks, but otherwise looks good.
There is one missing bit that we didn't foresee, in terms of process: you are directly touching the
stable
file, which is probably not the best stable way to do things (considering that the first attempt was bogus for the old device is even more a hint that this is not correct).So I think we should:
- first copy the stable file into
testing
(and amendmeson.build
) - then add your commit on top (with my nitpicks)
- then let the magic happen and I can forward this to the kernel, which will eventually send back those changes into
stable
.
If you agree, I can easily do those changes myself in your branch (this will still keep you as the author both here and in the kernel)
- first copy the stable file into
mentioned in commit bentiss/hid@531a1cc6