Re: [PATCH] matroxfb update to new API

["Petr Vandrovec" <VANDROVE@vc.cvut.cz>]

On 27 May 03 at 21:53, James Simmons wrote:
> > What I say... matroxfb driver & fbcon layer which supports fbset,
> 
> The mode changing only worked on a select few cards before. What we need 
> is better DDC support and start working on fbmon.c. The functions are all 
> there to support this stuff.

I'd like to see how you'll resolve my config. One CRTC drives analog
21" EIZO F764-M with no DDC at all, secondary CRTC drives 17" DFP 
1280x1024 from fujitsu, but due to some hardware strangeness both
CRTCs have to use same pixel clocks... (1024x768@100Hz on first head,
1280x1024@60Hz on DFP).
 
> > updates all visible screens, 
> 
> ???

When I switch to secondary head with stripped down matroxfb & your
fbcon, program printing something on first head stops updating screen.
Only after I switch back to the primary head picture updates. It is not
major problem as I usually run 'fbtv -k' on the background head,
but... it should work. There was problem with info->display_fg
not being properly updated when VT is moved from one fb to another
and there is only one VT on the fbdev, but I'm not sure that it is still 
root of the problem.

> > supports text mode, 
> 
> Fbcon is over kill for text hardware mode. The best approach is what the 
> STI driver does. A core set of functions shared between text mode and 
> graphics mode. 

Maybe. For now I have something integrated with kernel's fbdev, so
people will stop complaining... As only thing I need from text mode is
special hardware state, as VMware, svgalib and dosemu will all take over
hardware anyway, maybe I can just implement vga 4bpp instead of text mode -
- hardware state is same, but it will match better with pixel based core.

> > implements clear_margins as black color and not current background 
> > color.
> 
> It would look bad if the margin where a different color from the screen 
> when it was cleared.

Nope. Try running midnight commander. You'll end with cyan (or red or..
just random, depending on what was mc doing when scrolling happened) 
line at the right and bottom of screen. Do not forget that rectangle around 
the picture is always black (even on DFPs there is about 1mm margin between 
first pixel and edge), so it seems natural to me that margin should be 
always black. Besides that I received two complaints in 16hrs after I
switched matroxfb from driver's black clear margin to the generic 
implementation using background color.
                                                Petr Vandrovec
                                                



-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge