Hi Favor, It is my understand that "hooking" is the approach to use when implementing a DFB graphics driver that uses an existing systems driver, however I have never implemented such an approach and cannot comment on it -- at least with any degree of certainty from past experience! :) We developed our own suite of drivers (including the systems driver) and interface plug-ins.
I strongly recommend that you first learn to use the OpenGL ES and EGL APIs in an independent stand-alone program (without the complexities of the DFB framework and core software). Years ago, I found the OpenGL blue (OpenGL Reference Guide, at 3rd edition now?) and red (OpenGL Programming Guide, at 3rd edition now?) book to be very helpful. I also have the OpenGL SuperBible (4th edition) and heard it was good but have not found the need to use it much yet (I does have a good explanation of the various OpenGL ES variants). There are many programming examples on the web and probably some also on the Khronos web site. Then after understanding the OpenGL and EGL programming needs, map them into the DFB framework. If the expected behavior is not occurring, use a debugger (I'm running gdbserver remotely with the SlickEdit as the front-end) to trace through the code to really understand what is going on, use the helpful built-in debugging functionality (instrument you driver code as well!). I have spent many many hours walking through the DFB core software in a debugger to understand how it behaves in targeted areas... and I still have more to learn. Good luck! Timothy -- Timothy Strelchun CE Software Engineering Digital Home Group Intel Corporation The views expressed above are my own and not those of Intel >-----Original Message----- >From: tang...@gmail.com [mailto:tang...@gmail.com] >Sent: Thursday, July 30, 2009 1:31 AM >To: Strelchun, Timothy >Cc: directfb-us...@directfb.org; directfb-dev@directfb.org >Subject: Re: Re: [directfb-dev] problem with writing directfb >gfxdriver for openGL ES > > >Hi, > >To make the back buffer visible, I called eglSwapBuffers like below, >static DFBResult >omapFlipRegion( CoreLayer *layer, >void *driver_data, >void *layer_data, >void *region_data, >CoreSurface *surface, >DFBSurfaceFlipFlags flags) >{ >printf("debug: swaped omapflip region \n"); >if(eglSurface != 0) >{ >eglSwapBuffers(eglDisplay, eglSurface); >printf("%s: swaped buffer \n",__FUNCTION__); >} >return DFB_OK; >} > >DisplayLayerFuncs omapPrimaryLayerFuncs = { >.UpdateRegion = omapUpdateRegion, >.FlipRegion = omapFlipRegion, >}; > >and in driver_init_driver function, I add this line (to let >omapFlipRegion function be called by system): >dfb_layers_hook_primary( device, driver_data, >&omapPrimaryLayerFuncs, NULL, NULL ); > >The Result: I still saw nothing image rendered to screen. >what's wrong with my opengl es driver ? >to use opengl es acceleration, if I need to do some modifies >to core system code in directFB, rather than writing a gfxdriver? >if it is so, how should I do that, what's the main work >related? I don't know much about grahpic driver implementation :( > >thanks in advance. > >On Jul 30, 2009 12:02am, "Strelchun, Timothy" ><timothy.strelc...@intel.com> wrote: >> Since your using an EGL window surface, you will need to >make the back buffer visible by calling eglSwapBuffers. A >systems driver would do this in the >DisplayLayerFuncs::FlipRegion function. Single buffered >display layers do it in the UpdateRegion function, however I >do not believe EGL supports single buffered EGL window surfaces. >> >> Timothy >> >> -- >> >> Timothy Strelchun >> CE Software Engineering >> Digital Home Group >> Intel Corporation >> >> The views expressed above are my own and not those of Intel _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
