Quoting Jon Smirl ([EMAIL PROTECTED]): > --- Michel D?nzer <[EMAIL PROTECTED]> wrote: > > I don't know the status of the Radeon DRI drivers > > wrt DirectFB (I'm > > curious myself :), but I know that it would likely > > be unstable unless > > the DirectFB driver cooperates and also uses the CP. > > But then that may > > be required for blending and scaling anyway.
My reply to that was: The Radeon DRI driver should work with DirectFBGL, at least without hardware acceleration in DirectFB. There's no need for a DirectFB driver to get a DRI driver working for DirectFBGL. Unfortunately, the Radeon DRI driver in embedded-2-branch has to be changed the way like the Matrox driver did. It's not trivial, but not that difficult, too. DirectFB and DRI drivers are cooperating nearly automatically. The DirectFBGL core acquires the graphics lock of DirectFB before acquiring the lock of DRI and pumping the last DRI state to the hardware. This is typically done before rendering a whole frame. After that both locks are released and the application most probably flips the surface. The DirectFB driver is told to (re)initialize the engine when the next graphics lock is done by DirectFB . > Here's my take on the status of getting Radeon support > for DirectFBGL..... > > Currently: > 1) Mesa Embedded-2 works with DirectFBGL on MGA, > others don't compile. minglx is broken since DRI API > was reworked > 2) Mesa Embedded-1 works on MGA, Radeon, FB - but no > DirectFBGL support. > 3) I have a patch with about 80% of the code from > Embedded-2 that applies and works on Embedded-1 for > the Radeon and R200 drivers. It does everything that > Embedded-2 does except move the allocation of the > framebuffers. miniglx works using the embedded-2 DRI > API. Great. > What needs to be done: > 1) Wait for Keith to merge embedded-1 into trunk. This > is a somewhat messy merge. The messiness of this is > requiring that the Embedded-2 work be redone. > Embedded-2 also broke minglx which is fixed in my > patch. > 2) I need to get the mesa fb driver working in my > patch. > 3) Someone should check out my patch on the MGA since > I don't have one. Should it work on a PCI G450? If so > I'll buy one. I can do so, just tell me what to grab, patch and test ;) > 4) Branch my patch against the trunk after Keith's > merge. My patch removes the Display dependency from > the DRI API like Embedded-2 did. Miniglx has been > adjust for the DRI API change. > 5) Merge in the all of the fixes to the MGA driver > from the Embedded-2 branch to my branch. The fixes to the MGA driver are obsolete after I redid all embedded-2 changes using the DRI trunk instead of the XFree trunk. > 6) Rework buffer allocation in all of the drivers so > that it is coordinated with DirectFB; this is the > other 20% of the Embedded-2 branch. DOK also made > buffers an attribute of a drawable instead of a > screen. That is a big part of implementing pbuffers. > My goal is to get pbuffers working in embedded Mesa. > > > Longer term: > There are three implementations of the DRI API. 1) > XFree (src/dri) 2) Miniglx (src/miniglx) 3) DirectFB > (src/miniglx - embedded-2). My code is attempting to > merge 2 and 3. Further work is needed to reunify all > three. A new version of the DRI API needs to be > designed that is general enough to work in all three cases. That won't be too difficult because 1) is a very limited version of 2) and 3). -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" Convergence GmbH -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe directfb-dev" as subject.
