Re: [PATCH] matroxfb update to new API
From: Petr Vandrovec <hidden>
Date: 2003-05-27 21:09:29
On 27 May 03 at 21:53, James Simmons wrote:
quoted
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).
quoted
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.
quoted
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.
quoted
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