On Thu, 2005-06-16 at 22:28 +0100, Dave Airlie wrote: > > > > Out of curiosity - who are the people that *need* intelfb ? (as opposed to > > *want*). > > > Xegl people will need a kernel framebuffer driver (not necessarily running > the console) but something loaded to take care of X when it starts ... > > also this memory manager has to go somewhere, and part of it will be in > the kernel.. no point having a memory manager if someone else is going to > write to your memory anyways..
In fact, the framebuffer support/mode setting doesn't have to be in the kernel stricto-sensus. The only sane approach, from my perspective, is to create a separate library/daemon/whatever that becomes the primary mode setting (& desktop geometry) interface. Wether it lays on top of fbdev or some userland based binary blobs is almost irrelevant (at least it is to the client application). This also isolates us from the underlying kernel beeing linux, some BSD, OS X, whatever... What the kernel need to provide however is some slightly improved DRM that provides the basic services of mapping the card resources, dealing with interrupt, and beeing present as a PCI driver for the card kernel-wise. Wether that kernel part does the actual mode setting (and then the userland library can use it) or not is almost irrelevant. An easy way to prototype such a library however would be to build something on top of fbdev. There are at least 2 different issues also regarding the HW ownership that are more/less overlapping. One is the VGA arbitration, the other one is the basic HW ownership of a given card. fbdev provides absolutely no kind of arbitration/locking/whatever. All we have currently at the linux kernel level is this notion of 'taking control' of the VT subsystem by switching it to KD_GRAPHICS mode. What could be done here is to have our library/daemon be responsible for that. That is, "modern" clients (Xegl, others) would use the library for resource sharing and access arbitration. The library itself would switch the entire system to KD_GRAPHICS on the first client getting in. We need a mecanism to relinguish ownership as well, which includes eventually loss of HW context etc... and proper synchronisation with client programs, to deal with VT switches and system suspend/resume. This is all quite a bit of work, we have discussed various possibilities a while back on IRC and I think I even posted some bits of proposed API for the mode setting bits a long time ago, I've also have some VGA arbitration stuff half-done that I itend to finish for KS, but I lack time and I don't necessarily have perfect ideas on the kind of interfaces to provide for these things. ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
