linux-kernel - Re: ACPI: Idle Processor PM Improvements

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 14 Sep 2006 11:20:49 +0200
From:	Pavel Machek <pavel@....cz>
To:	Jordan Crouse <jordan.crouse@....com>
Cc:	Jim Gettys <jg@...top.org>, "Brown, Len" <len.brown@...el.com>,
	Linux Kernel ML <linux-kernel@...r.kernel.org>,
	Dominik Brodowski <linux@...inikbrodowski.net>,
	ACPI ML <linux-acpi@...r.kernel.org>,
	Adam Belay <abelay@...ell.com>,
	"Pallipadi, Venkatesh" <venkatesh.pallipadi@...el.com>,
	Arjan van de Ven <arjan@...ux.intel.com>, devel@...top.org,
	Bjorn Helgaas <bjorn.helgaas@...com>
Subject: Re: ACPI: Idle Processor PM Improvements

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/