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.
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.
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.
=====
Jon Smirl
[EMAIL PROTECTED]
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail
-------------------------------------------------------
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
