Closed ZRtmWrJqXcjbqBLIMBYMCeUw closed 3 years ago
This is how it looks for a G29 with new-lg4ff:
usb 7-3: new full-speed USB device number 5 using xhci_hcd
usb 7-3: New USB device found, idVendor=046d, idProduct=c24f, bcdDevice=89.00
usb 7-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 7-3: Product: G29 Driving Force Racing Wheel
usb 7-3: Manufacturer: Logitech
input: Logitech G29 Driving Force Racing Wheel as /devices/pci0000:00/0000:00:08.1/0000:0a:00.3/usb7/7-3/7-3:1.0/0003:046D:C24F.000F/input/input38
logitech 0003:046D:C24F.000F: input,hidraw6: USB HID v1.11 Joystick [Logitech G29 Driving Force Racing Wheel] on usb-0000:0a:00.3-3/input0
logitech 0003:046D:C24F.000F: Force feedback support for Logitech Gaming Wheels (0.3.1)
It seems like the hiddpp module is trying to register the G923 as several devices. Maybe the TRUFORCE feature is presented as a second device using HID++? I don't know much about USB/HID, much less about HID++, so this is just guessing work.
usb 1-14: new full-speed USB device number 3 using xhci_hcd usb 1-14: New USB device found, idVendor=046d, idProduct=c267, bcdDevice=38.00 usb 1-14: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-14: Product: G923 Racing Wheel for PlayStation 4 and PC usb 1-14: Manufacturer: Logitech usb 1-14: SerialNumber:
logitech-hidpp-device 0003:046D:C267.0007: ignoring exceeding usage max input: Logitech G923 Racing Wheel for PlayStation 4 and PC as /devices/pci0000:00/0000:00:01.3/0000:01:00.0/usb1/1-14/1-14:1.0/0003:046D:C267.0007/input/input30 logitech-hidpp-device 0003:046D:C267.0007: input,hiddev1,hidraw3: USB HID v1.10 Gamepad [Logitech G923 Racing Wheel for PlayStation 4 and PC] on usb-0000:01:00.0-14/input0 logitech-hidpp-device 0003:046D:C267.0008: HID++ 4.2 device connected.
Up until this line it looks right except for the "Ignoring exceeding usage max". That might require some investigation, I don't know what it means.
You can add output lines for debugging the module. Seeing what the module is doing and following the HID++ specification might help figure out what's happening.
Knowing the output for the G29 helps a lot, thanks. I will look into why the wheel is presenting itself as 3 devices - I was under the impression the pedals and shifter had something to do with that... do they? Maybe not the pedals but how about the shifter? I am also not sure if TRUEFORCE has anything to do with it... I think the "Ignoring exceeding usage max" message is a good lead to follow for now.
At least in the G29 and G920 everything is seen as one device. Rather than presenting itself as several devices I think the module is interpreting that it's composed of several, maybe virtual, devices. It seems each supposed device has the same vendor/product ids. I'd investigate why the module seems to be doing 3 initiatlisations over the same device. I'm not sure I know what I'm talking about but I hope you can make some sense.
It seems hidpp_probe in hid-logitech-hidpp.c is being called 3 times.
usb 1-14: new full-speed USB device number 2 using xhci_hcd
usb 1-14: New USB device found, idVendor=046d, idProduct=c267, bcdDevice=38.00
usb 1-14: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-14: Product: G923 Racing Wheel for PlayStation 4 and PC
usb 1-14: Manufacturer: Logitech
usb 1-14: SerialNumber: <serial-number>
logitech-hidpp-device 0003:046D:C267.0004: hidpp_probe: started hidpp_probe // Probe #1
logitech-hidpp-device 0003:046D:C267.0004: ignoring exceeding usage max
input: Logitech G923 Racing Wheel for PlayStation 4 and PC as /devices/pci0000:00/0000:00:01.3/0000:01:00.0/usb1/1-14/1-14:1.0/0003:046D:C267.0004/input/input23
logitech-hidpp-device 0003:046D:C267.0004: input,hiddev1,hidraw3: USB HID v1.10 Gamepad [Logitech G923 Racing Wheel for PlayStation 4 and PC] on usb-0000:01:00.0-14/input0
logitech-hidpp-device 0003:046D:C267.0005: hidpp_probe: started hidpp_probe // Probe #2
logitech-hidpp-device 0003:046D:C267.0005: HID++ 4.2 device connected.
logitech-hidpp-device 0003:046D:C267.0005: hiddev2,hidraw4: USB HID v1.11 Device [Logitech G923 Racing Wheel for PlayStation 4 and PC] on usb-0000:01:00.0-14/input1
logitech-hidpp-device 0003:046D:C267.0005: no inputs found
logitech-hidpp-device 0003:046D:C267.0005: Unable to initialize force feedback support, errno -19
logitech-hidpp-device 0003:046D:C267.0006: hidpp_probe: started hidpp_probe // Probe #3
logitech-hidpp-device 0003:046D:C267.0006: hiddev3,hidraw5: USB HID v1.11 Device [Logitech G923 Racing Wheel for PlayStation 4 and PC] on usb-0000:01:00.0-14/input2
I will try go up the call stack then.
Some additional details:
It appears the inputs are added upon the first "device" being detected. This also appears to be the only time when hid_parser_local()
, in hid-core.c
, is being called. The g92X_get_config
in hidpp_probe()
, however, is only called when the second "device" is detected.
I think the "Ignoring exceeding usage max" message is a good lead to follow for now.
This is a warning because a kernel hard limit on a value has been exceeded. It's in the hid_parser_local
function. This might mean there's errors in the HID descriptors. It's frequent that HID descriptors have errors that need to be corrected in the driver.
This document explains that part of the specification: https://www.usb.org/sites/default/files/documents/hut1_12v2.pdf
It appears the inputs are added upon the first "device" being detected. This also appears to be the only time when
hid_parser_local()
, inhid-core.c
, is being called. Theg92X_get_config
inhidpp_probe()
, however, is only called when the second "device" is detected.
This means the G923 is really more than one device. I'd print vendor/product id in hidpp_probe
to see the device that is handled in each call.
It seems the second device matches the vendor/product id that you've used for the G920 quirks. Since it fails to initialize FFB, you may try changing it to the first or third device. Probably the first device should be closer to the G920, the others being unknown.
Have you tried contacting someone at Logitech?
This is a warning because a kernel hard limit on a value has been exceeded. It's in the
hid_parser_local
function. This might mean there's errors in the HID descriptors. It's frequent that HID descriptors have errors that need to be corrected in the driver.
I will look into this.
This means the G923 is really more than one device. I'd print vendor/product id in
hidpp_probe
to see the device that is handled in each call.
dmesg
is showing the same vendor/product id for each device, not sure if printing these manually would make a difference (please correct me if I am wrong).
It seems the second device matches the vendor/product id that you've used for the G920 quirks. Since it fails to initialize FFB, you may try changing it to the first or third device. Probably the first device should be closer to the G920, the others being unknown.
The quirk I am using for the G923 is 32 or BIT(5)
(part of the current patch, I also detect for that alongside the G920 quirk except i call my custom g923_get_config
). Printing hidpp->quirks
returns 32 for all 3 hidpp_probe
calls which means they all have the correct quirks set but only the second "device" has hidpp->supported_reports = 0x3
- it is 0x0
for the other 2 causing them to stop processing at the if (!hidpp->supported_reports)
line and not get a chance to reach hidpp_ff_init
call. Perhaps correcting the HID descriptors will allow this to work?
Have you tried contacting someone at Logitech?
I sent an email to benjamin.tissoires@gmail.com and nlopezcasad@logitech.com (they are listed as the authors of the hid-logitech-hidpp
module) a few days ago but have not received a response yet. I tried to find an a way to contact Logitech from their site but they seem like they are specific to reporting issues with the hardware...
The quirk I am using for the G923 is 32 or
BIT(5)
(part of the current patch, I also detect for that alongside the G920 quirk except i call my customg923_get_config
). Printinghidpp->quirks
returns 32 for all 3hidpp_probe
calls which means they all have the correct quirks set but only the second "device" hashidpp->supported_reports = 0x3
- it is0x0
for the other 2 causing them to stop processing at theif (!hidpp->supported_reports)
line and not get a chance to reachhidpp_ff_init
call. Perhaps correcting the HID descriptors will allow this to work?
OK, sorry, I was ignoring your changes. Then I think the vendor/id in dmesg are correct as they should be.
But I don't understand how is it possible doing several probes in the same device, there should be something changing from one probe to the other. USB devices can have several endpoints, they are different interfaces to the same device. I don't think a probe is needed for each endpoint but I might be wrong.
You might get useful information dumping the device descriptors with lsusb -v
. Peeking at what each call to g923_get_config
gets as device
and returns as data
might be useful too.
logitech-hidpp-device 0003:046D:C267.0005: no inputs found logitech-hidpp-device 0003:046D:C267.0005: Unable to initialize force feedback support, errno -19
You're trying to initialize FFB three times and it's failing the second one, so it's working the other two times. I'm intrigued by the outcome of this double initialization of FFB on the same device.
I'm sorry about lacking so much knowledge about the USB specification. I only have a grasp about how it works. It would be probably helpful being able to correctly interpret the device reports to know what's going on.
You might get useful information dumping the device descriptors with
lsusb -v
. Peeking at what each call tog923_get_config
gets asdevice
and returns asdata
might be useful too.
lsusb -v
:
Bus 001 Device 002: ID 046d:c267 Logitech, Inc. G923 Racing Wheel for PlayStation 4 and PC
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.00
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x046d Logitech, Inc.
idProduct 0xc267
bcdDevice 38.00
iManufacturer 1 Logitech
iProduct 2 G923 Racing Wheel for PlayStation 4 and PC
iSerial 3 <serial-number>
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0062
bNumInterfaces 3
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 200mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.10
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 193
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 5
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 5
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.11
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 54
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0014 1x 20 bytes
bInterval 5
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.11
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 30
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0000
(Bus Powered)
I will try to see if I can make use of that.
dmesg
with some custom print statements:
usb 1-14: new full-speed USB device number 2 using xhci_hcd
usb 1-14: New USB device found, idVendor=046d, idProduct=c267, bcdDevice=38.00
usb 1-14: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-14: Product: G923 Racing Wheel for PlayStation 4 and PC
usb 1-14: Manufacturer: Logitech
usb 1-14: SerialNumber: <serial-number>
hid-generic 0003:046D:C267.0004: hid_device_probe: calling hid_device_probe
logitech-hidpp-device 0003:046D:C267.0004: hid_device_probe: calling hid_device_probe
logitech-hidpp-device 0003:046D:C267.0004: hidpp_probe: calling hidpp_probe
logitech-hidpp-device 0003:046D:C267.0004: hid_parser_local: parsing data = 0x5
logitech-hidpp-device 0003:046D:C267.0004: hid_parser_local: parsing data = 0x30
logitech-hidpp-device 0003:046D:C267.0004: hid_parser_local: parsing data = 0x31
logitech-hidpp-device 0003:046D:C267.0004: hid_parser_local: parsing data = 0x32
logitech-hidpp-device 0003:046D:C267.0004: hid_parser_local: parsing data = 0x35
logitech-hidpp-device 0003:046D:C267.0004: hid_parser_local: parsing data = 0x39
logitech-hidpp-device 0003:046D:C267.0004: hid_parser_local: parsing data = 0x1
logitech-hidpp-device 0003:046D:C267.0004: hid_parser_local: parsing data = 0xE
logitech-hidpp-device 0003:046D:C267.0004: hid_parser_local: parsing data = 0x20
logitech-hidpp-device 0003:046D:C267.0004: hid_parser_local: parsing data = 0x33
logitech-hidpp-device 0003:046D:C267.0004: hid_parser_local: parsing data = 0x34
logitech-hidpp-device 0003:046D:C267.0004: hid_parser_local: parsing data = 0x21
logitech-hidpp-device 0003:046D:C267.0004: hid_parser_local: parsing data = 0x22
logitech-hidpp-device 0003:046D:C267.0004: hid_parser_local: parsing data = 0x2721
logitech-hidpp-device 0003:046D:C267.0004: hid_parser_local: parsing data = 0x40
logitech-hidpp-device 0003:046D:C267.0004: hid_parser_local: parsing data = 0x47
logitech-hidpp-device 0003:046D:C267.0004: hid_parser_local: parsing data = 0x48
logitech-hidpp-device 0003:046D:C267.0004: hid_parser_local: parsing data = 0x49
logitech-hidpp-device 0003:046D:C267.0004: hid_parser_local: parsing data = 0x4701
logitech-hidpp-device 0003:046D:C267.0004: hid_parser_local: parsing data = 0x4
logitech-hidpp-device 0003:046D:C267.0004: hid_parser_local: parsing data = 0x2
logitech-hidpp-device 0003:046D:C267.0004: hid_parser_local: parsing data = 0x1
logitech-hidpp-device 0003:046D:C267.0004: hid_parser_local: parsing data = 0xFFFF
logitech-hidpp-device 0003:046D:C267.0004: hid_parser_local: dev_name = 0003:046D:C267.0004 // This is the only place dev_name is set.
logitech-hidpp-device 0003:046D:C267.0004: ignoring exceeding usage max
logitech-hidpp-device 0003:046D:C267.0004: hidpp_probe: not hid++ capable. supported reports = 0x0
input: Logitech G923 Racing Wheel for PlayStation 4 and PC as /devices/pci0000:00/0000:00:01.3/0000:01:00.0/usb1/1-14/1-14:1.0/0003:046D:C267.0004/input/input29
logitech-hidpp-device 0003:046D:C267.0004: input,hiddev1,hidraw3: USB HID v1.10 Gamepad [Logitech G923 Racing Wheel for PlayStation 4 and PC] on usb-0000:01:00.0-14/input0
hid-generic 0003:046D:C267.0005: hid_device_probe: calling hid_device_probe
logitech-hidpp-device 0003:046D:C267.0005: hid_device_probe: calling hid_device_probe
logitech-hidpp-device 0003:046D:C267.0005: hidpp_probe: calling hidpp_probe
logitech-hidpp-device 0003:046D:C267.0005: hid_parser_local: parsing data = 0x1
logitech-hidpp-device 0003:046D:C267.0005: hid_parser_local: parsing data = 0x1
logitech-hidpp-device 0003:046D:C267.0005: hid_parser_local: parsing data = 0x1
logitech-hidpp-device 0003:046D:C267.0005: hid_parser_local: parsing data = 0x2
logitech-hidpp-device 0003:046D:C267.0005: hid_parser_local: parsing data = 0x2
logitech-hidpp-device 0003:046D:C267.0005: hid_parser_local: parsing data = 0x2
logitech-hidpp-device 0003:046D:C267.0005: HID++ 4.2 device connected.
logitech-hidpp-device 0003:046D:C267.0005: hidpp_connect_event: we have been called // This is the only place hidpp_connect_event() is called.
logitech-hidpp-device 0003:046D:C267.0005: hiddev2,hidraw4: USB HID v1.11 Device [Logitech G923 Racing Wheel for PlayStation 4 and PC] on usb-0000:01:00.0-14/input1
logitech-hidpp-device 0003:046D:C267.0005: hidpp_probe: hid++ device quirks = 32, supported reports = 0x3
logitech-hidpp-device 0003:046D:C267.0005: no inputs found
logitech-hidpp-device 0003:046D:C267.0005: Unable to initialize force feedback support, errno -19
hid-generic 0003:046D:C267.0006: hid_device_probe: calling hid_device_probe
logitech-hidpp-device 0003:046D:C267.0006: hid_device_probe: calling hid_device_probe
logitech-hidpp-device 0003:046D:C267.0006: hidpp_probe: calling hidpp_probe
logitech-hidpp-device 0003:046D:C267.0006: hid_parser_local: parsing data = 0xFD01
logitech-hidpp-device 0003:046D:C267.0006: hid_parser_local: parsing data = 0x1
logitech-hidpp-device 0003:046D:C267.0006: hid_parser_local: parsing data = 0x1
logitech-hidpp-device 0003:046D:C267.0006: hidpp_probe: not hid++ capable. supported reports = 0x0
logitech-hidpp-device 0003:046D:C267.0006: hiddev3,hidraw5: USB HID v1.11 Device [Logitech G923 Racing Wheel for PlayStation 4 and PC] on usb-0000:01:00.0-14/input2
Some of the print statements I added to hid-core.c
e.g. for printing the data being parsed. The currently executed function (__func__
) is printed before the colon.
You're trying to initialize FFB three times and it's failing the second one, so it's working the other two times. I'm intrigued by the outcome of this double initialization of FFB on the same device.
Sorry for not clarifying, I have been putting a lot of print statements everywhere and noticed that only the second probe (I will refer to them as probes from now on) reaches hidpp_ff_init
. The other two are cut short at if (!hidpp->supported_reports)
(see the "not hid++ capable" lines in the dmesg
output above). The second probe has a hidpp->supported_reports = 0x3
, whatever that means, while the other 2 probes have hidpp->supported_reports = 0x0
(hence being cut short at the mentioned if statement).
I'm sorry about lacking so much knowledge about the USB specification. I only have a grasp about how it works. It would be probably helpful being able to correctly interpret the device reports to know what's going on.
Don't worry about it. I don't really understand most of this so any information is useful to me. I'll continue reading documentation to try make sense of this. I still find all your help and general ideas very useful so thanks.
Using hid-tools I managed to extract what I believe is the report descriptor for the G923:
# Logitech G923 Racing Wheel for PlayStation 4 and PC
# 0x05, 0x01, // Usage Page (Generic Desktop) 0
# 0x09, 0x05, // Usage (Game Pad) 2
# 0xa1, 0x01, // Collection (Application) 4
# 0x85, 0x01, // Report ID (1) 6
# 0x09, 0x30, // Usage (X) 8
# 0x09, 0x31, // Usage (Y) 10
# 0x09, 0x32, // Usage (Z) 12
# 0x09, 0x35, // Usage (Rz) 14
# 0x15, 0x00, // Logical Minimum (0) 16
# 0x26, 0xff, 0x00, // Logical Maximum (255) 18
# 0x75, 0x08, // Report Size (8) 21
# 0x95, 0x04, // Report Count (4) 23
# 0x81, 0x02, // Input (Data,Var,Abs) 25
# 0x09, 0x39, // Usage (Hat switch) 27
# 0x15, 0x00, // Logical Minimum (0) 29
# 0x25, 0x07, // Logical Maximum (7) 31
# 0x35, 0x00, // Physical Minimum (0) 33
# 0x46, 0x3b, 0x01, // Physical Maximum (315) 35
# 0x65, 0x14, // Unit (Degrees,EngRotation) 38
# 0x75, 0x04, // Report Size (4) 40
# 0x95, 0x01, // Report Count (1) 42
# 0x81, 0x42, // Input (Data,Var,Abs,Null) 44
# 0x65, 0x00, // Unit (None) 46
# 0x05, 0x09, // Usage Page (Button) 48
# 0x19, 0x01, // Usage Minimum (1) 50
# 0x29, 0x0e, // Usage Maximum (14) 52
# 0x15, 0x00, // Logical Minimum (0) 54
# 0x25, 0x01, // Logical Maximum (1) 56
# 0x75, 0x01, // Report Size (1) 58
# 0x95, 0x0e, // Report Count (14) 60
# 0x81, 0x02, // Input (Data,Var,Abs) 62
# 0x06, 0x00, 0xff, // Usage Page (Vendor Defined Page 1) 64
# 0x09, 0x20, // Usage (Vendor Usage 0x20) 67
# 0x75, 0x06, // Report Size (6) 69
# 0x95, 0x01, // Report Count (1) 71
# 0x81, 0x02, // Input (Data,Var,Abs) 73
# 0x05, 0x01, // Usage Page (Generic Desktop) 75
# 0x09, 0x33, // Usage (Rx) 77
# 0x09, 0x34, // Usage (Ry) 79
# 0x15, 0x00, // Logical Minimum (0) 81
# 0x26, 0xff, 0x00, // Logical Maximum (255) 83
# 0x75, 0x08, // Report Size (8) 86
# 0x95, 0x02, // Report Count (2) 88
# 0x81, 0x02, // Input (Data,Var,Abs) 90
# 0x06, 0x00, 0xff, // Usage Page (Vendor Defined Page 1) 92
# 0x09, 0x21, // Usage (Vendor Usage 0x21) 95
# 0x95, 0x36, // Report Count (54) 97
# 0x81, 0x02, // Input (Data,Var,Abs) 99
# 0x85, 0x05, // Report ID (5) 101
# 0x09, 0x22, // Usage (Vendor Usage 0x22) 103
# 0x95, 0x1f, // Report Count (31) 105
# 0x91, 0x02, // Output (Data,Var,Abs) 107
# 0x85, 0x03, // Report ID (3) 109
# 0x0a, 0x21, 0x27, // Usage (Vendor Usage 0x2721) 111
# 0x95, 0x2f, // Report Count (47) 114
# 0xb1, 0x02, // Feature (Data,Var,Abs) 116
# 0xc0, // End Collection 118
# 0x06, 0xf0, 0xff, // Usage Page (Vendor Usage Page 0xfff0) 119
# 0x09, 0x40, // Usage (Vendor Usage 0x40) 122
# 0xa1, 0x01, // Collection (Application) 124
# 0x85, 0xf0, // Report ID (240) 126
# 0x09, 0x47, // Usage (Vendor Usage 0x47) 128
# 0x95, 0x3f, // Report Count (63) 130
# 0xb1, 0x02, // Feature (Data,Var,Abs) 132
# 0x85, 0xf1, // Report ID (241) 134
# 0x09, 0x48, // Usage (Vendor Usage 0x48) 136
# 0x95, 0x3f, // Report Count (63) 138
# 0xb1, 0x02, // Feature (Data,Var,Abs) 140
# 0x85, 0xf2, // Report ID (242) 142
# 0x09, 0x49, // Usage (Vendor Usage 0x49) 144
# 0x95, 0x0f, // Report Count (15) 146
# 0xb1, 0x02, // Feature (Data,Var,Abs) 148
# 0x85, 0xf3, // Report ID (243) 150
# 0x0a, 0x01, 0x47, // Usage (Vendor Usage 0x4701) 152
# 0x95, 0x07, // Report Count (7) 155
# 0xb1, 0x02, // Feature (Data,Var,Abs) 157
# 0xc0, // End Collection 159
# 0x05, 0x01, // Usage Page (Generic Desktop) 160
# 0x09, 0x04, // Usage (Joystick) 162
# 0xa1, 0x01, // Collection (Application) 164
# 0x85, 0x30, // Report ID (48) 166
# 0x06, 0x01, 0xff, // Usage Page (Vendor Usage Page 0xff01) 168
# 0x09, 0x02, // Usage (Vendor Usage 0x02) 171
# 0x95, 0x07, // Report Count (7) 173
# 0x91, 0x02, // Output (Data,Var,Abs) 175
# 0x85, 0x31, // Report ID (49) 177
# 0x95, 0x7e, // Report Count (126) 179
# 0x75, 0x10, // Report Size (16) 181
# 0x05, 0x10, // Usage Page (Unicode) 183
# 0x19, 0x01, // Usage Minimum (1) 185
# 0x2a, 0xff, 0xff, // Usage Maximum (65535) 187
# 0xb1, 0x40, // Feature (Data,Arr,Abs,Null) 190
# 0xc0, // End Collection 192
#
R: 193 05 01 09 05 a1 01 85 01 09 30 09 31 09 32 09 35 15 00 26 ff 00 75 08 95 04 81 02 09 39 15 00 25 07 35 00 46 3b 01 65 14 75 04 95 01 81 42 65 00 05 09 19 01 29 0e 15 00 25 01 75 01 95 0e 81 02 06 00 ff 09 20 75 06 95 01 81 02 05 01 09 33 09 34 15 00 26 ff 00 75 08 95 02 81 02 06 00 ff 09 21 95 36 81 02 85 05 09 22 95 1f 91 02 85 03 0a 21 27 95 2f b1 02 c0 06 f0 ff 09 40 a1 01 85 f0 09 47 95 3f b1 02 85 f1 09 48 95 3f b1 02 85 f2 09 49 95 0f b1 02 85 f3 0a 01 47 95 07 b1 02 c0 05 01 09 04 a1 01 85 30 06 01 ff 09 02 95 07 91 02 85 31 95 7e 75 10 05 10 19 01 2a ff ff b1 40 c0
I am still trying to decode this myself and trying to figure out how to modify this - maybe someone could help. I am seeing 3 collections, which matches 3 probes, but I do not think 3 collections are meant to cause 3 probes to be called.
I think the 3 interface descriptors correspond to the 3 probes. Notice how the HID version matches the dmesg output.
My G29 has only 2 interface descriptors. Here's the lsusb output for reference:
Bus 007 Device 005: ID 046d:c24f Logitech, Inc.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x046d Logitech, Inc.
idProduct 0xc24f
bcdDevice 89.00
iManufacturer 1
iProduct 2
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0042
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 4
bmAttributes 0x80
(Bus Powered)
MaxPower 200mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.11
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 123
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 2
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 2
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.11
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 54
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0014 1x 20 bytes
bInterval 2
G29 got PC compatibility and switch between PS3 and PS4 compatiblity(now sure, but it probably changes descriptors).
G923 is PC, PS4 and PS5 compatible without any switches. And it got this "Trueforce", so maybe it's another interface. After reading it's based on separate audio channel from game, I started wondering if it works as sound card and if it's processed by machine or wheel firmware itself (all we know that unlike Thrustmaster "T-DFB" technology built-in T-GT wheel, its not based on additional speaker inside, so maybe this feature could be backported to G29, which, except colors, is identical wheel to G923 ;-)
sorry for SPAM and offtopic.
On 10/26/20, Bernat notifications@github.com wrote:
I think the 3 interface descriptors correspond to the 3 probes. Notice how the HID version matches the dmesg output.
My G29 has only 2 interface descriptors. Here's the lsusb output for reference:
Bus 007 Device 005: ID 046d:c24f Logitech, Inc. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x046d Logitech, Inc. idProduct 0xc24f bcdDevice 89.00 iManufacturer 1 iProduct 2 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0042 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 4 bmAttributes 0x80 (Bus Powered) MaxPower 200mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.11 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 123 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0010 1x 16 bytes bInterval 2 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 2 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.11 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 54 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0014 1x 20 bytes bInterval 2
-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/ZRtmWrJqXcjbqBLIMBYMCeUw/Logitech-G923-Linux-Kernel-Driver/issues/1#issuecomment-716464512
It has been a while and I thought I should give a quick update.
After @berarma's comment with the lsusb
output of the G29, I was able to piece together a few things. I checked the code here and noticed the second interface was being ignored completely. So I tried some things along those lines and wanted to document some of my results here:
As mentioned in a previous comment, the first interface in the G923 provides the inputs (still not entirely sure what these are but they are important), the second interface defines the HID++ short and long reports, and the third interface I am still unsure of. I tried allowing the probing of one interface at a time (similar to here, basically ignoring all but one interface ID, a.k.a. iInterface
, but this did not result in the wheel magically working, sadly.
I then thought of modify the HID descriptor for either the first or second interface so that either the first interface includes a definition for the appropriate HID++ reports or have the second interface include the input reports from the first interface. I am able to extract the HID report using hid-tools from the first interface (see above comment) but I get nothing when trying to extract the HID report of the second interface.
As a side note, the reason we are getting that ignoring exceeding usage max
is because the Usage Maximum
in the last collection of the HID report for the first interface is set to 0xFFFF
or 65535
. Changing that to 0xFF
or 255
got rid of that warning.
After some thought, I realized the HID descriptors are probably tied closely to the hardware and additionally considering the difference in bcdHID
(HID version number) between the two interfaces (first interface is 1.10 while the second interface is 1.11), there is a good chance making such drastic changes tot he HID descriptor will likely not work. Please correct me if I am wrong here.
The other approach I am now considering is having the hid-logitech-hidpp
driver treat the multiple interfaces of the G923 properly, sending HID++ output to the second interface and receiving input from the first interface. Again, I am not sure if this is correct or not, so please correct me if I am wrong. For the time being, I will look further into this to see what I can find.
After some more thinking and testing, I have made a few realizations.
There are two issues we are dealing with here:
hidpp_ff_init
are generated and add them for this interface.I have been working on creating a proper HID report descriptor for interface 0 but I will be creating a separate issue for it as it is unrelated to this "No inputs found" issue; see issue #2.
Curious what kernel version you patched against for all this. I tried with Ubuntu 18.04 kernel but it seems that a bunch of stuff changed compared to your version. With fuzzing, 2 hunks fail on the hid-logitech-hidpp.c file, and even if I merge them in, it doesn't like the &data you are passing to g923_get_config().
Currently Ubuntu 18.04 is at 4.15.0-128-generic, and I am up for tinkering with some patches. Otherwise, it seems that about all I can get Steam to detect is a generic X-Box controller (buttons work etc.). Would be cool to see if it can detect.
@mcgrathd The current patch is probably outdated as I have been struggling to make progress. Regardless, I believe the current patch was written with version 5.8 of the kernel (5.8.11, I think) - I am running Arch Linux. Most of the patch is not even necessary. To get the wheel detected, the most important points are:
hid-ids.h
hid_device_id
struct in the hidpp_devices[]
array in hid-logitech-hidpp.c
If you do not wish to install the newly built kernel, you will have to install the hid-logitech-hidpp.ko
module with insmod
.
Again, this will only make your computer detect the device as a G923 Logitech device but you will not get much more functionality than you have currently seen (i.e. some buttons working).
I have been trying to figure out how the wheel works on windows to get clue on how to make it work. I have been analyzing USB packet captures from connecting the device to a Windows 10 virtual machine and after having tried every single short and long report that is sent to the device, which did not work, I am suspecting it is one of the two SET CONFIGURATION
packets. Still trying to figure out what this means but this would make sense as a solution.
@mcgrathd The current patch is probably outdated as I have been struggling to make progress. Regardless, I believe the current patch was written with version 5.8 of the kernel (5.8.11, I think) - I am running Arch Linux. Most of the patch is not even necessary. To get the wheel detected, the most important points are:
- Define the device ID in
hid-ids.h
- Define the
hid_device_id
struct in thehidpp_devices[]
array inhid-logitech-hidpp.c
If you do not wish to install the newly built kernel, you will have to install the
hid-logitech-hidpp.ko
module withinsmod
.Again, this will only make your computer detect the device as a G923 Logitech device but you will not get much more functionality than you have currently seen (i.e. some buttons working).
I kinda figured about the USB ID and registering the quirks. The original patch I pretty much gave up on, due to differences in the API and lack of understanding on the changes, and tried just using a renamed g920 set of code.
In the end it loaded on boot just fine due to the system seeing the ID, which is kinda a given, but it didn't even show up in the jstest-gtk app at that point. Also unloading was failing due to in-use resource, which ultimately caused a kernel panic on shutdown. Was worth a shot though.
For reference, this is the patch I was testing against Ubuntu 18.04 kernel 4.15.0-126-generic:
Closing this issue as more information has emerged detailing how the G923 operates. See #3.
The following
dmesg
output is seen with the current state of the patch (basically just adding some id's):The wheel seems to connect multiple times (3 times). The "no inputs found" error is raised when
hidpp_ff_init
is called during the second connection (/input1 above) due to thehidpp->hid_dev->inputs
list being empty. This list is populated upon the first connection attempt (/input0 above). I am not sure if there are supposed to be multiple connection attempts (there are 2 calls tohid_hw_start
inhidpp_probe
) but that may not work with this wheel. Not sure idhidpp->hid_dev->inputs
is supposed to be "carried over", either.