Re: + pm-gxfb-add-hook-to-pm-console-layer-that-allows-disabling-of-suspen d-vt-switch.patch added to -mm tree

[Pavel Machek <pavel@ucw.cz>]

> > > (Note: I'm not convinced that console_sem is the best way to protect this, but
> > > we should probably have some form of locking..)
> > 
> > I guess this is okay for now, but we probably want to make it more
> > elaborate in future.
> > 
> > Console switch is there to make sure kernel (not X) owns the graphical
> > hardware.
> > 
> > That is unneccessary for gxfb since X never owns graphics hardware,
> > good. (I do not see why it is optional, then. Do you really want to
> > see tty1?)
> 
> Its the dream for the lxfb and gxfb to own the graphics hardware
> completely (at least, thats what Jim Gettys keeps pounding in to my
> brain), but we're not quite there yet.  What we have here are 
> framebuffer drivers that are intelligent enough to save and restore the
> state of the graphics engine, which is still a lot better then most other
> drivers.

Ok.

> > Now, question is what happens with two graphics cards, one of them
> > driven by X. Fortunately that is uncommon.
> 
> We would be screwed.  But since the Geode has built in graphics logic,
> it doesn't make much sense to use an external card, so we'll mostly
> avoid this problem.  But even if it happens, we'll have the VT switch
> available in a pinch.
> 
> > Also, it would be nice to make the logic the other way around. Move vt
> > switching to the drivers that need it because X can be expected to own
> > the hardware.
> 
> Conservation of energy.  Its easier to make 3 or 4 drivers opt out of 

Nice euphemism. You did quick hack instead of proper solution, and
someone will have to clean it up sooner or later...
								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html