On Wed, 2003-10-29 at 09:09, Jon Smirl wrote: > 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?
Here, you are going away from Linus suggestion. While it makes sense too, it would be a real pain to keep that single driver in sync between the different parties, to keep backward compatibility, etc... re-read Linus emails on this topic. I tend to agree with him here, what we want is a small low level layer that does the strict minimum to provide DMA/irq and arbitration. > 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). That mode setting / EDID is done in drivers on other platforms as well, I don't see the problem here. It's the basic "feature" provided by the framebuffer driver, it doesn't only make sense for fbcon but also for other framebuffer apps. Mapping the framebuffer into kernel space isn't necessary. It's how today's fbcon works, but it's not mandatory. In fact, if fbcon was fully accelerated, mapping the fb would be useless. > 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. DSO ? Can you translate ? > 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? So we lose the ability to get early boot messages and printk at interrupt time ? no thanks ! Looks you aren't regulary faced with the need to debug kernel code ;) > 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. fbcon can still be in the kernel. I see no point in your push to move it down to userland, provided that it stays a clearly separate entity from the fbdev itself, just another client. Ben. ------------------------------------------------------- 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
