Subject: Re: [PATCH] Framebuffer: client notification mecanism & PM
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: James Simmons <jsimmons@infradead.org>
Cc: Petr Vandrovec <VANDROVE@vc.cvut.cz>,
       linux-kernel mailing list <linux-kernel@vger.kernel.org>,
       Linux Fbdev development list 
	<linux-fbdev-devel@lists.sourceforge.net>
In-Reply-To: <1059510171.8538.53.camel@gaston>
References: <Pine.LNX.4.44.0307291753530.5874-100000@phoenix.infradead.org>
	 <1059510171.8538.53.camel@gaston>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1059567764.8538.76.camel@gaston>
Mime-Version: 1.0
Date: 30 Jul 2003 08:22:44 -0400
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1107
Lines: 26


> > I knew it was a matter of time before "client" management would happen. 
> > Is this a 2.6.X thing tho or shoudl we wait for the next developement 
> > cycle. I don't mind working on experimental stuff.

Note, BTW, there's also a locking issue. Typically, we must make sure
the fbcon (which may be running another CPU) have finished doing whatever
it was doing before returning, and we don't get any mode change or 
whatever ioctl initiated thing at that moment (or be in the middle of
doing it).

Right now, my code assumes any operation on the fbdev is protected by
the console sem. However, looking at the console & fbmem code, that is
not always true. Typically, userland ioctls in fbmem aren't, and vt.c
may call into consoles in some cases without holding it neither.

That should probably be fixed, though I haven't had time to work on
it yet.

Ben.

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