[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mesa3d-dev
Subject:    Re: [Mesa3d-dev] suspend/resume and mesa
From:       Jon Smirl <jonsmirl () gmail ! com>
Date:       2005-06-18 14:25:57
Message-ID: 9e4733910506180725442f64e3 () mail ! gmail ! com
[Download RAW message or body]

On 6/18/05, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> 
> > 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.

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.

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
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_idt77&alloc_id492&opĚk
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[prev in list] [next in list] [prev in thread] [next in thread]