On Wed, 2005-06-22 at 02:48 +0100, Dave Airlie wrote: > > > > I don't see this process adding huge amounts of code to the drivers, > > I'm halfway through and I don't think I've added hardly any code at > > all. Mostly I just rearrange what is already there. > > > > Linux already has existing fbdev drivers for mode setting. I am > > choosing to use those now since I wasted a year messing around trying > > to add mode setting directly to DRM. I now realize that there are > > vocal, powerful supporters behind using the fbdev code. I want to get > > my server working so I am choosing the path of least resistance and > > using fbdev. > > But there are also people who are against it and my thinking is that with > benh now thinking we should avoid using fbdev, we should maybe start to > think about it.. > > My presentation at desktopcon is an effort to cover this, I'll give the > same one to KS in a slightly modified form.... > > We can't mode set in the kernel for every chip, we know this, intelfb > doesn't modeset in the kernel if you aren't using a single CRT (i.e. BIOS > isn't needed)... this can't be fixed in the current fb architecture so we > need something new... > > After talking with Ben a few days back, I'm getting the idea we are going > to need a user-space server process that does all of this, call it 0 > (zero) as X-X = 0, this 0 process is started by init and has card specific > loadable modules, that just init the in-kernel driver with some info from > a file in /etc and maybe some other stuff.. you have it reading a kernel > netlink or something similiar for kernel mode change events from a kernel > side driver, (so your mode change API can still happen), > > at startup it can just setup the memory manager, detect monitors (could > also wakeup every so often if needed for monitor hotplug detection), it > woudln't need to do an initial modeset I don't think, until someone else > comes along and asks for it.. so a userspace console would just be an app > like anything else.. things like Xegl and KAA/Shiny would use the same > basic infrastructure and not care ... > > this process would run as root so you can then audit it, it would be much > smaller than X, and it would run in userspace so we wouldn't have to audit > it as much for doing evil things.. the less code in the kernel the less > code I have to review ;-)
This is the best thing I've heard in this discussion so far! I'm still concerned by the handwaving involved in how apps are going to interact with mode setting (yes, I do want to be able to have my video game switch to 1280x1024), but I have nothing concrete to offer either. -- Eric Anholt [EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] ------------------------------------------------------- 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
