>I thought about this a bit more. Let me propose a different viewpoint as >a result. That viewpoint is that there is no reason for any >acceleration. Scroll at most. > >If the video mode switching is done right and apps can handle graphics >nicely then you need a kernel mode text console at boot, but thinking >about Jon's ideas and the GL without X and other work the rational >argument for _good_ console support becomes that after boot you run a >graphical user space console app built with OpenGL, antialiased true >type font handling, megabyte scrollback, hotkeys, URL detection/menus, >googlizer and the like. >
I agree! The 99% case should just be a user-space console. It is a much more efficient design because currently the console renders rather synchronous with the data being generated which is unnecessary. but back to the banked memory problem. The issue is that writing pixels is a device dependent operation. Just because there are only a handful a ways it is done does not make it device independent. You should be calling a "put" function rather than drawing characters in memory from DI code. The put function's implementation would probably be to call a generic helper but any implementation could be used. The kernel-proper then never draws to memory directly. This also allows any locking or hardware idling to be done transparently in the driver where it belongs. Yes, there is a speed disadvantage but if we are going toward doing 99% of console drawing from a user-space client it is not a concern. >On that basis the kernel driver really can be argued to be boot/debug >only. I don't see this leap? Hardware touching still needs a privileged home. That is either a *.so linked to a root app, A root daemon, or a kernel driver. (perhaps you meant the kernel-proper->driver interface is only used for boot/debug) I still think the solution is user-space API backed by whatever the driver writer wants/needs. My prediction is that you end up with some small kernel driver doing the hardware touching with a thin DD user-space API called from a corresponding DD layer within OGL, X server, whatever. So I think we are jelling around this concept. (Speak up if this doesn't jell with you) 1: A user mode library interface for basic mode setting that does not require elevated privileges. library is backed by whatever technical means suits your fancy. 2: Some optional components to the mode setting interface to deal with some more advanced but still device independent concepts. 3: Any number of device dependent interfaces. 4:A kernel level API so that the kernel-proper can draw in a device independent manner for slow consoles, oopsen, debuggers, and booting. ------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
