--- Michel Dänzer <[EMAIL PROTECTED]> wrote: > On Sat, 2004-03-13 at 04:54, Jon Smirl wrote: > > > > The code for the proposed IOCTLs is written and tested. They would be added > one > > at a time. > > Do you have a patch for us to look at?
I'll start sending the patches out if everyone is ok with the general concept. > > > > 3) BLANK - simple call to allow Vesa power management to blank the display. > > > > A fourth call will be a driver specific call for setting the video mode. I > am > > implementing this by completely computing the register values needed to set > the > > mode in user space. I then pass these as a struct to the IOCTL and the > driver > > sets the mode. Doing it this way moves about 100K of code (in the radeon > case vs > > framebuffer) out of the kernel and into user space. > > Is the verification of the input data really that much smaller? Yes. Big chunks of Benh's driver and the mode parts of fb can easily be moved to user space. It only took a couple of days. Mode setting code is seldom used as compared to an interrupt handler, this gives the space back for more important things and eliminates the need to security audit the code. It's also much easier to debug. current radeonfb + fb + radeon is about 300Kb code > I still don't quite see the point of duplicating framebuffer device > functionality in the DRM... I'm not really duplicating framebuffer. I took the framebuffer code and the DRM code and merged them into a single driver. Then I'm moving everything I can out of the kernel and into user space. The goal is to provide an OpenGL stack which is capable of being the only interface to the hardware. Doing this builds the graphics API at a very high level. A high level API will let the hardware change transparent to the software. For example SGI hardware does not have access to the framebuffer; PC hardware with a similar architecture is coming soon. It also makes it easy for ATI/Nvidia to provide monolithic driver stacks. It's a path to providing more controlled access to the graphics hardware. Right now we have a free for all when every app and device driver can just do what it wants to the hardware. What if I am running X/DRI in one VT and another app that does direct 3D drawing via the hardware on another VT. Does framebuffer preserve the complete state of the hardware at VT switch? Although I haven't written the code yet, I intend to add a output-only console driver entry point to DRM. Since mode setting is now tracked through the DRM driver it will be possible to display a kernel oops that occurs while running xserver. This is something framebuffer can't currently do. The state of graphics on Linux needs to move forward. Microsoft Longhorn is going to ensure that every PC built in the future has capable graphic coprocessor support. Don't think of this as 3D vs 2D, think of it as a switch from dumb to intelligent hardware. There is a lot of complicated code to be designed and written and we've got a year to do it if we're going to beat Microsoft. Let's all work together to achieve this transition in Linux. ===== Jon Smirl [EMAIL PROTECTED] __________________________________ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
