Messages in this thread | | | Date | Tue, 23 Jun 2009 08:39:44 -0700 | From | Jesse Barnes <> | Subject | Re: [git pull] drm: previous pull req + 1. |
| |
On Tue, 23 Jun 2009 09:48:00 +0200 Michel Dänzer <michel@daenzer.net> wrote: > > > 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...
Yeah, in the general case we shouldn't have to pin it...
> > (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.
Oh I know, most operating systems have reasonable debugging facilities, and have had for a long time. Linux is the one lagging here.
I agree it probably won't be that helpful for low level gfx debugging, but I'm trying to think beyond that too. :)
-- Jesse Barnes, Intel Open Source Technology Center -- 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/
| |