uludaggonul / snow-dots

Automatically exported from code.google.com/p/snow-dots
0 stars 0 forks source link

mexHID optionally sieze HID device #38

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
I was talking to Victor De Lafuente about his monkey physiology task, 
implemented with Expo and Plexon.  He pointed out that his was of reading from 
a touch screen was crazy: read touchscreen HID positions into a windows PC, 
re-output them with a Measurement Computing USB device, and read them in to 
Expo as analogs.

It would be much easier just to read then mous positon with the Mac running the 
experiment (Expo, Matlab, whatever).  But this should not interfere with the 
regular system mouse.

The IOKit concept of "seizing" a device should accomplish the right thing: 
making a particular HID's inputs visible to mexHID.  So to seize should be an 
option during device opening.

Is there a widows HID implementation analog?  Doesn't matter right now.

What should be the default--to seize or not?  Not seizing seems like the least 
surprising.

Original issue reported on code.google.com by Benjamin.Heasly on 7 Sep 2010 at 7:06

GoogleCodeExporter commented 8 years ago

Original comment by Benjamin.Heasly on 23 Sep 2010 at 5:46

GoogleCodeExporter commented 8 years ago
As of r387, mexHID openAllMatchingDevices and openMatchingDevice take an 
optional isExclusive argument.

When true, will try for exclusive device access with the OS X/IOKit 
kIOHIDOptionsTypeSeizeDevice option.  The default is not to try for exclusive 
access.  If a device is already seized, opening will fail with negative status.

Aside:
I found that I had been using the HID manager wrong.  I never needed to "open" 
the manager because I was opening individual devices instead.  I also never 
needed to schedule the manager with the run loop.  Opening and scheduling the 
manager is really just there to open and schedule matched devices, which I'm 
not trying to do.

I don't need to schedule devices with the run loop because I'm not using 
device-level asynchronous functions.  Only queues need scheduling, so far.

But I may later need to schedule devices...

Original comment by Benjamin.Heasly on 24 Sep 2010 at 8:26