[PATCH]: rivafb DDC2/I2C

[PATCH]: rivafb DDC2/I2C

[Antonino A. Daplas]

[-- Attachment #1: Type: text/plain, Size: 1541 bytes --]

Hi,

Attached is a patch against linux-2.6.1 + fbdev.diff. (It's another big
patch so it's zipped).

1. fbmon.c
- expanded struct fb_monspecs to include almost information parsed from
the EDID block, including a pointer to a mode database, manufacture,
model, monitor name, serial number, etc.

- as suggested by Ben H., the contents of the EDID block can be
transferred in one go into struct fb_monspecs with the function
fb_edid_to_monspecs(unsigned char *, struct fb_monspecs *)

- show_edid() is depreciated.  For verbose edid output, just define DEBUG
in fbmon.c and call fb_edid_to_monspecs().

2. modedb.c
- removed __init for fb_find_mode().
- added extra field (flag) to struct fb_videomode.  As I explained in my
previous mail, this field should tell the source of each entry (vesa,
detailed, etc)

3. fbcon.c and softcursor.c
The cursor is corrupted whether with softcursor or hardware cursor :-(  I
tried to make some changes without greatly affecting the logic of the
cursor framework, but the changes will probably break some drivers with
hardware cursors.

The logic behind the change is:

In fbcon_cursor(), info->image.mask (mask) is just a bitmap of
(fontwidth)x(fontheight) dimensions which is filled with 1's.
info->cursor.image.data (image) is an "xor" of the bitmap of the current
character and a bitmap of the current cursor.

The final image (in softcursor.c) is then produced by doing *image++ &
*mask++.

3.  RIVAFB:

- added DDC/I2C support
- fixed cursor bugs
- fixed accel bugs

Any comments welcome.

Tony






[-- Attachment #2: fb-linux-2.6.1.diff.gz --]
[-- Type: application/x-gzip, Size: 20031 bytes --]

Re: [PATCH]: rivafb DDC2/I2C

[Benjamin Herrenschmidt]

On Tue, 2004-01-13 at 01:59, Antonino A. Daplas wrote:
> Hi,
> 
> Attached is a patch against linux-2.6.1 + fbdev.diff. (It's another big
> patch so it's zipped).
>

Sounds nice (according to your description at least :)

I won't have time to try it on my side much during this week
(linuxconf.au), nor to adapt radeonfb to the changes at least
until I'm back.

James: Are you still around ? Got my previous set of patches ?

I think it's time to start feeding Andrew (though I'd rather
add the FB_ACTIVATE_FIND first, but that can always get in later
if we really want it).

Note that I reproduced cases of console resize via stty blowing
up in accel_clear_margins on an x86, I think that's unrelated to
the changes I did though, but I haven't figured out what's going
on exactly yet. It blows up after the resize, apparently in a
call to fbcon_switch()...

Ben.




-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html

Re: [PATCH]: rivafb DDC2/I2C

[James Simmons]

> James: Are you still around ? Got my previous set of patches ?

Yes. I applied your pixmap locking fix. Its in the BK tree. This weekend I 
setup most of my machines. I have my sparc/ix86 and indy running and 
ready for testing :-) I also pulled out my few dozen video cards. 

> I think it's time to start feeding Andrew (though I'd rather
> add the FB_ACTIVATE_FIND first, but that can always get in later
> if we really want it).
> 
> Note that I reproduced cases of console resize via stty blowing
> up in accel_clear_margins on an x86, I think that's unrelated to
> the changes I did though, but I haven't figured out what's going
> on exactly yet. It blows up after the resize, apparently in a
> call to fbcon_switch()...

Strange. Is this a specific driver issue or in general. I think it should 
be okay otherwise. Will test in the next few days a few different cards.



> 
> Ben.
> 
> 
> 



-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html

Re: [PATCH]: rivafb DDC2/I2C

[Antonino A. Daplas]

On Tue, 2004-01-13 at 01:38, Kronos wrote:
>
>                         *mode = vesa_modes[i];
> -                       return 1;
> +                       mode->flag |= MODE_IS_STANDARD;
> +                       break;
> +               } else {
> +                       calc_mode_timings(xres, yres, refresh, mode);
> +                       mode->flag = MODE_IS_STANDARD | MODE_IS_CALCULATED;
> +                       break;
>                 }
>         }
> 
> This won't work. It will exit after the first iteration in any case. You
> reintroduced the same bug you spotted some time ago ;)

Thanks :-).  Fixed.

> Also, I see that you introduced fb_sqrt, we already have int_sqrt (see
> lib/int_sqrt.c). If the only issue was the return value you can change
> fb_sqrt to:
> 
> static inline u32 fb_sqrt(int x) {
>         return (u32)int_sqrt(x);
> }
> 

No issue.  Fixed.

>  
> > 2. modedb.c
> > - removed __init for fb_find_mode().
> 
> You have to change the prototype in fb.h. fb_find_mode was implemented
> in a different way if MODULE was defined.

Ok.

> 
> And if we are keeping modedb (~2.7KB) after initialization we should
> merge it with vesa_modes (we still have MODE_IS_VESA flag) and remove 
> duplicates.
> 

Possibly.  Will be on my TODO.

Tony






-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html