@pik33 said:
This is the mouse alone (endless debug reports)
Okay, fails at SetIdle. I think there was an issue like that before (like, way before, when building the initial gamepad driver), maybe I'll just make it ignore errors on that one.
Mind that there currently isn't a nice interface to the keyboard. Currently you can only check the momentary status of keys. Still need to implement a key queue. That, as mentioned, will be scancodes-only. Simple US layout to ASCII conversion can be implemented in high-level code with a few lines, so no big deal. More complex layouts with more layers, deadkeys, non-ASCII characters, etc should be implemented in high-level code.
Also, the API particulars may still change, in general.
A scancode queue is enough. We need press and release info in the queue - old style 8th bit? My Raspberry inteface uses MIDI style - key on, key off, modifier on, modifier off.
Okay, I've added a first version of the scancode queue. You need to set its size by constant override of KEYQUEUE_SIZE to enable it and then call get_key. Current format is as follows:
bit 0..7 is the scancode. The object defines a bunch of KEY_ constants that match these. Modifiers also generate their scancodes!
bit 8..15 is the current modifiers as in the USB report (left ctrl, left shift, left alt, left meta, right ctrl, right shift, right alt, right meta)
bit 16..30 are unused (should put caps/num/scroll lock state here when I add it)
There was a fairly simple Propeller1 object API for the older (PS/2) keyboards. Perhaps an API or wrapper layer could emulate that interface if it is still useful for Prop2's and if it maps cleanly to the USB keyboard variants. If it doesn't then designing another one makes sense.
@Wuerfel_21 said:
Okay, I've added a first version of the scancode queue. You need to set its size by constant override of KEYQUEUE_SIZE to enable it and then call get_key. Current format is as follows:
bit 0..7 is the scancode. The object defines a bunch of KEY_ constants that match these. Modifiers also generate their scancodes!
bit 8..15 is the current modifiers as in the USB report (left ctrl, left shift, left alt, left meta, right ctrl, right shift, right alt, right meta)
bit 16..30 are unused (should put caps/num/scroll lock state here when I add it)
@rogloh said:
There was a fairly simple Propeller1 object API for the older (PS/2) keyboards. Perhaps an API or wrapper layer could emulate that interface if it is still useful for Prop2's and if it maps cleanly to the USB keyboard variants. If it doesn't then designing another one makes sense.
You could probably make a wrapper to that extent, yea. The P1 PS/2 object does perform ASCII conversion (but weirdly where the special keys are mapped to strange characters) and uses different scancodes, etc etc. The biggest API difference is that it doesn't give you key break events. Might need to add a function to the USB driver that gets the next event without consuming it to make that fully wrappable.
I've just pushed a change to remove gamepad-related bloat when neither the HIDPad nor EmuPad interface is enabled. It's not mega thorough, but it saves ~1.9k RAM. Maybe not for long though, the mouse might need to share some of the HID-related code when I make it properly parse the reports.
I tried this cursed wireless gamepad. Of course it doesn't work. When connected standalone, it returns this:
When connected via the hub, the result is too long for the forum post and the driver needs resetting.
Edit: I tried this with debug disabled. The pad doesn't hang the driver in this mode. Hanging is caused by the pad+debug enabled at default 200 kbps. 2Mbps helped...
The result is interesting: first, the pad data that seems to be correct appears on the screen. Then the pad field goes gray for a second and then it is white again, but displaying garbage and doesn't respond to any pad movement. The keyboard and mouse still work with the pad attached.
May just really be cursed, just like my 8bitdo pad.
In other news, I've fixed a possible race condition with the keyboard state buffer (i.e. trying to check key while the driver is re-writing the report leading to false negative). I didn't actually observe this happening, but in theory it was possible. (and it still is possible if you access the keyboard buffer byte-wise. The correct way is to burst-read the entire thing at once)
Edit: and yes, it works immediately after connecting.... One, two second, it react to movement and gives the proper numbers... until it decides to go gray and return in non working state
Yea, it changes up its descriptors. That sounds like the same weird auto-detect routine that my 8bitdo pad does, though that one does never ever return valid data (but does respond to XInput rumble/LED control messages when it gets stuck in XInput mode). Wonder what message these are expecting from a PC that we're not sending?
The second descriptor looks very normal, so either the data coming out is bad or something weird happens to the driver itself.
There is a sign of life. The driver reacts to the button called "analog": Y and Z values blink. Is there a way to simply dump the raw reports somewhere?
@pik33 said:
There is a sign of life. The driver reacts to the button called "analog": Y and Z values blink. Is there a way to simply dump the raw reports somewhere?
The "analog" button usually switches the stick and dpad to deal with old PC games that want to pull digital directions from the X/Y axis (why this couldn't be fixed in software, idk). If the values react to the analog switch but not the actual inputs, that means the controller itself must have gotten into a bad state where it doesn't properly read the inputs.
Right now there is no way to read the raw reports, since they all share a buffer and get overwritten when the next device is polled. However, I have attached a hacked version that prints it to DEBUG. Might not work right due to timing issues.
Maybe I should start a list of which game input devices which work and which don't, so people know what to buy / not buy. Well, half the ones I have are old and discontinued, but oh well.
I think most controllers marketed specifically towards Nintendo Switch usage will work? My sample size is 1... Maybe I should buy the actual 1st party Pro Controller to test with, would be nice to have for the actual Nintendo, too.
@Wuerfel_21 said:
Okay, I've added a first version of the scancode queue. You need to set its size by constant override of KEYQUEUE_SIZE to enable it and then call get_key. Current format is as follows:
bit 0..7 is the scancode. The object defines a bunch of KEY_ constants that match these. Modifiers also generate their scancodes!
bit 8..15 is the current modifiers as in the USB report (left ctrl, left shift, left alt, left meta, right ctrl, right shift, right alt, right meta)
bit 16..30 are unused (should put caps/num/scroll lock state here when I add it)
bit 31 is press/release
You get zero when the buffer is empty.
I've also added this to the hidpad example.
This is impressive work.
Maybe the thread title could be edited slightly to be ( as there is now P2 USB device work )
P2 USB Host driver (re-)development thread
Yes, It is in the P2 sub-forum, but adding P2 to the title helps google find things ?
@rogloh said:
... Hopefully by the end of it all we'll have a Keyboard,Mouse and 2 USB controllers working together from a 4 port hub. That would be ideal for me anyway.
and one day later ...
@rogloh said:
@Wuerfel_21 Just tried your latest code, and I have **2 USB gamepads, a mouse and a keyboard all fitted to a 4 port USB hub and each reporting nicely **running hidpad_to_vga.spin2. Nice work
If you want to acquire a usbnew (is that what I'm calling it?) compatible controller, do peruse the "works great" list.
If anyone has any other reports, please send me:
- Name / Model number
- VID/PID (visible in the HIDpad test)
- (if not broken) Which button number is which physical button (so I can write a PADMAP rule on the wiki)
Working game controllers I have tested with usbnew.
PS3 DualShock3 controller - already reported
ID=054C0268
All buttons, sticks & HAT reporting. Right analog Joystick Up and Down both reported in Z-AXIS?
Generic USB game controller (SNES style) works well, all buttons.
ID=081FE401
Generic control board marketed as "Zero Delay Arcade USB encoder" or "ARC Controller" etc works well
ID=00790006
Comments
Okay, fails at SetIdle. I think there was an issue like that before (like, way before, when building the initial gamepad driver), maybe I'll just make it ignore errors on that one.
Yea, that was a thing, we don't even do SetIdle on gamepads currently.
@pik33 try this one
Reset without anything on usb, plugged in kbd+mouse. Kbd works
Is that with the newer file I just posted?
I hoppe yes, but let's copy it again...
Edit: it works now. It seems I copied the file with Flexprop still opened.
The debug:
As it works now, I can replace my RPi contraption with the USB accessory board and add the driver to the Prop2play
Much simpler solution.
Mind that there currently isn't a nice interface to the keyboard. Currently you can only check the momentary status of keys. Still need to implement a key queue. That, as mentioned, will be scancodes-only. Simple US layout to ASCII conversion can be implemented in high-level code with a few lines, so no big deal. More complex layouts with more layers, deadkeys, non-ASCII characters, etc should be implemented in high-level code.
Also, the API particulars may still change, in general.
A scancode queue is enough. We need press and release info in the queue - old style 8th bit? My Raspberry inteface uses MIDI style - key on, key off, modifier on, modifier off.
Okay, I've added a first version of the scancode queue. You need to set its size by constant override of
KEYQUEUE_SIZEto enable it and then callget_key. Current format is as follows:You get zero when the buffer is empty.
I've also added this to the hidpad example.
There was a fairly simple Propeller1 object API for the older (PS/2) keyboards. Perhaps an API or wrapper layer could emulate that interface if it is still useful for Prop2's and if it maps cleanly to the USB keyboard variants. If it doesn't then designing another one makes sense.
You could probably make a wrapper to that extent, yea. The P1 PS/2 object does perform ASCII conversion (but weirdly where the special keys are mapped to strange characters) and uses different scancodes, etc etc. The biggest API difference is that it doesn't give you key break events. Might need to add a function to the USB driver that gets the next event without consuming it to make that fully wrappable.
I've just pushed a change to remove gamepad-related bloat when neither the HIDPad nor EmuPad interface is enabled. It's not mega thorough, but it saves ~1.9k RAM. Maybe not for long though, the mouse might need to share some of the HID-related code when I make it properly parse the reports.
I tried this cursed wireless gamepad. Of course it doesn't work. When connected standalone, it returns this:
When connected via the hub, the result is too long for the forum post and the driver needs resetting.
Edit: I tried this with debug disabled. The pad doesn't hang the driver in this mode. Hanging is caused by the pad+debug enabled at default 200 kbps. 2Mbps helped...
The result is interesting: first, the pad data that seems to be correct appears on the screen. Then the pad field goes gray for a second and then it is white again, but displaying garbage and doesn't respond to any pad movement. The keyboard and mouse still work with the pad attached.
May just really be cursed, just like my 8bitdo pad.
In other news, I've fixed a possible race condition with the keyboard state buffer (i.e. trying to check key while the driver is re-writing the report leading to false negative). I didn't actually observe this happening, but in theory it was possible. (and it still is possible if you access the keyboard buffer byte-wise. The correct way is to burst-read the entire thing at once)
This is the proper debug report from the pad.
Edit: and yes, it works immediately after connecting.... One, two second, it react to movement and gives the proper numbers... until it decides to go gray and return in non working state
Yea, it changes up its descriptors. That sounds like the same weird auto-detect routine that my 8bitdo pad does, though that one does never ever return valid data (but does respond to XInput rumble/LED control messages when it gets stuck in XInput mode). Wonder what message these are expecting from a PC that we're not sending?
The second descriptor looks very normal, so either the data coming out is bad or something weird happens to the driver itself.
There is a sign of life. The driver reacts to the button called "analog": Y and Z values blink. Is there a way to simply dump the raw reports somewhere?
The "analog" button usually switches the stick and dpad to deal with old PC games that want to pull digital directions from the X/Y axis (why this couldn't be fixed in software, idk). If the values react to the analog switch but not the actual inputs, that means the controller itself must have gotten into a bad state where it doesn't properly read the inputs.
Right now there is no way to read the raw reports, since they all share a buffer and get overwritten when the next device is polled. However, I have attached a hacked version that prints it to DEBUG. Might not work right due to timing issues.
Maybe I should start a list of which game input devices which work and which don't, so people know what to buy / not buy. Well, half the ones I have are old and discontinued, but oh well.
I think most controllers marketed specifically towards Nintendo Switch usage will work? My sample size is 1... Maybe I should buy the actual 1st party Pro Controller to test with, would be nice to have for the actual Nintendo, too.
Before going bad:
Cog2 hdev_port = 3 RAW REPORT: urx_buff_p = $00, $00, $0F, $80, $80, $80, $80,
$00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $02, $00, $02,
$00, $02, $00, $02
After going bad:
Cog2 hdev_port = 3 RAW REPORT: urx_buff_p = $02, $00, $00, $00
4 bytes only.
That's why it's sad I guess
I started filling out the aforementioned compatibility list: https://github.com/Wuerfel21/usbnew/wiki
Works only 2 seconds after connecting, then stops working: Vakoss wireless gamepad model no GP-3925BK, VID=0x0079 PID=0x181C
This is impressive work.
Maybe the thread title could be edited slightly to be ( as there is now P2 USB device work )
P2 USB Host driver (re-)development thread
Yes, It is in the P2 sub-forum, but adding P2 to the title helps google find things ?
and one day later ...
Impressive stack-up that is supported.
I think I went through all the game controller shaped e-waste that's lying around my basement now: https://github.com/Wuerfel21/usbnew/wiki
If you want to acquire a usbnew (is that what I'm calling it?) compatible controller, do peruse the "works great" list.
If anyone has any other reports, please send me:
- Name / Model number
- VID/PID (visible in the HIDpad test)
- (if not broken) Which button number is which physical button (so I can write a PADMAP rule on the wiki)
I've also written up the PADMAP information on the wiki, alongside enlightening rationale behind using terms like "north face button", featuring mspaint fingies: https://github.com/Wuerfel21/usbnew/wiki/PADMAP.TXT-Format-and-the-reference-gamepad
Is the simplified format description at the top enough?
Working game controllers I have tested with usbnew.
PS3 DualShock3 controller - already reported
ID=054C0268
All buttons, sticks & HAT reporting. Right analog Joystick Up and Down both reported in Z-AXIS?
Generic USB game controller (SNES style) works well, all buttons.
ID=081FE401
Generic control board marketed as "Zero Delay Arcade USB encoder" or "ARC Controller" etc works well
ID=00790006
0483-9005 Interface for a retro DB9 joystick. Works.
https://allegro.pl/oferta/retrofun-adapter-podlacz-retro-joystick-do-pc-12512264974