On Thursday, May 30, 2002, at 03:27 PM, Francis bouchard wrote: On 30/05/02 17:00, "Shawn Erickson" <shawn@freetimesw.com> wrote: When your frame buffer driver attaches to your effect driver... how do things operate? It sounds like the frame buffer it still assuming it is matching against your hardware. Basically your frame buffer is not attached to your hardware at this point but to your effect driver. I'm not sure about this one! How should it be. I've put the pci device id but what should I put there if I want it to match to the effectDriver ? The class name ? Do I still use IOPCIMatch or another obscure (for me at least) tag. You only need to use IOPCIMatch if your diver needs to match against hardware... so effect driver: yes, frame buffer: no. To get your frame buffer to match against your effect driver then you must specific the effect drivers class name in IOProviderClass. Your prior emailed plists looks correct with the one exception you still have IOPCIMatch listed in you frame buffers plist. [What is com.matrox.driver.MatroxBoard listed in your effect driver plist? This may be a typo.] Anyway my question was more along the lines of how do expect/want your two drivers to work with one another once they have been matched, which leads to... [Or does only your effect driver need interact with your hardware and your frame buffer ask it do things when needed?] This is exactly how I would like it to be. It's gonna be much simpler since the effect driver already handles synchronisation between requests. So matching gets your frame buffer to know about your effects driver... after this point it is up to you to define and implement the way they will interact with each other. I would consider using the open/close semantics provided by IOService so that the connection between your frame buffer and effects driver is tracked (lookup open & close on IOService). Basically define methods on your effects driver class that expose the functionality needed by your frame buffer class. Then all your frame buffer need do is call methods on the effect driver class as needed. I would still use the workloop that your effect driver uses to sync your frame buffer functionality as it cuts down on the number of workloops (fewer threads). In your frame buffer start method retain and save a reference to your effect driver, open the effect driver, do what preparation is needed, and return true. Then as your frame buffer is asked to do things internally you call your effect driver as needed. Also have your getWorkloop method call the effects driver getWorkloop method (unless IOFrameBuffer is design to have it own... I don't know?). When stopping your frame buffer should cleanup, close the effect driver and release its reference. -Shawn _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.