> Everyone except for you that I have heard so far has been assuming the > kernel has some very limited capability to change modes in case things > go horribly wrong, which OOM killing this hypothetical small daemon > certainly should qualify as.
I think all the kernel needs is the capability to restore the card state to some 'initial' state, either text mode or basic graphic mode as obtained from the firmware. That is enough for an emergency console. I was initially more in favor of an fbdev-type approach, but that was before I though seriously about all the issues involved, like arbitration, the gazillion of undocumented tmds/lvds transmitter, DACs, etc... the mess of getting things like TV out right and more ... The fbdev interface is just not there and I don't really see ever getting there. I think it's just more realistic to have all of that in a userland daemon with a library for interfacing to it. Easier to debug, portable to other OSes, allow binary drivers more sanely than a kernel implementation would do (I don't like binary drivers but we have to be realistic), and finally, I really think it would make a lot of sense to have something that can wrap an existing X.org DDX (not the best solution but would provide something that works for cases where no "new style" driver exist yet). The kernel side must still exist, for things like DRM, providing mapping to registers, but also suspend/resume activities (at least some of them should be done in kernel), interrupt processing, and maybe other card specific niceties. Ben; ------------------------------------------------------- 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
