From: Jon S. <jon...@gm...> - 2005-06-18 14:32:41
|
On 6/18/05, Benjamin Herrenschmidt <be...@ke...> wrote: >=20 > > 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. >=20 > 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. >=20 > 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. Where are you now on mode list generation and DDC probing? Last year you we in-kernel and I was user space. You wanted in-kernel to get the DDC list to set the initial mode during boot. I wanted user space because there is no way to adjust the DDC via a file in /etc from in-kernel. The DDC code is about 25K. Right now fbdev generates the list in-kernel at boot. I have code that generates an event on monitor change that triggers a user space app. The app reads DDC, merges with the /etc file, and use /sys/class/graphics/fb0/modes to set the new mode list. Changing the mode list generates an fbdev event. fbconsole picks up this event and will search for the nearest mode to what it had and swap to it. Another part of mode setting is restricting the set of modes a normal user can set. This prevents a virus from setting modes that will burn up the monitor. In my scheme (already in the kernel tree) you can cat /sys/class/graphics/fb0/modes to see the mode list. Then echo "mode name from list" >/sys/class/graphics/fb0/mode to set it. fbconsole will pick up the mode change. This model does not prevent user space mode setting code. After the new mode name is in the kernel and checked against the valid mode list, just send it out to call_userhelper(). My code was originally written that way until various people beat it up for out of memory issues, then I reverted to in-kernel. As for arbitrating things, the current X server disables all video cards (expect the ones it is using) on VT swap. That behavior is completely incompatible with mutltiuser use of the other cards. --=20 Jon Smirl jon...@gm... |