Jon Smirl wrote:
Why does __driCreateNewScreen() need the framebuffer parameter? For example in the radeon driver case there is common code that drmMap()'s the framebuffer and builds the framebuffer structure. This structure is then passed to the radeon implementation of __driCreateNewScreen() which never uses it. This causes a map of the framebuffer to be hanging around unused. I'm also forced to build the structure because I can't tell if the driver needs it.
You mean the the __DRIframebuffer pointer? That is used by __driUtilCreateNewScreen.
On the other hand the fb_dri driver needs to know everything about the framebuffer in order to work. But it can get this info by querying the fbdev driver.
Also, how does __driCreateNewScreen() work with RandR? If the mode is changed the framebuffer parameters will change too.
Off the top of my head, I'd have to say that it doesn't. Has any DRI driver ever worked with RandR? :) It has long been assumed that the framebuffer configuration was a static resource, and little thought has been put into what happens if / when that is not the case. Of course, the critical time for doing that thinking is here. :)
Should this info be stored in the driver and then the user space code
can retrieve it if need be instead of passing it in as a parameter?
This is tied into the question of how mode setting is going to work.
The compositing system also complicates this. The primary app is going to want the framebuffer struct for the main display window. But secondary apps are going to want the framebuffer structure for their pbuffer windows.
Right. In a pbuffer type situation, the DRI driver is in complete control of the height / width / stride / etc. of the rendering target. In that scenario, the data in the __DRIframebuffer structure is irrelevant. That will be a happy time. :)
------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
