From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756761AbZFWH5n (ORCPT ); Tue, 23 Jun 2009 03:57:43 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754454AbZFWH5Z (ORCPT ); Tue, 23 Jun 2009 03:57:25 -0400 Received: from darkcity.gna.ch ([195.226.6.51]:39409 "EHLO mail.gna.ch" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1756679AbZFWH5X convert rfc822-to-8bit (ORCPT ); Tue, 23 Jun 2009 03:57:23 -0400 X-Greylist: delayed 557 seconds by postgrey-1.27 at vger.kernel.org; Tue, 23 Jun 2009 03:57:23 EDT Subject: Re: [git pull] drm: previous pull req + 1. From: Michel =?ISO-8859-1?Q?D=E4nzer?= To: Jesse Barnes Cc: Benjamin Herrenschmidt , Thomas@netline-mail2.netline.ch, Dave Airlie , Andrew Lutomirski , Linux Kernel Mailing List , Jerome Glisse , dri-devel@lists.sf.net, Alex Deucher , Linus Torvalds In-Reply-To: <20090622181832.771dac03@jbarnes-g45> References: <4A3DABE1.50309@mit.edu> <4A3F3E3A.2030202@shipmail.org> <1245715213.4017.13.camel@pasglop> <1245719079.4017.25.camel@pasglop> <20090622181832.771dac03@jbarnes-g45> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Date: Tue, 23 Jun 2009 09:48:00 +0200 Message-Id: <1245743280.5580.2203.camel@thor.local> Mime-Version: 1.0 X-Mailer: Evolution 2.26.2 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2009-06-22 at 18:18 -0700, Jesse Barnes wrote: > On Tue, 23 Jun 2009 11:04:39 +1000 > Benjamin Herrenschmidt wrote: > > > On Mon, 2009-06-22 at 17:24 -0700, Linus Torvalds wrote: > > > > > > On Tue, 23 Jun 2009, Benjamin Herrenschmidt wrote: > > > > > > > > As far as I can remember, all fbdev operations are done under the > > > > console semaphore. > > > > > > Yeah, and some of them are horribly broken (ie copying data from > > > user space while doing it - causing horrible things like VC > > > switching latencies and invisible printk's if an oops happens > > > during the op). > > > > > > Or maybe that got fixed. > > > > Well, it does rely on userspace behaving.. ie, no accel ops are done > > by the kernel in KD_GRAPHICS and userspace is -supposed- to switch to > > KD_GRAPHICS before touching the fb. > > > > In fact, nowdays, we do have the infrastructure to be smart and > > enforce that. IE. Instead of using a boring remap_page_ranges() in > > fb_mmap() we could use a fault handler. When in KD_TEXT, we fail > > them, when in KD_GRAPHICS, we service them, and we > > unmap_mapping_range() when switching. Something like that... > > > > Dunno how that interacts with the new DRM thingy though. > > I think it could work, but ideally we'd keep the kernel fbcon object > pinned, and keep printing into it even while some other gfx app is > running. It doesn't need to be pinned for that, does it? I think in the long run it's a bad idea to have it pinned all the time, think of machines with only 8 MB of VRAM... > (something like this would also be handy for dual head debugging; one > head running your desktop and the other a debug console printing all > the messages). On a side note, I did precisely that about ten years ago on my Amiga. :) Granted, that was using two separate framebuffer devices (X glint driver on top of pm2fb, debug messages on amifb), but I think even that case isn't possible ATM. I agree it would be nice, though realistically there's hardly a way around a second machine for graphics driver development anyway. -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer