I am getting started with coding for HID devices. I got started with reading Apple documents and sample code. The code provided are terribly outdated that it doesn't even open in Xcode8.
Download Sample Code from Apple
I need help in finding a sample project / snippet for getting started with HID Services! Open a handle, read and write reports to device, Listen to reports generated by device in a run loop.
OS X/macOS's HID stack is called IOHIDFamily, and much of it is open source. This includes kernel and userspace components. You can find the code for various different OS X/macOS releases at
https://opensource.apple.com/
For 10.12.2 (latest code released at time of writing) you can browse the IOHIDFamily code here:
https://opensource.apple.com/source/IOHIDFamily/IOHIDFamily-870.31.1/
or download it as a zip file here:
https://opensource.apple.com/tarballs/IOHIDFamily/IOHIDFamily-870.31.1.tar.gz
The "tools" directory contains some userspace sample/test code which might help with what you're trying to do.
As for sample code not being updated, documentation being incomplete/outdated/missing, and provided code requiring a lot of effort to build: welcome to Mac systems & driver development. That's unfortunately how it is. I've been doing OS X kernel/driver work for 7 years, and while some things get easier with experience, downloading code from Apple and building it still feels like playing the lottery.
Related
Got this Digital Keychain Photo viewer thingy. Comes with DPFMate which does not run under Windows 10. Does anyone know where DPFMate places the images on the keychain, so I could possibly write my own program to do the move?
i know this thread dates back to April but i have a device that uses DPFmate and it was packaged with it in memory. the software came with a windows and a mac version. fortunately most of the code is literally available in an uncompiled form in the mac app package. i have included everything from that package in a mediafire link. https://www.mediafire.com/file/ebyxepk013k18pd/Resources.rar
from what i gathered it loads a virtual drive from the machine using a SCSI connection driver of some sorts. i hope you can make sens of it more than me since i am not familiar with the programming language used.
I'm trying to update a simple sequencer I wrote a few years ago in XCode 3. I hit a brick wall at the very outset because AudioComponentCount and AudioComponentFindNext do not find my software instruments.
They just find two: Apple's DLS music device and their sampler.
I have several others which I can see in the library Components file. Auval sees them too, and passes them OK. They also work fine with my old sequencer, where they are found OK by the same functions. And I have checked that the components are up to date.
I do have the AudioUnits framework linked in (and the program compiles OK, it just doesn't do the right thing). Trying CountComponents with the CoreServices famework gives the same problem.
All the Apple documentation and sample code I have found indicates that my code should work.
Can someone suggest why these functions should be blind to perfectly good synths?
(I am compiling using XCode 4.3.3 on a Mac Quad-core Intel Xeon running Mac OS X 10.7.5. Could it be incompatibility between the up-to-date XCode and the Lion OS??)
The OSX command line tool nettop (I think it was added with Lion) can display per app network throughput without requiring root privileges. I browsed through the Darwin source code on http://www.opensource.apple.com/ but couldn't find it's source code. Is it open source at all or did I just missed it. Incase the source is not publicly available, does anyone have an idea via which api nettop is getting its data?
nettop is open source only in its BSD version, but Apple's version uses their private NetworkStatistics framework (new in Lion) so I doubt you will find the sources since Apple tends to not release private code.
I'm currently working on a project where we want to interface with TWAIN scanners on both the PC (Windows) and the Macintosh.
On Windows, we basically have everything squared away and the code works successfully with the vast majority of scanners.
On Mac OS X, we also basically have everything working and with the main scanner we used to develop the application with works perfectly, but we're not having a ton of luck with other scanners. As a byproduct of development on this project, we have a fair number of scanners from various manufacturers on-hand to test with. The results vary wildly:
The scanner we used to develop with works perfectly on Mac OS X as it does in Windows. Ironically this scanner is the cheapest and crappiest scanner (speed-wise) we've ever encountered but it's been a dream to work with.
Another scanner works great - until the second or third scan, at which point the application crashes with no clear indication of what happened (we get an EXEC_BAD_ACCESS from the debugger)
Another scanner apparently has no TWAIN support on Mac OS X (no data sources in the "Image Capture/TWAIN Data Sources" folder), although it does have TWAIN support in Windows.
Another scanner has a generic data source that I'm thinking is supposed to cover all the possible scanners from this manufacturer but when we try to initiate a native scan (which is a requirement for all TWAIN data sources) we get no results. Also, trying to install a second scanner from this manufacturer gums everything up and requires a manual uninstall for everything from this company.
Another scanner has a TWAIN data source that appears to be specific to the manufacturer, but it also fails to initiate a native scan (but a scan using the native GUI - which is incompatible with our project - works)
So I'm not sure where to go with this. I'm still digging into the code to figure out what, if anything, we're doing wrong but in checking against the TWAIN standard it really does look like we're doing everything right, but we're getting very hit-or-miss results on most of the scanners we're testing against.
Also, as part of the new Cocoa/Carbon Events model there's this additional consideration of a "callback" function that Mac OS X TWAIN data sources are supposed to implement and I'm not seeing it called from most of these data source/drivers.
So all of this leads me to wonder - is it that we're just doing something wrong or is TWAIN just not supported properly by and large on the Macintosh?
I'm really not seeing a lot of information on TWAIN on the Macintosh online - the occasional sporadic inquiry on twainforum.org tends to go unanswered. Windows also has a thing called WIA - Windows Image Acquisition - and on the Windows side we also include this as an option. Is there something else on the Mac we should be exploring instead of or in addition to TWAIN?
You can try ImageCaptureCore.framework. But you have to verify that the company/model scanners to which you are giving solution have ImageCapture support.
If any vendor has given support then a ImageCapture module will be present in location '/Library/Image Capture/Devices'. You can also check the plists inside modules for supported models.
Hope it helps :-)
I recently started creating applications for mobile devices and have successfully completed an application for the iPhone. I am now turning my attention to the Blackberry but haven't been able to find a convincing article or website that states that it can be done or a tutorial on how to do so. Can Blackberry apps be developed on Mac OS X? If yes, how do I go about doing so? Can anyone please point me in the right direction as I only have access to a Mac and really want to get this project on the road. Thanks in advance for your help.
UPDATE:
RIM has released a MacOS Eclipse plug-in for Blackberry Development: http://na.blackberry.com/eng/developers/javaappdev/macosx.jsp
While there is no built-in simulator, the plug-in DOES support USB tethered device debugging for the Torch 9800 handhelds. I plan to get one; they are ~$499 w/no contract. With a Torch and the new plug-in, Blackberry development is possible without using a VM. (Finally!)
PREVIOUS POST:
Building on MacOS works well once you set it up. I've had less luck with the simulator. On the whole though, being able to run Eclipse natively in MacOS and flip to a Windows VM only for debugging is a big win in my book.
You can get a MacOS version of preverify (see link below for details). I do my development with Eclipse on MacOS X and use Ant to build BB apps.
This blog is excellent and has many of the details to get you started:
http://www.azizuysal.com/2009/07/blackberry-development-on-mac-os-x.html (original link is dead. The "wayback machine" provides us with the original text content, but images and styling are lost to the sands of time. Still worth a read.)
The tricky part is getting the simulator to work. There is a Wine-based work-around, but on my computer, while the simulator was able to run under Wine, the LCD output was scrambled.
Currently, I build COD files from Mac, and my Ant build process drops them into a directory that is shared with a WinXP VM. I can run the simulator stand-alone in this VM. Debugging is also possible by installing Eclipse inside WinXP and pointing the debug configuration it at the source directories.
I've actually got a bit more magic. I enabled some of the Java 1.5 features by compiling against 1.5 and then translating the bytecode to 1.3 prior to the preverify script. (Blackberry only speaks a barbaric 1.3 java, flashback to circa 1992). It's not a silver bullet as some features still don't work, but it does cut down on the need to make everything an untyped Object reference.
Lately, I've been working on a x-platform framework to allow me to write app code once and build against both Android and Blackberry (both are Java). The Android part was easy. It's just a bitch to debug anything in Blackberry. Someone working at RIM decided that Blackberry didn't need to keep Exception stack traces unless there was a catch(Throwable), and then they could do something bizarre, non-standard, and undocumented (catching Throwable behaves weird). I've only kinda-sorta figured out a hack to get stack traces using JavaLoader.exe without breaking into the debugger, and it's barely worth it.
p.s., I now do x-platform development with a single code-base targeting Android, Blackberry, and Desktop. Desktop is great for testing app functionality, with very little Blackberry on-device testing needed once features work in the desktop 'simulator' (a Swing GUI built for debugging our games).
Even though certain components of the RIM development platform are java-based, such as the JDE - other components such as the preverifier and device simulators are implemented as native Windows executables.
Basically, the easiest way to do it is to install Windows on your Mac using Bootcamp or Parallels and run inside a real Windows environment on your Mac.
However, there are other "hackier" ways to do it using Wine, MacPorts, and a number of other tools - as an example see this blog post