linux-kernel - Re: [OLPC-devel] Re: [RFC][PATCH 1/2] 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:	Wed, 06 Sep 2006 11:19:09 -0400
From:	Jim Gettys <jg@...top.org>
To:	Pavel Machek <pavel@....cz>
Cc:	Bjorn Helgaas <bjorn.helgaas@...com>,
	Matthew Garrett <mjg59@...f.ucam.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
Subject: Re: [OLPC-devel] Re: [RFC][PATCH 1/2] ACPI: Idle Processor PM
	Improvements

On Wed, 2006-09-06 at 12:37 +0200, Pavel Machek wrote:
> Hi!
> 
> > > 2.4 and 2.6 are *very* different here. You'll probably need to optimize freezer
> > > in 2.6 a bit...
> > > 						
> > 
> > Among other problems: e.g. 2.4 did not automatically do a VT switch; 2.6
> > does; we'll have to have a way to signal "we're a sane display driver;
> > don't switch away from me on suspend".
> 
> Not like that, please.
> 
> You are using X running over framebuffer, right? So that kernel is
> controlling the graphics hardware. In such case it is safe to avoid VT
> switch.

It should be perfectly safe.

The Geode has significantly more than dumb frame buffer support, even
though it can't support 3D in hardware (we do get blit and alpha
blending, and YUV->RGB support in hardware).

We have an fbdev driver for the hardware (in fact, have to finally have
a decent driver in general, as the transfer to and from DCON controlled
display has to happen at interrupt time).  We won't be doing thing evil
in X behind the operating system's back the way most XF86 drivers do,
but very much the way display drivers supported X before the strange
notion of completely OS independent drivers without any kernel support
twisted the way XF86 drivers usually work.  Ah, back to the future
(past)....
                                        - Jim


-- 
Jim Gettys
One Laptop Per Child


-
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/