Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I'm using C++ and libusb-win32 to try and communicate with a commercial USB device ... I don't know much about USB programming, but I want to send some commands to the device that I know from using a sniffer program. Libusb-win32 seemed OK, but it looks like it can only be used on a device that uses the libusb driver for the device.
I want to use it on a device with a driver "USB Composite Device" driver provided by windows usbccgp.sys ... is it even possible? If not, how can I do this?
I just need to send some Control Transfers
This is currently not possible. libusb is designed around the Linux driver model where composite devices are treated as a single device by the system. Windows treats composite devices as multiple separate ones - a parent composite device and child devices for each interface.
As such libusb cannot access the child devices without first changing the parent driver to a libusb supported one. It can be done but then the device won't work with the vendor supplied software.
If you want to talk to a commercial device you need to contact the manufacturer and find out if there is an interface to that device that is published through their driver. Most manufacturers won't have a way to interface with generic control requests in a product. There may be an undocumented IOCTL, but again you'll need to work with them to get this information.
If you just want to hook the device and send it a control request then you need to replace the manufacturer's driver with the libusb driver. The problem here is that while you can get at the device it may not function the way you want unless you spoof what the manufacturer does (for example, the device might expect some vendor specific communication to get the device ready to interact with the host). If you do see problems then you can reverse engineer the vendor specific protocol by looking at the USB line through some hardware analyzer.
Read USB Complete, it's a great introduction to the USB protocol and will help you understand more of what's going on between a USB device and your host PC.
Related
I am looking for a piece of software, or assistance with where to start for coding, that will let you select a USB device and convert its output signals (when buttons are pressed on the device) into keystrokes or configurable macros.
In more detail, I have this remote control (more accurately, a USB handset/phone) that sends USB signals depending on which button is pressed and the software I currently use converts those signals into keystrokes or macros. The software I currently use however is extremely limited, non-configurable and obsolete. The software which I retrieved from the CD that the device came in is simply named 'USBPhone 5 in 1' however there is no mention of this anywhere on the internet.
The device is unfortunately unbranded and also has very little visibility on the internet so I cannot see if there's any updated software or even any way to edit it.
Any help is greatly appreciated!
I think you need to start by getting basic understanding of the USB standard and device classes. Then you need to find out if your device implements a specific device class or some proprietary interfaces. Then you will either need to use a driver for the device class or implement a proprietary driver.
While USB is abbreviation from Universal Serial Bus, it is not transferring some random analogue data but well defined digital packets. The standard defines Audio Class for audio devices, Video class for video devices etc. Most devices implement one or more of those classes. For keyboards and mouse it defines HID class, which is most likely what your device implements. You can find HID device class related specifications here. It is not the most simple one to begin with, but it should work when you just plug the device to your PC and open e.g. notepad and start writing. USB device class codes are listed here.
In order to find out what device class your device implements, you need to read it's descriptors. In Windows one of the easier ways is to use usbview. You can read more about USB decriptors from here.
You do not mention what is your USB host (Windows or Linux PC, Mac or something else), so I am not going to go into actual USB driver implementation, but hopefully I was able to give you some information on what could be needed. In any case, if the device has some proprietary implementation, you will either need to have specification for it, or reverse engineer it by monitoring the USB packets. There are lots of expensive hardware solutions on the market for analyzing the USB traffic, but there are also some free SW solutions that might be good enough for your purpose. Quick Googling brought up this.
You can try joyToKey, this software do exactly what you want but with gamedpad. I don't know if it will work well with your USB controller.
http://joytokey.net/en/
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
How do I to get the full control of a remote computer which I know his open port number and his IP address using C++ ?
I know that I need to establish a socket connection between these two computers which I've already done. But, how to get the remote computer's screen image dynamically which gives me a live watch of what is happening?
I'm just looking for what do I need to know to deal this.
PS: I'm trying to implement this solution, I know that there is many softwares whom deal this.
OS: Windows 7 SP1.
If you want to just see the remote computer's screen, you can take screen captures by instructions from Here or Here.
Next you should send data of bitmap pointing by a pointer like ULONG *pBitmap over network. You can put a header before each frame data and a footer after that. In the receiving side you can detect each frame packet by headers and footers ensuring that each frame data is received completely.
After receiving a frame you should display it by whatever GUI framework you are using.
This is quite complex. Things like "Remote Desktop" will implement a virtual screen driver, virtual keyboard driver and virtual mouse driver. The virtual driver then does the packaging of what is going on (when enabled) and sends the data to the local computer, which has code to redraw the remote machine's graphics. The local machine on the other hand (assuming you want to control the remote machine) will send keypresses and mouse movement to the remote machine to allow control. These will be picked up by the remote machine's virtual keyboard and mouse drivers and entered into the system as if they were "real" keyboard and mouse movements.
You could do a very simple version by simply doing a screengrab and sending the data from that to your local machine over the network. You may want to do some sort of "compare this image with the before one, only send what changed" to avoid too much data across the network.
One of many answers about screen shots here on SO:
How can I take a screenshot and save it as JPEG on Windows?
And there are interfaces to send keyboard and mouse events to the system, such as what is described here:
http://msdn.microsoft.com/en-us/library/ms171548%28v=vs.110%29.aspx
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 1 year ago.
Improve this question
Our requirement is to develop remote sound system which should support all the windows OS starting from WindowsXP Onwards .
It is something like http://www.elusiva.com/products/RemoteSound/
I would like to describe the functionalites more clearly here...
Microsoft has 3 different options over RDP using virtual chanel
Play on this computer
Don't play
Play in Remote System
For that microft is using RdpendP.dll and virtual chanel to control over that three diff. options..
Our case is just reverse of Microsoft when one user is selecting Play in Remote System option that should be played at local system not in remote system.. using our own virtual chanel which we have registered. Secondly when the user is selecting Play on this computer option that should be played on remote system not in local system with low latency...
Our approach:
We just created one virtual client dll and registered at (HCURRENT_USER/Software/Microsoft/Terminal Server Client/Default/Addin).Now we able to make a virtual chanel with terminal server.
Problems:
First problem is how to redirect the sound from Terminal server to client(So that when one media player is playing at terminal server it should be played at client system).We tried with WASAPIS to capture sound from terminal server endpoint device speaker and using WTSVirtualWrite to write audio data to virtual chanel and then at the client side we use to render it by using getbuffer method to write client endpoint device , but I think it is very bad approach and huge latency is coming.
So what we think here instead of capturing and rendering if we redirect the sound which is playing in terminal server side to client audio device that would be the better approach but how to do these implementaions using virtual channel and terminal server APIs or any other Windows APIs..
What are the registry changes should be done for that…
Second problem is how to add a dummy speaker icon to volume Mixture device speaker(One combo box will come at device speaker , here we would have two diff. speaker icon with their property, one is HDRealtalk as supported and second one is our speaker with a speaker property general only)
Note : Here Instead of writing virtual Audio driver or our own audiodrv, how to achieve that.
Third problem is how to support our own codec(like verbois)...
(Here we created one .acm file but how to support it, We have gone through diff. ACM functionalities like ACMDriverAdd, ACMDrvClose, ACMOpen but we don't have idea to implement that)...
Fourth Problem is how to capture and render from microphone to client system(Like to capture from terminal server microphone to local capturing device and also playback there)...
Our requirement is like it should supported by all windows OS starting from Window XP onwards..
You could always use icecast for this. Just need some scripting and edcast and you should be sweet.
Other options include Mumble.
Im trying to get the output from a Wii Fit (balance board). I can find the device via the C++ Bluetooth enumerators but attempts to connect via a windows socket are failing.
Im wondering if anyone has had success in such a direction (C++, windows) I'd love to hear how you did it.
The Wii Balance Board is a HID device. To understand communications with the Balance Board, you need to know a little bit about Bluetooth HID. There's good information on WiiBrew about the Wiimote and the Wii Balance Board.
I don't think you can use Windows Sockets to connect to a HID device. The Windows Socket Bluetooth interface only allows you to connect to RFCOMM-based services. HID is based on L2CAP which is further down the Bluetooth protocol stack. There's some information at MSDN about that limitation.
If you're just looking to hack around with it, you can try Bluecove for Java. You may be able to do something using another stack (for example, Widcomm). If you're locked in to Windows and C++, you may have to look into writing an custom HID driver for the Balance Board.
As pwc said there is a limitation in the MS Bluetooth API, so with sockets you cannot have something else except RFCOMM, but this doesn't mean you cannot go down at L2CAP layer. What you have to do is to implement a client profile driver and you can use as starting point an article from MSDN: Creating a L2CAP Client Connection to a Remote Device and vice-versa: Accepting L2CAP Connections in a Bluetooth Profile Driver
Next of course as pwc said you have to study Bluetooth HID and WiiBrew for the communication protocol.
Also a good document to read is Bluetooth Wireless Technology FAQ - 2010 which states clear that it is possible to have L2CAP connections with Microsoft Bluetooth stack driver. Of course not with sockets.
When using HID on a Bluetooth device there is generally no need to create a L2CAP connection directly. All(???) of the Bluetooth stacks on Win32 have support for Bluetooth HID and provide access to the HID stream/control through the native Windows HID API. No (direct) L2CAP required! :-)
On WinCE there is built-in support for Bluetooth HID also, but I'm not sure there's a way to access a HID API.
That's how Brian Peek's wiimore library works -- it uses the HID API. The good thing about that is that one gets supports for all(?) the Bluetooth stacks that way -- they each support HID devices via the Windows HID API, whereas to use L2CAP directly one would have to support each of the stacks' APIs... (That's if they have one! BlueSoleil has no L2CAP API as far as I can see).
So, on Win32 one should just pair with the device and check that the HID checkbox is checked on its Bluetooth Service control panel tab (whichever Bluetooth stack is in use). In my 32feet.NET library one can discover the device and then ensure that HID is enabled for it with:
BluetoothDeviceInfo[] list = btCli.DiscoveryDevices();
var deviceInfo = list[n]; // Select the correct device
deviceInfo.SetServiceState(BluetoothService.HumanInterfaceDevice, true);
(That should work on MSFT and BlueSoleil; there's no API for that on Widcomm AFAIK -- although when paired it might be automatically enabled anyway).
The one possible exception case is that apparently some devices are not fully compliant with the Bluetooth/HID specs, I'm told the PS3 blu-ray controller is like that. Then one might want to try L2CAP connections directly -- however its likely that the stack's support for HID will interfere with third-party applications trying to provide the same service...
I'm developing a device and writing the software for it under Windows (MFC with Visual Studio).
I would like to start a measurement with a remote. It would be nice if it worked over Bluetooth, but I don't have a clue where to start.
What book can recommended or is there a site where such things are described?
Is it even possible to make my own Bluetooth device or do I have to pay some fee for licences?
What I would like to have, is a Bluetooth-remote with one button, which sends a signal to a Windows PC where a program then starts specific subroutines.
As Dan wrote in the comment when it comes to Microsoft the best place to start is with MSDN. For me his link didn't work, but I guess he wanted to point here.
MFC does not offer you support for Bluetooth, instead you have to work with a Bluetooth driver stack API. On Windows there are more stacks, but most widely used are: Microsoft Bluetooth driver stack and Widcomm/Broadcom. If you decide to use the Microsoft Bluetooth driver stack you might want to look on this thread. The stack that you choose it depends on the Bluetooth dongle attached/incorporated at your PC.
Is it even possible to make my own Bluetooth device or do I have to pay some fee for licences?
Yes, it is possible to make your own Bluetooth device. The fee depends from case to case, first if you want to be assigned your own IDs from SIG you have to pay them a fee, otherwise you can use the ones already bought by the chip manufacturer. Also if you want to re-write the firmware from the chip you could be forced to buy a software from the chip manufacturer. Usually it's enough with their firmware.
What I would like to have, is a Bluetooth-remote with one button, which sends a signal to a Windows PC where a Software then starts specific subroutines.
Well, it seems you will have to take care of the device discovery aspect and second make the pairing. After this you could use Serial Port Profile to communicate with your device like any other RS-232 enabled device. If your device is dedicated you might want to modify the IAC - Inquiry Access Code so in discovery phase only you that you know the code, can see the device.