> > 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 ;-) Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG ------------------------------------------------------- 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
