> 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

Reply via email to