Another USBQemu plugin, this time in VB.net (Keyboard only)

[FlatOut]

I just managed to reproduce it, but I don't know what caused it. I did notice that if you switch back to USBnull and then back to the plugin, it will stop working without the crash you get when hotswapping different versions of the plugin. But unlike the blocking issue this, as described earlier, can't be fixed without rebooting because of the PCSX2 issue.

[gh0stp1rate]

Investigating further.

Codebreaker does seem to initialise the USB controller, but doesn't seem to detect a keyboard

Codebreaker seems to disable interrupts and repetitively read HcRhDescriptorA (0x1F801648)

I tried to use PCSX2's debugger to try and figure out what it is doing with the result, but I can't seem to breakpoint on IOP instructions.

ARMax and GameShark should work. but I'm at a loss as to what specificity the issue with codebreaker is.

Yup, confirming it works with ARMax and GameShark, thanks!

[Kamijou Touma]

Yup, confirming it works with ARMax and GameShark, thanks!

Also noticed that if Lilypad is in DirectInput Mode then keyboard input on CLRUSB does not work.

[Ge-Force]

Also noticed that if Lilypad is in DirectInput Mode then keyboard input on CLRUSB does not work.

This should only be an issue if CLRUSB is in RawAPI mode (for clarification)

[FlatOut]

I see you've added a new commit on github, but that makes it spam the following in the log.

Code:

usbkeybd0: led_transfer_done -> 0x4

In my own build I solved it by simply adding bool checks, if NumLockOn and not Already_NumLockOn Then...

[Kamijou Touma]

This should only be an issue if CLRUSB is in RawAPI mode (for clarification)

Nope it also happens in Windows Messaging mode.

[Ge-Force]

This should only be an issue if CLRUSB is in RawAPI mode (for clarification)

Tracked down what was causing this and it should hopefully be fixed in the next version. Edit: ignore that.
Direct Input apparently suppresses normal Keyboard messages when it is used to capture keyboard input.
That being said, MS has recommended against using DirectInput for reading keyboard input.

I see you've added a new commit on github, but that makes it spam the following in the log.

Code:

usbkeybd0: led_transfer_done -> 0x4

In my own build I solved it by simply adding bool checks, if NumLockOn and not Already_NumLockOn Then...

That commit had some unrelated changes to emulation included from when I was trying to figure out why CodeBreaker wasn't detecting a keyboard.

What game are you having the log spam in?

[Kamijou Touma]

Tracked down what was causing this and it should hopefully be fixed in the next version. Edit: ignore that.
Direct Input apparently suppresses normal Keyboard messages when it is used to capture keyboard input.
That being said, MS has recommended against using DirectInput for reading keyboard input.


That commit had some unrelated changes to emulation included from when I was trying to figure out why CodeBreaker wasn't detecting a keyboard.

What game are you having the log spam in?

Does MS give any input on when/how to detect when Direct Input Mode is on?