From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Date: Tue, 30 Apr 2013 10:28:42 +0000 Subject: Re: [PATCH V2] video: implement a simple framebuffer driver Message-Id: <201304301228.42245.arnd@arndb.de> List-Id: References: <1365043183-28905-1-git-send-email-swarren@wwwdotorg.org> <517F7245.2050606@iki.fi> In-Reply-To: <517F7245.2050606@iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-arm-kernel@lists.infradead.org On Tuesday 30 April 2013, Tomi Valkeinen wrote: > The bootloader would init the display hardware, the bootfb would give an > early /dev/fb0 for the kernel and userspace, and when the real display > driver is loaded, the bootfb would be unbound and the real driver would > take over. I think that's a great idea. What I'm not sure about is how that infrastructure for switching frame buffers would work and how hard it's to write. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Tue, 30 Apr 2013 12:28:42 +0200 Subject: [PATCH V2] video: implement a simple framebuffer driver In-Reply-To: <517F7245.2050606@iki.fi> References: <1365043183-28905-1-git-send-email-swarren@wwwdotorg.org> <517F7245.2050606@iki.fi> Message-ID: <201304301228.42245.arnd@arndb.de> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tuesday 30 April 2013, Tomi Valkeinen wrote: > The bootloader would init the display hardware, the bootfb would give an > early /dev/fb0 for the kernel and userspace, and when the real display > driver is loaded, the bootfb would be unbound and the real driver would > take over. I think that's a great idea. What I'm not sure about is how that infrastructure for switching frame buffers would work and how hard it's to write. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [PATCH V2] video: implement a simple framebuffer driver Date: Tue, 30 Apr 2013 12:28:42 +0200 Message-ID: <201304301228.42245.arnd@arndb.de> References: <1365043183-28905-1-git-send-email-swarren@wwwdotorg.org> <517F7245.2050606@iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <517F7245.2050606-X3B1VOXEql0@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org Sender: "devicetree-discuss" To: Tomi Valkeinen Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org, Tomasz Figa , Rob Clark , Geert Uytterhoeven , linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, Andrew Morton , linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, Laurent Pinchart List-Id: devicetree@vger.kernel.org On Tuesday 30 April 2013, Tomi Valkeinen wrote: > The bootloader would init the display hardware, the bootfb would give an > early /dev/fb0 for the kernel and userspace, and when the real display > driver is loaded, the bootfb would be unbound and the real driver would > take over. I think that's a great idea. What I'm not sure about is how that infrastructure for switching frame buffers would work and how hard it's to write. Arnd