--- Alan Cox <[EMAIL PROTECTED]> wrote:
> If they are needed then probably the basic video restore for fb modes
> belongs in the FB driver, and the 3D engine restore in the dri driver.
> That way users get the pieces they need. In time once we have a
> consistent video layer it will tidy up.
Do you really want to teach FB about setting modes on multiple heads? This means
that FB will have to have the memory manager in it too since those display
buffers can change size. All of the logic for merged-fb will have to go into FB
too. FB is doing all of this mode logic and DDC decode in the device driver.
The DRM version I posted I used a different scheme. It provided a minimal I2C
driver for making the DDC data visible to user space via the standard I2C sysfs
API. All of the DDC decode, mode computation, merged-fb stuff is done in the
user space library. At the end of the process a tiny card specific IOCTL is used
to pass the registers values for the mode back to the driver. The exisiting DRM
memory manager is used to allocate the buffer space.
This is over 100K of code I have in user space that would be transfered into
kernel space in the FB model. The code is rarely used and it would be in
non-swapable memory. It would be running in ring 0. My user space library code
can run at user level priv and it's swappable.
=====
Jon Smirl
[EMAIL PROTECTED]
__________________________________
Do you Yahoo!?
Yahoo! Photos: High-quality 4x6 digital prints for 25¢
http://photos.yahoo.com/ph/print_splash
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
