On Tue, 23 Jun 2009 09:48:00 +0200 Michel Dänzer <mic...@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 ------------------------------------------------------------------------------ Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
