QB64.org Forum
Active Forums => QB64 Discussion => Topic started by: doppler on December 01, 2020, 08:28:00 pm
-
I got a USB HID dongle I would love to talk and listen from within QB64. I suspect heavy .DLL calls needed.
Generically if this works, it's the basis for talking to other HID's. Key FOB's and such.
It would be real nice to use QB64 as the interface to the HID.
I can't talk about the device, it's a company's closed loop product. The interfacing to it is classic HID.
-
@doppler
I'm sure there are some WinAPI libraries you can dig into to interface with USB devices. They could be too advanced for me to implement in QB64. Or, there could be a nice C/C++ library on GitHub somewhere. I'll do some digging tomorrow evening.
-
See if _DEVICES reads anything for you.
-
I'll see what I can do with _devices . Just for reference I ran the wiki example and only saw the standard 2 devices. Even If I plugged in an FTDI comm USB board. The FTDI maybe a special class HID device, like usb converters for flash and HDD's. So I might not see my company fob.
So I will play a bit.
-
@doppler
Take a look at this. I'm going to try building the DLL from this tonight and see if we can use this in QB64. If so, this could be a solution to your problem.
https://github.com/signal11/hidapi (https://github.com/signal11/hidapi)
-
Reading the github blurb. It looks interesting. That could work.
Secure fobs are very simple. Get a one time pass code. Send to key with info, or "the key contains the info (less secure way)". Key responds with an answer pass code. Send back to system making the challenge. The VPN or https connection continues. You are you and they know it. You can go to any system and be you. The key fob is really the key!
The idea to using QB64, the key fob doesn't know sh*t from shine-Nola (sp?). The key can be use by more that one system.
I really want to get pass the key fob thing. I am thinking along the lines of very small capacity flash for data storage. Since the flash drive is not being formatted for use by windows/or any other readable system. If I lose the flash, unless they have my program. The flash will only look like an un-formatted device. Or create a disk and leave it blank. But store what ever I want to it. In a very obscure location.
Only two scenario's . An blank flash or UN-used flash. Either one hides the true purpose.
-
Example information you will need for interfacing with an HID device is shown below. The VID and PID are the vendor ID and product ID, respectively. Those are the two arguments that will go into that hid_open function. You would just use the information that corresponds to the device you are using. I'll be sure to test it tonight and let you know what my findings are.
I've also found the WinAPI pages for using HID but I'm not sure how simple they are to implement. https://docs.microsoft.com/en-us/windows-hardware/drivers/hid/introduction-to-hid-concepts (https://docs.microsoft.com/en-us/windows-hardware/drivers/hid/introduction-to-hid-concepts)
[ This attachment cannot be displayed inline in 'Print Page' view ]
-
@doppler
So far it is going well! I built the 32 and 64 bit DLL for the hidapi and I've got it to interact at least this far!
[ This attachment cannot be displayed inline in 'Print Page' view ]
-
@SpriggsySpriggs
there's a more up to-date distribution which includes Windows DLL's https://github.com/libusb/hidapi/releases
-
there's a more up to-date distribution which includes Windows DLL's https://github.com/libusb/hidapi/releases
@jack
Thanks. I'll look at that tonight.
-
My god, I just realized I opened a can of worms here. Being selfish, I then realized the expand-ability of this interface. With this and a bit of magic you can! Use game console interfaces on QB64. Wired or wireless (with BT drivers). My PC has BT. And a whole bunch of other stuff. This could be a new code interface for QB64. Run 3D maze, Doom, Asteroids and a whole slew of other classics.
To create a game, just declare your controller (put the joystick interface to shame). And have at it. If this becomes stable soon enough, it has to go into V1.5
BTW, this is not limited to just gaming. A lot of industrial controls use some kind of controller interfaced to USB. There is lot's of money to be had selling into industry.
@SpriggsySpriggs Read my BTW last statement. Big incentive. (edit1)
-
@doppler
I hadn't thought of it being used like that. Interesting! Let's collaborate more on this as it goes!
My PC uses a Bluetooth dongle to interact with Bluetooth devices and I was able to display information about my controller when it was plugged in and when it was wireless. The description changed to reflect being wireless or not. I was able to grab 64 bytes of data from the controller in a loop and display it but I had no way of determining what it all meant. It would be interesting to see where this API takes us.
I'll be checking this out sometime this week as well:
https://github.com/dekuNukem/Nintendo_Switch_Reverse_Engineering/issues/7 (https://github.com/dekuNukem/Nintendo_Switch_Reverse_Engineering/issues/7)
https://github.com/dekuNukem/Nintendo_Switch_Reverse_Engineering/blob/master/USB-HID-Notes.md (https://github.com/dekuNukem/Nintendo_Switch_Reverse_Engineering/blob/master/USB-HID-Notes.md)
BTW, this is not limited to just gaming. A lot of industrial controls use some kind of controller interfaced to USB. There is lot's of money to be had selling into industry.
True, @doppler ! Making a program that interacts with a device on the HID packet level is quite literally making a custom device driver. You just have to decode the signals coming from the device and know what to send to the device. I wish I had a token USB thing like you have for those secure logins so I can do some testing with one of those.
-
If anyone's willing to buy me a Switch I'll port anything you get working to the Linux version of QB64 :)
More seriously though I'd like to port this, so I'll be watching to see what you learn.
-
If anyone's willing to buy me a Switch I'll port anything you get working to the Linux version of QB64 :)
More seriously though I'd like to port this, so I'll be watching to see what you learn.
@luke This library actually is cross platform as well! I've been looking at their stuff but unfortunately, since I use WSL2 and not a regular Linux setup, I don't have access to USB devices in the same manner. I wish they would hurry up and fix USB in WSL2 so I can mess with this on Ubuntu!!!
-
@doppler
I wish I had a token USB thing like you have for those secure logins so I can do some testing with one of those.
I happen to have one, but it's provided by my employer and I can't really mess with it. I wonder if anyone with one would be able to actually mess with theirs if they use it for actual security purposes.
-
I happen to have one, but it's provided by my employer and I can't really mess with it. I wonder if anyone with one would be able to actually mess with theirs if they use it for actual security purposes.
That's the problem with security FOB's, and the main reason I can't divulge anything. Companies that use FOB as part of the business control tightly use and distribution. If you get terminated, the first thing they get from you is the FOB. They care less about other equipment.
In government the FBI is in charge of security clearances and go "HANDS" on with recover/seizure. Don't mess with the 3 letter alphabet agencies. My present boss told about a guy in a agency who got booted one day. Two agents. His two arms. Grab'ed and speed escorted out of sight. They do this in high visibility, to show everyone what happens to dodgy people.
-
They have some kind of security fobs online on Amazon but I'm not sure if they would/could be used in the same manner. Oh well. And like you were saying about things being locked down; it would probably be nigh impossible to find documentation on the device to figure out what packets to send. I'm just excited that this topic is gaining attention from Luke and Fellippe. That gives me hope that it could lead to further USB (or even Bluetooth) implementation in QB64's future builds.
-
@doppler
I've made more progress with the HID API but don't have the stuff here to show you. I'm at work and don't have the files. If you were on the Discord you would be able to see some videos I posted last night that showed me decoding packets from the Nintendo Switch Pro Controller using only the HID library. I'm still working on the analog sticks, though. Oh, and it was all through Bluetooth connection to my PC.
-
@doppler
To definitively answer your question.... It is very possible to input/output to a USB HID device from QB64. However, I used Bluetooth. Same concept, just different packets. I figure you probably don't have the controller to test this with but if you look at the code it should at least give you some insight as to what is going on. The code is made with InForm and then merged so it's quite large. Scroll down towards the bottom section for the code I wrote. Below is also a video showing me using the test program I created using the hidapi library.
My source code ---> [ This attachment cannot be displayed inline in 'Print Page' view ]
-
This is an interesting discussion, I am trying to get QB64 to read separate input from 2 or more USB mice plugged into the PC:
- reading multiple mice input with _DEVICES and _DEVICE$, or RawInput ?
https://www.qb64.org/forum/index.php?topic=3348.0 (https://www.qb64.org/forum/index.php?topic=3348.0)
To do that would I need to get into device drivers and lower level stuff, or is that just because you're talking about specialized hardware like game controllers? I'm just interested in your standard wired USB optical wheel mouse.