On Tuesday, March 18, 2008 9:54 am Tom Cooksey wrote: > I've had some time to play with the modesetting branch. I am using a laptop > with an Intel 965GM, is this likely to work? At the moment, when I run > tests/modedemo I get a hard lock. :-/
Yeah, that should be a good platform... > I have a few comments/questions from what I've looked at so far: > > 1) The current libdrm looks to be a very thin wrapper around the ioctls. If > this is the case and all the code is kernel-side, what are the thoughts of > implementing a linuxfb driver ontop of this? It would be pretty cool to get > fbcon rendering using DRM? There should be an option you can give to the i915 driver when you load it, modeset=1 iirc, to make it actually change modes and register the fbcon compatibility driver (see intel_fb.c in the source). > 2) Sortof related to the above... it would be very cool to have a very > simple drawing API to use on top of the modesetting API. A simple blit & > solid fill would surfice. I've always found it odd that the internal kernal > API for framebuffer devices includes blit and solid fill, but that API is > never exposed to user-space applications - even though it would be _very_ > useful. Sure, nothing wrong with exposing those as part of a simple API. However there's also no reason you have to do it in the kernel, you could just add code to emit blts & solid fills to an i915 specific bit of libdrm code. IIRC airlied has been thinking about adding driver specific libdrm bits for awhile... > 3) The drmBOCreate() looks fun. Could we use this to store pixmaps? Again, > having an API to blit a pixmap created with drmBOCreate() to the > framebuffer, would be very nice. Even nicer if porter-duff composition > modes were supported, although a simple blit would be a massive leap > forward. Yep, should be usable for whatever you want, given that you allocate with the right options for your chip (adhering to stride limitations, alignment, cacheability requirements etc.) > 4) The API doesn't seem to provide any mechenism for syncing framebuffer > updates to VBLANK. Does this mean the sync is done automatically, i.e. > after unmapping the framebuffer, the contents on the screen aren't actually > updated until the next vblank? The i915 driver exposes two methods for doing this, one via I915_VBLANK_SWAP (probably the best option) and another via the regular DRM_IOCTL_WAIT_VBLANK, which can either signal your app when a vblank period starts, or wake it up. > 5) Can we implement double-buffering by creating 2 BOs and switching > between them using drmModeAddFB()? It's probably easier to program your flipping from userspace; you shouldn't need to call back into the kernel once you have your buffers allocated. > 6) What is the plan for this modesetting work? Is it intended to replace > fbdev or suplement it? From what I've seen, there's nothing stopping you > creating a DRM driver for very basic framebuffer-only type hardware? Right, you could do that. It's not really meant to *replace* fb, given that fb is so simple, but I expect over time it'll end up having more drivers, since more and more hardware has 3D features that are better suited to supporting with DRM drivers than fb ones... > 7) The modedemo/demo.c seems to be doing stuff with /dev/fb0. From what I > can tell, this is just getting the current mode at startup & restoring it > before exit. Can I assume this is to stop garbled output after the program > exits and can be safely #defined out (as I'm using VGA console)? Not sure about this, I haven't tried the demo. Jakob or alanh could probably answer that though... Jesse ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
