Subject: Re: X (was Re: Call for testers: i386 ACPI suspend/resume support)
From: Michal Suchanek <firstname.lastname@example.org>
Date: 06/21/2006 16:01:48
On 6/21/06, Perry E. Metzger <email@example.com> wrote:
> Garrett D'Amore <firstname.lastname@example.org> 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
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.