LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Jordan Crouse <jordan.crouse@amd.com>
Cc: Jim Gettys <jg@laptop.org>, "Brown, Len" <len.brown@intel.com>,
Linux Kernel ML <linux-kernel@vger.kernel.org>,
Dominik Brodowski <linux@dominikbrodowski.net>,
ACPI ML <linux-acpi@vger.kernel.org>,
Adam Belay <abelay@novell.com>,
"Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>,
Arjan van de Ven <arjan@linux.intel.com>,
devel@laptop.org, Bjorn Helgaas <bjorn.helgaas@hp.com>
Subject: Re: ACPI: Idle Processor PM Improvements
Date: Thu, 14 Sep 2006 11:20:49 +0200 [thread overview]
Message-ID: <20060914092049.GB15102@elf.ucw.cz> (raw)
In-Reply-To: <20060912201805.GK14885@cosmic.amd.com>
On Tue 2006-09-12 14:18:05, Jordan Crouse wrote:
> On 12/09/06 14:14 -0400, Jim Gettys wrote:
> > > Alternatively, hack kernel to take control from X without actually
> > > switching consoles. That should be possible even with current
> > > interface.
> >
> > This would require saving/restoring all graphics state in the kernel
> > (and X already has that state internally). Feasible, but seems like
> > duplication of effort. I haven't checked if there are any write-only
> > registers in the Geode (though, thankfully, this kind of brain damage is
> > rarer than it once was). This then begs interesting kernel/X
> > synchronization issues, of course.
>
> We don't need any kernel output during suspend or resume. Thus, if the VT
> doesn't change, then the kernel doesn't need worry about saving or restoring
> the graphics state, and thats the way it should be, IMHO.
> Whoever owns the current VT should be in charge of saving and restoring
> the registers.
>
> So, we would need some way of indicating the "ownership" of the VT. And
> in reality, we really only to know if the framebuffer console owns it or
> not, so a boolean would suffice. In the past, I've used KD_TEXT and
> KD_GRAPHICS for this purpose. As an example, on the Geode LX, I assume
> that if the vc_mode is KD_GRAPHICS, then we don't own it, and we don't
> do 2D accelerations. If the mode is KD_TEXT then we are free to use the
> 2D engine. All I needed to add ws a notifier chain to let the framebuffer
> know when the mode switched, and I was happy. I'm not sure if thats the
> smartest way to handle it permanently, but it works in a pinch.
KD_TEXT vs. KD_GRAPHICS looks like the way to go. Just tell X you want
console back, but then don't actually redraw/switch consoles. We
probably want that on normal PCs, too... console switch for
suspend-to-RAM looks ugly.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
next prev parent reply other threads:[~2006-09-14 9:20 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-30 18:40 [RFC][PATCH 1/2] " Pallipadi, Venkatesh
2006-08-30 19:43 ` Matthew Garrett
2006-08-31 23:13 ` Bjorn Helgaas
2006-09-01 0:30 ` [OLPC-devel] " Jim Gettys
2006-09-01 3:53 ` Len Brown
2006-09-01 4:12 ` Matthew Garrett
2006-09-01 15:51 ` Jordan Crouse
2006-09-01 13:14 ` [OLPC-devel] Re: [RFC][PATCH 1/2] " Carl-Daniel Hailfinger
2006-09-01 21:52 ` Andi Kleen
2006-09-01 22:57 ` Alan Cox
2006-09-04 13:13 ` Pavel Machek
2006-09-04 13:09 ` Pavel Machek
2006-09-05 14:31 ` Jim Gettys
2006-09-06 10:37 ` Pavel Machek
2006-09-06 14:58 ` Jordan Crouse
2006-09-12 9:21 ` Pavel Machek
2006-09-12 18:14 ` Jim Gettys
2006-09-12 18:27 ` Mitch Bradley
2006-09-12 20:18 ` Jordan Crouse
2006-09-14 9:20 ` Pavel Machek [this message]
2006-09-14 9:18 ` Pavel Machek
2006-09-14 11:29 ` Jim Gettys
2006-09-06 15:19 ` [OLPC-devel] Re: [RFC][PATCH 1/2] " Jim Gettys
2006-09-12 9:21 ` Pavel Machek
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=20060914092049.GB15102@elf.ucw.cz \
--to=pavel@ucw.cz \
--cc=abelay@novell.com \
--cc=arjan@linux.intel.com \
--cc=bjorn.helgaas@hp.com \
--cc=devel@laptop.org \
--cc=jg@laptop.org \
--cc=jordan.crouse@amd.com \
--cc=len.brown@intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@dominikbrodowski.net \
--cc=venkatesh.pallipadi@intel.com \
--subject='Re: ACPI: Idle Processor PM Improvements' \
/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
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).