nanogui@linuxhacker.org

That's a good idea.

The linux driver allows multiple opens and so the mw app could reopen the
device and call ioctl()'s. However, the device also allows multiple drawing
surfaces. Mw will not be the only thing running against this driver, and
there could even be multiple instances of mw running (I don't know why, but
it's possible). In any case, I'd need to find out which surface the mw
screen driver was assigned.

This could be done by passing back the surface handle through a user-defined
int in MWSCREENINFO. Or by hijacking one of the existing parameters...any
suggestion?

For now, I could assume one surface and have the linux driver pass it back
to me when I open the device a second time.

-----Original Message-----
On Fri, 20 Oct 2000, David Erickson wrote:
> I've just finished porting Microwindows to an r&d cable set-top box. You

Cool. Is this something likely to make it into production?

> Because I'm overlaying microwindows on the tv picture, I have some special
> needs. My apps need to make some custom calls to the video card, and the
> driver has the necessary handles and pointers. I need something like an
> ioctl call where I can define my own control codes and pass some custom
> data. 

Can't you just extend your framebuffer driver to allow multiple open()s?
ie. only one process is allowed to mmap() it at a time, but anything can
do ioctl()s to play with the settings and stuff...

-- 
--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------