Custom Teensyduino HID Type Not Seen by Software

Status
Not open for further replies.
I am working on a custom HID type for driving simulators that I forked directly from the Teensyduino "Keyboard+Mouse+Joystick" HID type. I only changed the joystick report descriptor (which is now 3 joystick axes), the size of the packets being sent (12 bytes to 8 bytes) and the joystick report data arrays and methods in the "usb_api.cpp" and "usb_api.h" files. All should be working correctly, and when I view the packets being sent with usbhid-dump, they are correct and are like the original type (Keyboard+Mouse+Joystick), just in a different place. However, the game which I am using to test, American Truck Simulator, doesn't detect the joystick axis input, which it did perfectly on the original type.

I am including the files (that i have changed) contained in
Code:
(arduino root)/hardware/teensy/avr/cores/usb_drivingsim/[CODE], my directory for the custom type

[ATTACH]20932._xfImport[/ATTACH]
[ATTACH]20933._xfImport[/ATTACH]
[ATTACH]20934._xfImport[/ATTACH]
[ATTACH]20935._xfImport[/ATTACH]

The original type is contained in [CODE](arduino root)/hardware/teensy/avr/cores/usb_hid/[CODE]

Here are examples of the packets being sent:

[LIST]
[*]All axes at 0 [CODE]00 00 00 00 00 00 00 00
[*]First axes all the way on
Code:
FF 03 00 00 00 00 00 00
[*]Second axis
Code:
00 FE 0F 00 00 00 00 00
[*]Third axis
Code:
00 00 F0 3F 00 00 00 00
[*]All axes on
Code:
FF FF FF 3F 00 00 00 00
[/LIST]

My operating system is Ubuntu 18.04.4 LTS and my hardware is the Teensy 2.0 programmed on Arduino.

View attachment DrivingSim.ino

Any help would be appreciated, as I am new to USB HID and it will help me learn.
 
Sorry I have not done any of this with T2.x boards. And mostly I have handled from the other side. USBHost_t36,

but I know that some of these systems are picky. For example I believe most systems require that the packet sizes be a multiple of 8 bits (
My quick look through yours shows it as simply 3 10 bit fields so 30 bits which is not a multiple of 8.
You will see in some of the hids a reserved field or defined as constant. That you might try adding another field of 2 bits
 
Thank you for the reply. I altered the report descriptor to add two buttons after the 3-axis collection:
Code:
        0x15, 0x00,                     // Logical Minimum (0)
        0x25, 0x01,                     // Logical Maximum (1)
        0x75, 0x01,                     // Report Size (1)
        0x95, 0x02,                     // Report Count (2)
        0x05, 0x09,			// Usage Page (Button)
	0x19, 0x01,			// Usage Minimum (Button #1)
	0x29, 0x02,			// Usage Maximum (Button #2)
	0x81, 0x02,			// Input (variable,absolute)

However, this did not fix the issue. Perhaps I could try some other game or software to test whether its being picked up. Any suggestions?
 
Again hopefully someone who does stuff like this might give you some other suggestions.

But again if it were me, I would plug it into my Ubuntu machine and see what shows up.

Does a joystick object show up. I am rusty on the ubuntu device map for these, but probably something like: /dev/input/js0
I would also look at system debug output to see what devices were created and any messages, something like: dmesg | tail -40
I would then probably try running linux app like jstest or the gui version, something like jstest-gtk? And see if it will show you stuff...

Beyond that, if I ran into issues, I would probably dump the hid data on the linux machine to see if it comes out correctly.

Hopefully others may have suggestions.
 
Perhaps I could try some other game or software to test whether its being picked up. Any suggestions?

On Linux, run "jstest".

Also a good idea to run "tail -f /var/log/syslog" or whatever command your distro needs to watch the kernel's log messages. If it doesn't like something about the USB device, sometimes you'll get a helpful (or not-so-helpful) kernel message.
 
Ok, so after viewing the syslogs when plugging in the custom vs. original device, the only difference appears to be this error:
Code:
usb 3-3: input irq status -75 received
which is a kernel error "EOVERFLOW".

The error occurs on linux systems on my desktop and laptop, so I can confirm that it is not a kernel issue, but a device issue.

I will look through the code more closely to see if I can spot the error, but I thought everything size-related was changed.
 
Again, it might help to see the whole updated descriptor...
Before I believe you had:

Code:
#ifdef JOYSTICK_INTERFACE
static const uint8_t PROGMEM joystick_hid_report_desc[] = {
        0x05, 0x01,                     // Usage Page (Generic Desktop)
        0x09, 0x04,                     // Usage (Joystick)
        0xA1, 0x01,                     // Collection (Application)
        0x05, 0x01,                     // Usage Page (Generic Desktop)
	0x09, 0x01,			// Usage (Pointer)
        0xA1, 0x00,                     // Collection ()
	0x15, 0x00,			//   Logical Minimum (0)
	0x26, 0xFF, 0x03,		//   Logical Maximum (1023)
	0x75, 0x0A,			//   Report Size (10)
	0x95, 0x03,			//   Report Count (3)
	0x09, 0x30,			//   Usage (X)
	0x09, 0x31,			//   Usage (Y)
        0x09, 0x32,                     //   Usage (Z)
	0x81, 0x02,			//   Input (variable,absolute)
        0xC0,                           // End Collection
 [COLOR="#FF0000"]       0x15, 0x00,                     // Logical Minimum (0)
        0x25, 0x01,                     // Logical Maximum (1)
        0x75, 0x01,                     // Report Size (1)
        0x95, 0x02,                     // Report Count (2)
        0x05, 0x09,			// Usage Page (Button)
	0x19, 0x01,			// Usage Minimum (Button #1)
	0x29, 0x02,			// Usage Maximum (Button #2)
	0x81, 0x02,			// Input (variable,absolute)[/COLOR]
        0xC0                            // End Collection
};
#endif

So the question would be where did you put these two bits?
Also I am not sure, that maybe Button fields need again to be multiple of 8 bits?

Also I believe your files say that the report size was 8, but I only see 32 bits of data or 4 bytes
 
I have found the issue! It was that I was sending 8 bytes (although the last 4 were 0x00), but the report descriptor only stated that 4 bytes were being sent. Changing the button report count and usage maximum to 0x22 (34), I defined 8 bytes of data to be sent.

The game now recognizes the three axes, but jstest does not recognize them and fails with default settings. However, when running with --event, I see that it is somehow altering the time on the event(?):

Code:
Event: type 0, time 1611595776, number 0, value 0
Event: type 0, time 1611595814, number 0, value 0

Not a huge deal, but would be interesting to know what's going on here, as other games might function in the same way jstest is, and the teensy will not work on them.

Edit: As I suspected, F1 2017 does not pick up the input. Although it doesn't pick up the prebuilt setting of Joystick either, so idk what type it wants.
Edit2: Ok, turns out that game is just garbage for different devices. I can't even use my mouse!
 
Last edited:
Final note: jstest does work as expected when I test /dev/input/js*, so all is good. The device is recognized by Steam as a controller, so any game on Steam can recognized the controller when mapped in controller settings. Finally, the code is on my Github at https://github.com/geoffreyswisher/teensy-usbhid-drivingsim for anyone to use and modify, and will be including installation and linking instructions at some point.
 
Status
Not open for further replies.
Back
Top