I am new to the Apple DriverKit SDK an i am not clear about how register my device driver so it would be available as a Camera in the OS. Do i have to register a streaming function in the Start function of the IOService? I searched all over the internet for an answer but i could not find on.
I need to read data from a custom USB Camera and then make it available via a custom driver.
Can any of you guys help me?
Support for cameras and video capture devices is not implemented as special I/O Kit classes in macOS (and therefore also not in DriverKit), but rather entirely in user space, via the Core Media I/O framework. Depending on the type of device a DriverKit component may be necessary. (e.g. PCI/Thunderbolt, which is not available directly from userspace, or USB devices where the camera functionality is not cleanly isolated to a USB interface descriptor) This dext would expose an entirely custom API that in turn can then be used from the user space CoreMediaIO based driver.
From macOS 13 (Ventura) onwards, the Core Media I/O extensions API should be used to implement a driver as this will run in its own standalone process and can be used from all apps using Core Media.
Prior to that (macOS 12 and earlier), only a so-called Device Abstraction Layer (DAL) plug-in API existed, which involved writing a dynamic library in a bundle, which would be loaded on-demand by any application wishing to use the device in question. Unfortunately, this raised code signing issues: applications built with the hardened runtime and library-validation flags can only load libraries signed by Apple or by the same team as signed the application itself. This means such apps can't load third party camera drivers. Examples of such apps are all of Apple's own, including FaceTime.
I want to write a Windows application which accesses the joystick. It is just a very simple application which reads the values and sends them to a server, so I am not using any game programming framework. However, I am confused about which API to use.
I looked at the Multimedia Joystick API, but this is described as superseded by DirectInput. So I looked at DirectInput, but this is also deprecated in favour of XInput.
However the XInput documentation talks only about Xbox360 controllers, and says it does not support "legacy DirectInput devices".
Have Microsoft consigned the entire HID Joystick usage type to the dustbin and given up on supporting them in favour of their own proprietary controller products, or am I missing something?
The most common solution is to use a combination of XInput and DirectInput so your application can properly access both type of devices. Microsoft even provides instructions on how to do this.
Please note that DirectInput is not available for Windows Store apps so if you intend to distribute through there, that's not an option.
XInput devices like the XBox 360 controller will also work with DirectInput but with some limitations. Notably, the left and right trigger will be mapped to the same axis instead of being independents, and vibration effects will not be available.
Can I use Serial Port Profile (SPP) to communicate with iOS devices over Bluetooth Low Energy (v4.0) without the need for MFi Chip?
If you're designing something from scratch (rather than trying to interface to an existing SPP-enabled device), there is a possible solution.
Laird Technologies make a Bluetooth Low Energy Module (BL600), which can be loaded with a virtual serial port application. This creates a service which is similar to the SPP; at the remote end it can just be treated as a plain serial port (albeit rather low speed). You could roll your own service to do something similar on other devices.
It's not the most elegant solution, but seems to work okay, and far easier than trying to get MFi certification.
If you cannot control the peripheral's protocol choice:
The Serial Port Profile (SPP) is still supported by Bluetooth 4.0. However, Bluetooth 4.0 Low Energy uses different pysical and link layer protocols that are not backwards compatible with older Bluetooth standards. Current iOS and Android devices use "dual mode" interfaces that support the backward compatible part of BT 4.0 and the Low Energy standard.
Bluetooth 4.0 Low Energy does not support SPP whereas regular Bluetooth 4.0 does!
I found a Cordova/Phonegap Plugin on GitHub that might serve as a source of inspiration for you. They advertise to support SPP on iOS and Android alike.
If you are in control of the peripheral, i.e. you implement the peripheral's software:
Bluetooth 4.0 Low Energy communication makes use of the Generic ATTribute Protocol. Based on GATT there exist a number of profiles but no serial port profile.
The good news is that implementing your own proprietary serial port profile on iOS, Android and your device is fairly simple. The API instructions for your BTLE module/SoC should provide some examples for existing profiles.
As soon as you see how simple implementing your own profile is, you will probably choose to go for a more use case specific profile which will save you lots of power on your (battery powered?) peripheral.
Just to clear up John Parsons comment from Feb 16th - the BL600 is definitely not discontinued whatsoever.
vSP works well for a low level, low throughput data connectivity using BLE for iOS devices, as well as Android. Video showing the solution working to an iPad are at this link and full source code is available for the iOS application as well http://www.lairdtech.com/Support-Center/Technical-Library/Videos/VSP-Bridge-Command/#.UwYvzGJ_s1w
There are no MFi requirements for BLE connectivity on iOS.
MFi is only relevant to Classic Bluetooth data connections to / from iOS devices, where you need to use Apple's iAP protocol, be a MFi licensee, use an external Apple Authentication IC and pay a royalty to Apple.
NO,you can't. BLE not support SPP.
No, you can't. In general, it's important to remember that any Bluetooth Classic profile isn't necessarily applicable for Bluetooth Low Energy. With BLE however, you can easily create your own custom service/profile, specially tailored towards your particular application. As far as I know, all BLE communication with iOS is currently allowed without participating in the MFi. You can also take a look at this page for further information on SPP and BLE.
I'm searching for SPP for iOS myself and found a German supplier, lintech.de, that has products for "Bluetooth meets Apple" claiming to support/emulate SSP, apparently using their own embedded software layer combined with iAP. "BlueMFI software communicate with APPLE devices using the iAP (iPod Accessory Protocol) and manage the data communication with the Apple authentication chip...BlueMFI software is designed to run on a variety of hardware platforms (Bluetooth modules), and interested users can obtain the relevant evaluation kits. LinTech’s Bluetooth modules with BlueMFI software not only support the APPLE iAP protocol via Bluetooth, but they are also able to communicate with standard Bluetooth devices." Haven't tried this yet, just exploring and sharing.
I won't say SPP is directly supported under iOS 7, Apple says no. Won't argue :)
But...
I use connectblue modules OBS421 and OBS425 on a data collection project.
BLE modules have SPP profile enabled and I transmit data from my sensors to the iOS devices using BTLE module in SPP mode.
Works pretty fine under iOS 6 and 7
That said, I was having trouble with MFi bluetooth devices under iPhone 5S, that's why I moved to BTLE.
Drawback with BTLE, it's limited to 20 bytes at a time.
I had to adjust hardware and software, but was easy.
You have programmable chips such as Bluegiga BL112 that are doing the job. It is the cable replacement code.
I'm integrating it actually for both iOS and Android 4.3. It works at least on the demo board.
I have an application that uses WIA 2.0 however the scanners that we have in the office are not compatible with WIA.
Is there any dummy driver such as the TWAIN Dummy driver (twainkit.exe) for WIA that we can actually test with like a fake image? Note this has to support Win 7 64-bit.
There's also WIAonTwain, http://sourceforge.net/projects/wia-on-twain/
From the description in sourceforge, "A WIA on TWAIN driver implementation designed to expose all necessary scanner functionality while adhering to the WIA 1.0 and WIA 2.0 specification and achieving compatibility with all WIA compliant applications." Also, it is made by the TWAIN working group.
We have a Windows Forms app running on XP that uses WIA to retrieve images from digital cameras attached to our company's field technician laptops. As clunky as the COM wrappers and APIs are, they've handled millions of images reliably. Looking now at inevitable migration to Win 7 and wondering if we should move from WIA to WPD (Windows Portable Devices) API.
Does anyone have experience migrating from WIA to WPD? Or just working with WPD? Any pros or cons of staying WIA or going to WPD? Thanks in advance!