[Pxc] pxc and pxcdd libraries anyone ?

[Franco Callari]

>Well, I've no such experience, I've never written anything under windows.

Lucky you - I *have* to, at work. At home I only run Linux.
 
>> What exactly you don't like?
>
>Name space pollution, for instance. I didn't understand all the
>methods are fields of a grabber object ("pxc->Grab()" is good, while
>"Grab()" is not).

But that's done exactly to _prevent_ name space pollution. You cannot
call "Grab()" directly, since Imagenation's PXC functions can be called 
only through function pointers in a grabber struct. 
That's the closest thing you can get using C to C++'s calling of an object's method.
The result is that, both from C and C++, you end up calling them as pxc->Grab(),
and it is one reason why I think Imagenation's design is well thought. Of
course, API design is a highly opinable matter, but I ended up liking what
they did, and they don't pay me for saying that :-)

> And other stuff that presumes exclusive access to
>the device 

Hmmm, not sure what you mean here - all the PXC APIs take a frame grabber
handle as argument, so you can access more than one, if you have several
cards sitting on your bus. If you mean multithreaded access, you are right,
in that only one thread is supposed to access each frame grabber. But I think
that has more to do with the fact that the card keeps its status on board, rather
than with a limitation of the API itself. Correct me if am wrong.

>> Yup, a library is exactly what I have in mind. It sits on top of your
>> driver and provides a drop-in replacement for Imagenation's higher-level 
>> APIs.
>
>... as long as the low-level functionality is implemented :)

Well, from my (admittely, still cursory) inspection of your driver, it seems
to me most, if not all, the hooks needed for the port are already in your
driver. For example, the WaitFinished() api that's used to synch the program
with the frame grabber in asynchronous grabbing mode can be probably implemented 
using your PX_IOCACWAITVB ioctl and a coroutine. And Zanchi's region of
interest support should allow for porting the "image width/hight/position"
apis.

>While my driver is not as full-features as it may be, I now have
>another person looking over it, so some glitches will be sorted
>out and mid-implemented features will finally see the light.

Good. Well, my plan for now is to put down a design for the library and
start hacking. When I have enough code to show I'll park it in CVS
someplace (e.g. sourceforge) and ask for comment/help/improvements. Hope
I can keep bugging you with questions about the driver if I find myself in
trouble. Ok?

Cheers
Franco

>
>/alessandro

--
Francesco G. Callari              "So, putting it simply, STL is the 
Geometrix, Inc.                    result of a bacterial infection"
1590 The Alameda, Suite 200        (A. Stepanov)
San Jose, CA, USA, 95126 

FrancoC@geometrix.com | ph: +(408) 999-7480 | fax: +(408) 289-8258

        E0E0 2296 CDED A9D6 3D9F  1EBF 7B97 8ED6 5C7E C03D