You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, I've done this kind of thing, years ago on PDP-11s. I don't see you even passing the vendor and product id to the OTG side.
I thought I was clever, back then, when I set the output port's control block for features and status to be the same as the controlling input side. Then, my friend Jeff showed me his version where he got the address of the interrupt service routine for input and did something that delivered the character to the output.
Anyway, I'm trying to make arbitrary keyboards work for a reason. It turns out that my fancy mechanical keyboards are mostly gaming keyboards because thats the only way to get data-processing level switches and keycaps. I need to use a KVM. KVMs really don't like gaming keyboards. Hence, put a Pi in the middle,
Is the output side getting this information in a side effect that I can't find in the code?
I would prefer to do your "suitable device" check against the protocol field, which is 1 for keyboards.
I'm going to do some experimental programming and debugging.
My plan: if the device is a keyboard, just forward it. That's because it isn't going to do anything crazy--after all, the user has this keyboard and could plug it directly into the machine being controlled.
I can see so many applications for pi400kb. I would always want a Pi in between my keyboard and the host.
My best to you,
Eirikur
The text was updated successfully, but these errors were encountered:
IIRC the VID/PID are used mostly to "grab" a specific keyboard device for forwarding.
At the moment it does a low level protocol forward of the keyboard, mirroring (for the most part) its descriptors and forwarding the raw packets. I don't know how necessary this is, since most keyboard should behave more or less the same.
I'd love to create some kind of HID mirror setup where any HID device you connect to the Pi (including its own built-in keyboard) gets mirrored onto OTG with the same descriptor info and the raw data copied over. This is antithetical to trying to do anything fancy with the keyboard data in flight.
Definitely hack away! I have been buried in work and unable to play with this, but I'd love to see what you come up with.
(Note, pi400kb is very hacked together and definitely doesn't represent the state of the art in keyboard forwarding 😆)
Hi, I've done this kind of thing, years ago on PDP-11s. I don't see you even passing the vendor and product id to the OTG side.
I thought I was clever, back then, when I set the output port's control block for features and status to be the same as the controlling input side. Then, my friend Jeff showed me his version where he got the address of the interrupt service routine for input and did something that delivered the character to the output.
Anyway, I'm trying to make arbitrary keyboards work for a reason. It turns out that my fancy mechanical keyboards are mostly gaming keyboards because thats the only way to get data-processing level switches and keycaps. I need to use a KVM. KVMs really don't like gaming keyboards. Hence, put a Pi in the middle,
Is the output side getting this information in a side effect that I can't find in the code?
I would prefer to do your "suitable device" check against the protocol field, which is 1 for keyboards.
I'm going to do some experimental programming and debugging.
My plan: if the device is a keyboard, just forward it. That's because it isn't going to do anything crazy--after all, the user has this keyboard and could plug it directly into the machine being controlled.
I can see so many applications for pi400kb. I would always want a Pi in between my keyboard and the host.
My best to you,
Eirikur
The text was updated successfully, but these errors were encountered: