Hi all, I've been trying to follow this mailing list as to the current state of DRM, especially modesetting. My goal is to get Qt-Embedded to use moden graphics drivers rather than the fbdev interface we have today. A few months ago I played with the drm modesetting-101 branch with the intel driver to see if I could at least map a frame buffer into the server process and use our software renderer to render into it. I eventually managed to get the modesetting test app to work, but other things pulled me away from the work. I now want to resume what I started, but it seems everything has got a whole lot more complicated.
So my question is this: Are things API-stable enough to start playing again, or should I wait another few months until the GEM vs TTM stuff has been resolved? If the API is stable, how can I start playing again? All I want to do at this stage is map the framebuffer and render into it. I will then have the equivilant to what we have already with fbdev. Later (probably much later) I want to modify the Gallium winsys layer so I can use gl to render into the framebuffer. Then comes multiple processes, then retirement. For now I guess all I need is a vanilla kernel and a drm build, but which branch of drm should I use? modesetting-101 or modesetting-gem? I notice the gem branch has a test (gem_mmap.c) which seems to create & map a hunk of memory, but I guess this is just a i915 test as all the ioctls are i915-specific. Unless the idea of a generic interface is dead? Cheers, Tom PS: I have a GM965 based laptop I want to use for experimentation - but can get hold of something else if it's going to help? ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
