Date: Tue, 23 Jan 1996 13:12:19 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: marino.ladavac@aut.alcatel.at Cc: terry@lambert.org, hackers@freebsd.org Subject: Re: Amancio's tv program with capture! Message-ID: <199601232012.NAA18259@phaeton.artisoft.com> In-Reply-To: <9601231904.AA06008@atuhc16.atusks01.aut.alcatel.at> from "marino.ladavac@aut.alcatel.at" at Jan 23, 96 08:04:16 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > I would suggest adding an mmap() entry point for the device driver > > and calling it when you request pages to be mmapped. The system > > mmap() interface would not be changed, it would just act differently > > for vnodes that were devices. > > > This would work for mapping video memory by device generically as well > > as frame capture buffers, etc.. > > Since it hit the hackers, I'll ask a more general question: > > anybody remembers Sun's pixrect and /dev/fb? Does anyone see something > very wrong about it? > > All agree that video, keyboard and busmouse need to be separated; it's > just too much to do for the current maintainers. > > The last time I had anything to do with pixrect and /dev/fb, it seemed to > me as a reasonable abstraction. It would sure make life easier if we > used graphic card drivers as LKM's, and geared everything towards the > /dev/fb. I guess the X11 implementors might like it. Of course, if > the LKM provided mmap() and various ioctl()s to operate the blitter, > the things might get yet simpler. > > Any obvious fallacies with this? > > Any interest? This has been discussed before but never implemented. The biggest minus is that you would need card specific drivers for the console to support modes supported by the cards in addition to EGA/VGA mode and register emulation. This means having a default driver that gets replaced with a card specific driver. There would also be the need for accelerated command interfaces for direct use of accelerated adapter commands; commands that were not supported (like vector line draws, fills, etc.) would need to be emulated to provide a common, standard interface for users of the device. There would need to be a facility for mixing emulated and unemulated primitives for any given driver (obviously the default would be 640x480 and 800x600 and use the emulated primitives). Then there would be the need to rewrite X to use the new interfaces... effectively, this moves the DDX into the kernel, and that interface could be used as a model to prototype the primitive set for the drivers. This would resolve the 'X' problem once and for all, and give a minimal graphic interface for use by install, etc. I don't know how you would deal with card identification; probably not easily. I suspect that at some point it will be desirable to locate the default video driver in a different segment ID than the rest of the kernel so that pages it used in the default load scenario could be reclaimed once a card specific driver had been loaded (obviating the default driver). The default driver in this case is what I have frequently called a "fallback driver"... it need not use VM86(), unless you intend something like INT 10 based video mode selection (to reliably pick modes for SVGA and/or Diamond cards, etc.). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601232012.NAA18259>