Dear HID experts
I need help. I feel like the sorcerer's apprentice. Once I've called
setInterruptReportHandlerCallback, and received all the reports I
want, how do I stop the callback?
Using the HID Utilities, Allen Ingling and I have written an
extension to MATLAB, PsychHID.mexmac, which provides
MATLAB-user-level access to HID commands. It most ways it works well,
providing reliable two-way communication with a number of
HID-compliant devices, including keyboard, mouse, and the PMD-1208FS
data acquisition device. This is very useful and we provide it free
to the user community:
http://psychtoolbox.org/daq.html
However, though useful, our code has a fatal flaw. To receive reports
from the PMD-1208FS we cannot use GetReport (the device rejects the
request by stalling), so we use setInterruptReportHandlerCallback
instead. setInterruptReportHandlerCallback works very well indeed
while we want it. The problem is getting rid of it when we no longer
need it. It seems that once we set up a callback using
setInterruptReportHandlerCallback, we are doomed to crash
(segmentation errors from within CF) when we try to shut down the
callback by anything short of quitting the MATLAB application. We
would like to shut down the callback when our extension is about to
be flushed from memory, or when we are notified that our device has
been unplugged. However, all our attempts to shut down the callback
result in crashes. The crashes are neither prompt nor reliable, and
are thus difficult to track down.
Fernando suggested that we destroy our "connection to the
IOHIDInterface (the callback is released in the destructor for the
IOHIDDeviceClass)." However, I think we are already doing that,
without success.
Initially, we open our connection using this:
if(!HIDHaveDeviceList())HIDBuildDeviceList(NULL, NULL);
At the end, when we are about to be flushed, we close our connection
using this:
if(HIDHaveDeviceList())HIDReleaseDeviceList();
HID_Utilities.c shows that HIDReleaseDeviceList() calls
hid_DisposeDevice(), which calls HIDCloseReleaseInterface(). I think
this is doing what Fernando suggested, but I'm not absolutely sure.
The crashes are a bit hit and miss, so it's possible that I've not
tallied them quite right. However, my impression is that we have no
problems if we never call setInterruptReportHandlerCallback. If we do
call setInterruptReportHandlerCallback, then things work perfectly,
successfully doing many elaborate communications, until we: unplug
and reinsert the device, or flush our extension and try to run it
again. My theory is that setInterruptReportHandlerCallback just won't
let go.
I've pasted below the relevant bits of code, omitting the error
checking. ("error" is always zero.)
Incidentally, I don't know if it's relevant, but the PMD-1208FS is a
composite device with four interfaces. In our code, below, we treat
it as four devices, calling setInterruptReportHandlerCallback for
each interface, since the PMD-1208FS sends reports through all four.
I'd be most grateful for any suggestions.
Best
denis
Denis Pelli
Professor of Psychology and Neural Science
http://psych.nyu.edu/pelli/
static boolean ready[MAXDEVICEINDEXS];
static CFRunLoopSourceRef source[MAXDEVICEINDEXS];
static mach_port_t port[MAXDEVICEINDEXS];
int deviceIndex=1;
long error=0;
pRecDevice device;
IOHIDDeviceInterface122** interface=NULL;
CFStringRef myRunLoopMode = CFSTR("MyMode");
int reason; // kCFRunLoopRunFinished, kCFRunLoopRunStopped,
kCFRunLoopRunTimedOut, kCFRunLoopRunHandledSource
static unsigned char buffer[MAXREPORTSIZE];
UInt32 bufferSize=MAXREPORTSIZE;
// Enable the callback. This works fine the first time. However, if I
enable, disable (see below), and then re-enable, I don't get any
callbacks.
if(!ready[deviceIndex]){
error=(*interface)->createAsyncPort(interface,&(port[deviceIndex]));
error=(*interface)-
>createAsyncEventSource(interface,&(source[deviceIndex]));
CFRunLoopAddSource(CFRunLoopGetCurrent(),source[deviceIndex],myRunLoop
Mode);
error=(*interface)-
>setInterruptReportHandlerCallback(interface,buffer,bufferSize,ReportC
allback,buffer,(void *)deviceIndex);
ready[deviceIndex]=1;
}
// This works fine until I disable (see below).
reason=CFRunLoopRunInMode(myRunLoopMode,0.001,false);
// Disable. This does stop the callbacks, but seems to damage things.
After this we get crashes and cannot re-enable the callback.
// Therefore, we never call this bit of code, even though it's what
the documentation seems to suggest.
#if 0
if(ready[deviceIndex]){
ready[deviceIndex]=0;
CFRunLoopSourceInvalidate(source[deviceIndex]);
source[deviceIndex]=0;
if(port[deviceIndex]!
=0)mach_port_deallocate(mach_task_self(),port[deviceIndex]);
port[deviceIndex]=0;
}
#endif
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Usb mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/usb/email@hidden
This email sent to email@hidden
