--- Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > The problem is the same. DMA or not DMA, what we want is arbitration. > > When fbdev sets up a mode, the X server mustn't blast 2D engine (either > using PIO or sending DMA commands) etc... So that "arbitration" module > will have to provide the necessary arbitration so that the 2D/3D DMA > command flow can be interrupted (if any), and/or the hw access "lock" > passed between things like fbdev/fbcon and userland clients.
Do we really want arbitration between multiple things (FB, X, DRI, etc) all trying to control the video hardware at a register level? This is like writing a multitaking system for device drivers. Or do we want a single device driver with multiple clients? A major complaint from the framebuffer console people is that we have to do mode setting/EDID in the device driver so that there is a console to look at from the first second the kernel boots. This also means we have to map the framebuffer into kernel space (sucking up to 256MB of kernel address space). In the 2.7 time frame is it possible to write a low level driver like Linus proposed plus a small DSO for mode setting/EDID. Then write fbconsole as a user space app that is loaded much eariler in the boot process than user-mode currently starts? In other words is there a solution to having a boot time console that doesn't involve running it in a device driver? Another possible solution to the boot time problem would be to write a disposable device driver. The disposable driver would set the mode/EDID and run the console until user mode started; then self destruct. ===== Jon Smirl [EMAIL PROTECTED] __________________________________ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/ ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
