Status for my work.

Status for my work.

[James Simmons]

Hi!
	I have been busy with some new patches. Hold off on the cfb_imageblit
    patch. I'm working on a better one. Of the things I discovered is that not
    all graphics hardware can do 32 bit writes to the framebuffer. For example
    the Epson135X chipsets have this problem. Only 16 bit writes/reads. So I
    have been working on making cfb_imageblit be able to do 8/16/32 writes/reads
    to the framebuffer. So far I have managed to get the color image working
    for most conditions. Unfortunely it doesn't work for the case where the pixel
    is larger than the allowed write/read.
        The second issue I have been pondering is what to do exactly with
    struct fb_pixmap. Its not really clear what its totally functionality
    could be to alot of people. Originally it was designed to deal with
    padding scan lines of images to and/or padding image data at the end so 
    hardware accel engines could handle the data directly inside the hardware
    drivers acceleration functions.
    	Now I have been viewing it as a layer just above the lowest level of 
    access. It still would do the above functions plus more. I'm purposing
    creating a list of struct pixmap's for struct fb_info. Right now we have
    pixmap and sprite. No one at the present uses sprite. So instead we have 
    the link list instead. We would create the default one which is the 
    scratch pad for fb_con. It could be used else where as well. I also like to
    create a second one for the framebuffer itself. Doing this we could:

	1. Move screen_base and screen_size into struct fb_pixmap.
	2. Get ride of the fb_writes and fb_reads with inbuf, outbuf.

    So what do you think?

	The other thing I have been working on is real sysfs support. So far I 
    brought it back and made it functional. You can also get the name of the device
    also which can replace /proc/fb. I have been attempting to figure out how to
    handle the mode database. How should it be displayed in the tree?
    


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: Status for my work.

[Jon Smirl]

On Sat, 5 Feb 2005 01:03:40 +0000 (GMT), James Simmons
<jsimmons@www.infradead.org> wrote:
>         The other thing I have been working on is real sysfs support. So far I
>     brought it back and made it functional. You can also get the name of the device
>     also which can replace /proc/fb. I have been attempting to figure out how to
>     handle the mode database. How should it be displayed in the tree?

I have coded up various tries at the modefb problem. My best solution
was to have pairs of variables like graphics/fb0/modes and
graphics/fb0/mode. modes is a list of legal modes and can only be set
by root but read by everyone. I pulled all of the code for querying
DDC, building the modedb, matching, etc out of fbdev and moved it to a
user space app triggered by hotplug or manually on a monitor switch.
This app queries the DDC and then builds a list of fb_mode structures
which it sets to graphics/fb0/modes. Since it is user space it is easy
to add modes to this list from an etc/fb.modes file. The fb driver
then remembers this list of modes.

If you "cat graphics/fb0/modes" you see a list of things like
1024x768-60, 1024x768-70, etc generated from the list of fb_modes. Set
one of these strings back to graphics/fb0/mode and you change the
mode. By allowing owner writes of fb0/mode and using pan to assign
ownership, it is now safe for the user to set any mode they want
without needing root priv. Setting modes without root priv is a major
requirement for X on GL support. cat graphics/fb0/mode and you can see
the current mode.

This scheme does disallow a user from setting a custom mode. The user
is limited to the modes that have been set into graphics/fb0/modes. If
you want a custom mode, add it to etc/fb.modes and rerun the hotplug
command as root to add it to the list. On the other hand, this stops
malicious users from setting modes that will destory the monitor.

A parallel scheme can be used for things like bits per pixel, but in
this case the bpps attribute would be static. After setting bpp the
mode list would be scanned to disable entries that exceed hardware
bandwidth.

The fb_info variable also needs to be evaluated. I would like to see
it split into a base fb_info with multiple fb_head structures. Now a
days most cards have two heads and some like Matrox have three.
Duplicating fb_info as is causes info that is global per card to be
duplicated. So if you set a global value into one fb_info it will be
out of sync with the other ones. Splitting into fb_info/fb_head would
also make things match what DRM is doing internally.

X on GL definitely needs per head mode control. Part of why there is
the DRM/fbdev split is lack of mode setting for the secondary heads.

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl