On Friday 07 March 2008 18:35:10 Jesse Barnes wrote: > On Friday, March 07, 2008 1:21 am Tom Cooksey wrote: > > I'm a developer working on getting OpenGL ES working with QWS - the window > > system built into Qt/Embedded. That is, Trolltech's own windowing system, > > completely independent of X. The typical hardware we're working with is > > PowerVR MBX, an OpenGL ES 1.1 complient device. We have also played with > > ATI mobile chipsets. One thing all these devices have in common is rubbish > > (IMO), closed source drivers. The only API we have for them is EGL, the > > only on-screen surface is the entire display. > > > > While we are continuing development with these devices, I'm very keen to > > develop a proof-of-concept driver using an open source desktop OpenGL > > implementation. I want to show people what can be done with decent (& open) > > drivers. > > Great, that's one of the goals we had in mind when changing the DRM recently. > > There's actually some standalone OpenGL code in the Mesa tree that can be > used as a starting point (EGL & miniglx, two separate ways of doing that). > > > The first step I'd like to make is to just get something on the screen. I > > was wondering if it's possible to use DRM to just map the framebuffer into > > a user process's address space and use it like we would use the LinuxFB > > device? Or do modern frame buffer drivers use the DRM themselves to do > > this? > > Yeah, that should be doable with the current code on Intel & ATI devices. > You'll have to allocate a new buffer object for your front buffer, then use > it to set a new mode. > > We'd really like to hear any feedback you have about the interfaces and > design; given that what you're doing is something we'd really like to > support, we want to make sure we get it right before it gets pushed upstream > into Linux and set in stone.
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. :-/ 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? 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. 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. 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? 5) Can we implement double-buffering by creating 2 BOs and switching between them using drmModeAddFB()? 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? 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)? Cheers, Tom ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
