Hi Giuseppe, On Sun, Jan 22, 2023 at 3:43 AM Giuseppe Bilotta <giuseppe.bilotta@xxxxxxxxx> wrote: > > Hello Roderick, > > I'm terribly sorry for the late reply, it's a bit of a busy period for > me and I have had less time than I wished to test things. > > > Thanks for your work so far. My first thought was 'yikes what an ugly > > device'. I'm not really sure what the best way of handling it is. > > The patch is beyond ugly (in addition to not working). But I'm barely > treading water here, I'm way out of my element, hence why I came to > the ML looking for help 8-) > > > First is the device a HID device? It would normally be picked up by > > hid-generic. You can try dumping the HID descriptors. > > I'm afraid this is not the case, at least as far as I can tell. Again, > keep in mind I'm not even exactly sure how to check these things out, > so please bear with me, and feel free to direct me to appropriate > resources. > What I have tried is to first plug the pad in with xpad blacklisted, > and lsusb -vs the device, which gave me: > > --8<----------------- > Bus 001 Device 006: ID 146b:0603 BigBen Interactive PC Compact Controller > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 2.00 > bDeviceClass 255 Vendor Specific Class > bDeviceSubClass 255 Vendor Specific Subclass > bDeviceProtocol 255 Vendor Specific Protocol > bMaxPacketSize0 64 > idVendor 0x146b BigBen Interactive > idProduct 0x0603 > bcdDevice 1.00 > iManufacturer 1 Bigben Interactive > iProduct 2 PC Compact Controller > iSerial 3 58B00422 > bNumConfigurations 1 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 0x0031 > bNumInterfaces 1 > bConfigurationValue 1 > iConfiguration 0 > bmAttributes 0x80 > (Bus Powered) > MaxPower 500mA > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 0 > bAlternateSetting 0 > bNumEndpoints 2 > bInterfaceClass 255 Vendor Specific Class You would normally expect bInterfaceClass to be 3 for 'Human Interface Device'. I recall Xbox controllers in general have this at a vendor specific value as they are not actual HID devices (with the exception of in Bluetooth mode recently). So it is not a formal HID device. > bInterfaceSubClass 93 > bInterfaceProtocol 1 > iInterface 0 > ** UNRECOGNIZED: 11 21 00 01 01 25 81 14 00 00 00 00 13 02 08 03 03 > 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 4 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x02 EP 2 OUT > bmAttributes 3 > Transfer Type Interrupt > Synch Type None > Usage Type Data > wMaxPacketSize 0x0040 1x 64 bytes > bInterval 8 > Device Status: 0x0000 > (Bus Powered) > --8<----------------- > > I also tried running usbhid-dump, that claimed there were “No matching > HID interfaces”. > > If I enable the xpad module shipping with my Debian sid distribution > (6.0.12-1 from 2022-12-09), there's no difference on the lsusb and > usbhid-dump outputs, > even though xpad seems to detect and bind with the device: > > --8<----------------- > [Jan23 05:33] usb 1-1: new full-speed USB device number 7 using xhci_hcd > [ +0.149801] usb 1-1: New USB device found, idVendor=146b, > idProduct=0603, bcdDevice= 1.00 > [ +0.000017] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 > [ +0.000008] usb 1-1: Product: PC Compact Controller > [ +0.000006] usb 1-1: Manufacturer: Bigben Interactive > [ +0.000006] usb 1-1: SerialNumber: 58B00422 > [ +0.068217] input: Generic X-Box pad as > /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0/input/input35 > [ +0.000114] usbcore: registered new interface driver xpad > --8<----------------- > > Is there some other tool I can use to inspect the HID descriptors or > check which protocols are supported, possibly depending on the device > initialization? The device doesn't seem to be a HID device, which is why there are no descriptors. I haven't looked at the Xbox protocol in detail, but I recall Xbox compatible devices report some magic value in some USB descriptor, which is picked up by drivers and hence no need for a formal driver unless overrides are needed. > (I have other gamepads whose behavior seems to depend on > initialization sequence, so this may be the case for this device too?) > > > It is a bit ugly if the device has to spawn multiple drivers. My > > initial gut feeling would have been to complete the support within the > > xpad driver. My understanding of our licensed controllers is that the > > HID protocol they use is different from the DS4 protocol, so it is > > really like handling an entire new device needing its own HID report > > parsing. So, no matter what each driver would have needed some changes > > to deal with the device properly and it is probably smallest in xpad. > > I don't have enough knowledge to know exactly what would be better, > but I would expect the protocol to be closer to the PS one than the > XBOX one, > even though out of the box it kind of works with xpad (modulo the > issues I mentioned). > I also have no idea how similar or different the PS and XBOX protocols > are, so it might just be that for the limited use and testing I've > done they match. So far it looks like the device is not a HID device, but only a USB device. If true, you can't leverage the HID drivers and need to be in a classic input driver such as xpad. I'm honestly not sure how this device is working on PlayStation if it is one of BigBen's licensed PlayStation compatible controllers. Our PS input stack is all HID based (at least to my knowledge). > > > You mention access flipping and then the touchpad. > > Axes mapping is weird, but I think my original issue was actually with > jstest-gtk not using the correct information. The CLI jstest seems to > report things correctly. > The “touchpad” is a rectangular area above the joysticks and between > the DPAD and the box/triangle/x/o buttons. I'm not entirely surely if > it's a touchpad or something else, > but it seems to be clickable “everywhere”. It's not detected or > exposed by the xpad driver in any way, but assume it would be > accessible in the protocol. > There's also something that looks like an audio jack. > The key question is to figure out how this touchpad works. Maybe some people in the community documented this somewhere. > I can run tests on this thing, but I really don't know what to try next. > > Thank you for your reply, and looking forward for things to try, > Giuseppe Bilotta > > Thanks, Roderick
