Re: [git pull] drm: previous pull req + 1.

Michel Dänzer
2009-06-23T07:57:43Z

On Mon, 2009-06-22 at 18:18 -0700, Jesse Barnes wrote:
> On Tue, 23 Jun 2009 11:04:39 +1000
> Benjamin Herrenschmidt <benh@kernel.crashing.org> 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