linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: John Zielinski <grim@undead.cc>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Linux Fbdev development list
	<linux-fbdev-devel@lists.sourceforge.net>,
	James Simmons <jsimmons@infradead.org>
Subject: Re: Restoring Screen when coming back	from	KD_GRAPHICS
Date: Wed, 24 Dec 2003 20:22:51 -0500	[thread overview]
Message-ID: <3FEA3BEB.2060608@undead.cc> (raw)
In-Reply-To: <1072306057.15476.19.camel@gaston>

Benjamin Herrenschmidt wrote:

>I don't think we need to "save" anything, there is no way I want any
>knowledge of fbcon-specific stuff to go back into fbdev's, it was
>hard enough to split these properly (that's a good thing James did).
>  
>

I was using "save" as in "don't overwrite".    The fb_var_screeninfo and 
fb_cmap structures are the two main ones.  If we have seperate ones for 
each vt and one for when a graphics app then the contents of each is 
"saved" and can be restored by fbcon very easily.

But if a fbdev can't recreate it's state from the information that fbcon 
provides (var, cmap, etc) because it has some internal driver or hw 
state info then there needs to be a way for fbcon to tell the fbdev "put 
your internal state in this buffer" so it can be remembered when things 
get restored later.  That way the fbdev doesn't have to worry about any 
of the high level stuff.  It just gets the contents of that buffer back 
when things get restored.   Fbcon can ask the driver on startup as to 
how many bytes of buffer space does it need for it's save area and if 
the fbdev doesn't need any (it can totally restore it's state using the 
normal set_var mechanism) it can just say zero.

>I think we just need to instruct the fbdev to restore it's mode via
>a set_var with an activate flag FB_ACTIVATE_FORCE, that bypass any
>test inside the driver about the mode changing from the current info-var,
>that is basically forcing it to re-apply it's current var. Most drivers
>will also reset the accel engine properly if any when doing so.
>  
>

Can all the fbdevs restore everything with just that information?   If 
so then we don't have to worry about the internal state save buffer 
stuff above.

John




-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

  reply	other threads:[~2003-12-25  1:23 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-26  8:11 Restoring Screen when coming back from KD_GRAPHICS John Zielinski
2003-12-24  8:26 ` Benjamin Herrenschmidt
2003-12-24 22:07   ` John Zielinski
2003-12-24 22:47     ` Benjamin Herrenschmidt
2003-12-25  1:22       ` John Zielinski [this message]
2003-12-25 10:37         ` Benjamin Herrenschmidt
2003-12-25 16:28           ` John Zielinski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3FEA3BEB.2060608@undead.cc \
    --to=grim@undead.cc \
    --cc=benh@kernel.crashing.org \
    --cc=jsimmons@infradead.org \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).