Michal Suchanek wrote:
> On 6/21/06, Perry E. Metzger <perry@piermont.com> wrote:
>>
>> Garrett D'Amore <garrett_damore@tadpole.com> writes:
>> >> This is not surprising. S3 is allowed to power off *everything* but
>> >> memory, so the state of the video chip is lost. On restore we do a
>> >> reset of the video, but we don't know what the state of the chip was
>> >> before sleep. X effectively manages the drivers entirely in userland,
>> >> so unless X decides to re-initialize the display it is going to be
>> >> screwed up.
>> >
>> > This is another example of why, IMO, the architecture of X talking
>> > directly to registers is an incredibly bad idea.
>>
>> It might (or might not) be a bad idea, but we simply do not have the
>> manpower to deal with the vast flow of new video cards that arrive
>> with time. We have to use the X.org drivers because by doing that, we
>> get to piggyback on all their manpower. Unless you have a way to fix
>> that problem, even if the current system sucks rocks, we'll have to
>> continue using it.
>
> I guess the problem is that the X driver messes directly with the
> card's registers but assumes nobody else would do that. It just
> happened to work most of the time in the past but it is plain wrong.
>
> Sometimes it helps a bit to switch from X to text mode before the
> sleep so that X reinitializes at least something when switching back
> to X.
>
> But often X is not performing reset of the card even on startup
> because it is not known how to get the card into an usable state
> without the card's BIOS or other external tool preinitializing it.


Very true.  The X drivers typically assume BIOS initialization.  The
Radeon is a good example of this, where a bunch of undocumented setup
for memory timings, etc. happens in BIOS.

In the case of Radeon, I actually have code that does a full
initialization _without_ BIOS, but I got the info for it under NDA from
ATI -- I'm trying to talk ATI into letting me release it with the rest
of my radeonfb, but I don't know yet whether they will or not.

    -- Garrett
>
> Thanks
>
> Michal


-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191