Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 9 of 9

Thread: Custom Teensyduino HID Type Not Seen by Software

  1. #1
    Junior Member
    Join Date
    Jul 2020
    Posts
    5

    Custom Teensyduino HID Type Not Seen by Software

    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

    usb.c
    usb_api.cpp
    usb_api.h
    usb_private.h

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

    Here are examples of the packets being sent:

    • 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


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

    DrivingSim.ino

    Any help would be appreciated, as I am new to USB HID and it will help me learn.

  2. #2
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    7,142
    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

  3. #3
    Junior Member
    Join Date
    Jul 2020
    Posts
    5
    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?

  4. #4
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    7,142
    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.

  5. #5
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    22,285
    Quote Originally Posted by yeastbeast View Post
    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.

  6. #6
    Junior Member
    Join Date
    Jul 2020
    Posts
    5
    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.

  7. #7
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    7,142
    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
            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)
            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

  8. #8
    Junior Member
    Join Date
    Jul 2020
    Posts
    5
    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 by yeastbeast; 07-14-2020 at 02:29 AM.

  9. #9
    Junior Member
    Join Date
    Jul 2020
    Posts
    5
    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/t...hid-drivingsim for anyone to use and modify, and will be including installation and linking instructions at some point.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •