I'm trying to implement an AVRCP/A2DP connection between my Android phone and my car PC. The A2DP bit basically works out of the box so no issue there. I want the PC to be the AVRCP CT (controller) and the A2DP sink. The phone is the AVRCP TG (target) and the A2DP source.
Where I'm having trouble is getting any sort of AVRCP connection that I can use. Windows 7 comes with a toolbar application that at least provides the basic play/pause/skip/stop type functions. So it definitely works with the software I have without any extra drivers or otherwise. However my searching has produced little results on any way to do this or documentation on creating an L2CAP connection which I believe I need.
The 32feet.NET libraries don't support L2CAP connections unless you use a Broadcom/Widcomm stack. Buying a new BT USB device may be a viable solution but at the moment I'm trying to do this all in software :). i.e. like this although there a problems noted there that weren't solve (or reported as solved)
link: How can I establish an AVRCP connection from Windows 7 (controller) to phone (target) using L2CAP on Widcomm SDK?
I'd prefer to do it C# if possible but if I had some kind of library to interface with my code, that would be fine (like the 32feet.NET library which works quite well for the things it does work on.)
This is about the closest I've got but is all a bit Greek to me and not quite enough to get me started (I'm an embedded guy):
http://msdn.microsoft.com/en-us/library/windows/hardware/ff536674(v=vs.85).aspx
Is Bluetooth really such a mess on Windows that it seems to be from my searching? There are multiple different stacks that all seem to be significantly different in terms of the API etc.
Can anyone point me in the right direction? I've done a lot of searching/reading other posts here and elsewhere and not really made any progress.
Thanks
Christian
Related
How would I go about creating a "gamepad" which appears to DirectInput applications as a normal game controller but the state of its controls is actually defined by software?
Write a device driver to pretend to be one.
Specifically, Windows device drivers handle what are called Interrupt Requests via the Interrupt Request Protocol - which boils down to a wrapped up structure and a set of buffers internally in the driver.
Now the next thing you need to know is that many drivers are actually layered, or stacked, or whichever name you want to use. So for example to write a disk driver, you might interface with the driver above it (as a disk class) but use a driver below it (scsi port, for example) to actually send commands to your devices.
That's how real devices work. Fake devices need to conform to the top level interface requirements, e.g. a disk, or a controller, or a mouse, or whatever it is. However, underneath they can do anything they like - return whatever values they like.
This opens up the possibility of controlling a driver via a user-mode application and pretending to "be" a device. To send a driver messages, you can DeviceIoControl to it; then to actually get those messages you can either:
Stuff them in the Irp that makes up that DeviceIoControl.
Have the driver read them out of your process' memory space.
Drivers can also access \\Registry\\Machine and various other, non-user-specific non-explorer registry areas, so it is possible to communicate that way.
Finally, there's no saying you can't filter existing IO, rather than make it all up via a new device. There are a great many options and ways you can go about doing this.
If you're going to do this, you'll need:
VirtualKD or an expensive debugger cable and two PCs.
You probably also want to start with the references on this blog post. You'll find that there are essentially a bazillion different names for driver code, so I'll interpret some of them:
WDM = Windows Driver Model, basically the NT driver model mixed with (some of) Windows 9x.
KMDF = Kernel mode driver framework - drivers of the above type use this, plus additionally WDF (Windows Driver Foundation) which is a set of libraries on top of WDM to make it quicker to use.
UMDF = User mode driver framework - write a driver without the danger of kernel mode. If you can, use this, as kernel mode drivers that go wrong will bluescreen (in driver parlance, bugcheck) your system.
Edit: I'm not massively knowledgeable on DirectInput - there may be a way to override the various API controls in use via DLL redirection and the like, which may be simpler than the way I've described.
There is vJoy opensource project: http://sourceforge.net/projects/vjoystick/ - can be worth looking at.
The easiest solution may be to emulate an XInput device (Xbox 360 and One). These are supported in most modern games and the set up is very simple. Here is a C++ project here that provides this without any installed drivers or external dependencies: https://github.com/shauleiz/vXboxInterface/
I know it is an old question but for anyone which is interested in this topic it is also worth looking at this project called ViGEm.
You can emulate some well known gamepads like Microsoft Xbox 360 Controller, Sony DualShock 4 Controller and Microsoft Xbox One Controller. The project offers also some API to interact with these virtual controllers. E.g. the C# API can be found here
The simplest solution I found was using vJoy and its C# wrapper.
You need to download the vJoy driver from here.
You can use the vJoy SDK for implementing a feeder program: https://github.com/njz3/vJoy/tree/master/SDK/c%23
Use the C# starter project for this, or simply add the two .dll-s to your existing project as references from the x86 or x64 folder.
You can find instructions on how to use the api in the readme.odt file.
I'm working with various (mostly Bluetooth) development boards (ConnectBlue, Ubertooth, USRPs etc.) in order to research about Bluetooth communication behaviour at PHY level. In order to get some more insights I'm looking for a way to debug the Bluetooth stack on a Windows 7 Desktop computer. My use-case is relatively simple: I have custom baseband implementations, which establish connections with the Windows computer. I'd like to see everything the Bluetooth hardware/driver does.
I'm not sure how to approach this: I'd like to see when the Bluetooth Chip/Windows driver receives a Signal, and how it (the message) gets interpreted/formatted/passed through the various APIs concerned. Mostly this relates to kernel debugging.
Is there a way to display the state of the attached hardware in Windows in WinDBG? Maybe to perform (Kernel) API logging on the Bluetooth kernel service?
I hope somebody more familiar with device driver debugging and Windows Kernel services can give me some pointers here.
Since you don't appear to have gotten any hits on this, I'll post what I can.
I don't have any definite answers, but on the NTDebugging blog they often do hardware level debugging in windbg.
I.e.
http://blogs.msdn.com/b/ntdebugging/archive/2007/06/22/where-the-rubber-meets-the-road-or-in-this-case-the-hardware-meets-the-probe.aspx
To be honest this is going to require extensive knowledge not only of your hardware, but also of the deep internals of windows, and how the bluetooth stack is written, but the WDK would probably be a good place to start for understanding the bluetooth stack. I would also check out the blog for tips and tricks.
The other place to check and ask questions is http://osronline.com/ It's one of the better communities about device drivers, so they should have some reasonable tips on doing what you're trying to do.
I want to write something like DaemonTools: a software that presents itself to the system as a real device (a DVD-ROM in the previous example) but it reads the data from a file instead. My requirement is not limited to DVD-ROM. The first goal is a joystick/gamepad for Windows.
I'm a web developer, so I don't know from where I could start such a project. I believe it will have to be written in C/C++, but other than that, I have no clue where to start.
Did anyone tried something like this and can give me some starting tips ?
Most drivers are written in either C or C++, so if you don't know those languages reasonably well, you'll want to get familiar with them before you start. Windows programming uses a lot of interesting shortcuts that might be confusing to a beginner - for example PVOIDs (typedef void* PVOID) and LPVOIDs (typedef void* far LPVOD;). You'll need to be happy with pointers as concepts as well as structures because you'll be using a lot of them. I'd suggest writing a really straightforward win32 app as an exercise in getting to grips with the Windows style of doing C/C++.
Your next port of call then is to navigate the Windows Driver Kit - specifically, you'll need it to build drivers for Windows. At this stage my ability to advise really depends on what you're doing and the hardware you have available etc, or whether or not you're really using hardware. You'll need to know how to drive your hardware and from there you'll need to choose an appropriate way of writing a driver - there are several different types of driver depending on what you need to achieve and it might be you can plug into one of these.
The windows driver kit contains quite a large number of samples, including a driver that implements a virtual toaster. These should provide you with starting points.
I strongly suggest you do the testing of this in a virtual machine. If your driver successfully builds, but causes a runtime error, the result could well crash windows entirely if you're in kernel-mode. You will therefore save yourself some pain by being able to revert the virtual machine if you damage it, as well as not having to wait on your system restarting. It'll also make debugging easier as virtual serial cables can be used.
This is quite a big undertaking, so before you start, I'd research Windows development more thoroughly - check you can't do it using the Windows APIs first, then have a look at the user-mode driver framework, then finally and only if you need to, look at the kernel level stuff.
I need to scan Wifi access point on Windows Mobile and connect the one of scanned results.
Currently I am using C# language, Windows Mobile 6.5 device, also to scan I am using the below code.
[DllImport(wlanapi.dll", SetLastError=true)]
I am using wlanapi.dll, but it seems that not possible to use on Mobile.
Does anyone know about the belows.
Could I use the dll in Windows Mobile 6.5 to scan and connect?
If the 1 is not possible, please let me know the different methods..
Please give me the clues.
wlanapi.dll doesn't exist in WinMo/WinCE. You have to use an API that is supported.
Most WinMo WiFi drivers (though probably not all) support the Wireless Zero Config (WZC) set of APIs. The native versions of these APIs, like WZCQueryInterface, are outlined in MSDN.
Microsoft does not provide any managed interface for these APIs, in fact the native documentation for them is pretty bad too. The definitive "example" of it's use is in the NETUI component source of Platform Builder. Gettign the eval version just for the source is very worthwhile if you plan to do much WinCE/WinMo development.
From a managed perspective I wrote an MSDN article back in '06 that talks about using the SDF for getting network info. The SDF has been reworked a lot since then, especially in the WZC area, but it's still pretty similar.
I did an updated blog post in '07 about custom-drawn ListBoxes, and while that's not what you're after, the data being displayed is wireless network info, which is in line with what you're after.
I'm looking at developing a device which will need to support Ethernet over USB (hosted in Linux, XP, and Vista). As I understand it, Vista and Linux support the industry standard USB CDC. However, in classic Windows style, XP only supports it's own Remote NDIS. So, now I'm thinking of just bowing down and doing it over RNDIS, as opposed to rolling my own CDC driver for XP.
I've been reading some older documentation that says even XP is pretty buggy with NDIS (suprise!). Does anyone have experience with XP's RNDIS drivers? Are they safe for product development? Any insight would be much appreciated.
We use RNDIS at work. and I've found that it blue screens my machine every now and again (about every month or two). However others (at my work) have not had this happen, so it could just be the particular device that I use.
I think it is stable enough for development, so give it a go.
The problem here is that Linux does not support RNDIS in the host mode, and you can't develop custom driver due to MS RNDIS license restrictions. MAC does not support RNDIS as well due to same reason (licensing).
So if you need multiplatform solution you need a standard approach which is CDC/ECM.
There is number of available CDC/ECM XP/VIsta solutions in the market,you can google for them i don't want to advertise our solution here :)
After doing my own research and testing, a single NDIS device works reasonably well. However, if you are at all needing to support multiple NDIS devices, you are out of luck. My system became extremely unstable and was essentially unusable. This was very reproducible.
I would not recommend NDIS in any type of multiple-device scenario.
if you are looking for commercial solution, Jungo does provide decent ECM solutions works for Windows/Linux/Mac. The only problem is that you have to pay them non-trivial royalty fee if you are going for a mass volume product.