Re: [PATCH] matroxfb update to new API

Re: [PATCH] matroxfb update to new API

[Petr Vandrovec]

On 27 May 03 at 21:44, Nicolas Souchu wrote:
> On Tue, May 27, 2003 at 07:50:21PM +0200, Petr Vandrovec wrote:
> > Hi,
> >   I just created stripped down version of matroxfb - it is available
> > as diff for 2.5.70 at 
> > ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/mga-stripdown-2.5.70.gz.
> > 
> >   I'll still update my own version of fbdev layer and matroxfb, as
> > this stripped down driver is quite unusable for me.
> >                       Petr Vandrovec
> 
> What do you mean exactly?

What I say... matroxfb driver & fbcon layer which supports fbset, updates
all visible screens, supports text mode, implements clear_margins
as black color and not current background color.

You can download that patch for several months from
ftp://platan.vc.cvut.cz/pub/linux/matrox-latest - current latest is
mga-2.5.69-c1155.gz, it applies to 2.5.70 with one offset. If you
do not have Matrox graphics card in your device, then this patch is
of no use for you.
                                                        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

Re: [PATCH] matroxfb update to new API

[Sven Luther]

On Tue, May 27, 2003 at 09:46:45PM +0200, Petr Vandrovec wrote:
> On 27 May 03 at 21:44, Nicolas Souchu wrote:
> > On Tue, May 27, 2003 at 07:50:21PM +0200, Petr Vandrovec wrote:
> > > Hi,
> > >   I just created stripped down version of matroxfb - it is available
> > > as diff for 2.5.70 at 
> > > ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/mga-stripdown-2.5.70.gz.
> > > 
> > >   I'll still update my own version of fbdev layer and matroxfb, as
> > > this stripped down driver is quite unusable for me.
> > >                       Petr Vandrovec
> > 
> > What do you mean exactly?
> 
> What I say... matroxfb driver & fbcon layer which supports fbset, updates
> all visible screens, supports text mode, implements clear_margins
> as black color and not current background color.
> 
> You can download that patch for several months from
> ftp://platan.vc.cvut.cz/pub/linux/matrox-latest - current latest is
> mga-2.5.69-c1155.gz, it applies to 2.5.70 with one offset. If you
> do not have Matrox graphics card in your device, then this patch is
> of no use for you.

If i have a matrox card and another supported by the new API, will both
work with this latest patch ?

Friendly,

Sven Luther


-------------------------------------------------------
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

Re: [PATCH] matroxfb update to new API

[James Simmons]

Sorry I have been ill for several days. Now I'm finally getting on my 
feet.
 
> 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.

> updates all visible screens, 

???

> 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. 

> 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.




-------------------------------------------------------
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

Re: [PATCH] matroxfb update to new API

[Petr Vandrovec]

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

Re: [PATCH] matroxfb update to new API

[Geert Uytterhoeven]

On Tue, 27 May 2003, Petr Vandrovec wrote:
> On 27 May 03 at 21:53, James Simmons wrote:
> > > 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.

The implementation using the background color is due to the SPARC guys. Suns
boot with a black on white console, and the border is white. Personally I don't
care making it black.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds



-------------------------------------------------------
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

Re: [PATCH] matroxfb update to new API

[Petr Vandrovec]

On 27 May 03 at 21:54, Sven Luther wrote:
> On Tue, May 27, 2003 at 09:46:45PM +0200, Petr Vandrovec wrote:
> > On 27 May 03 at 21:44, Nicolas Souchu wrote:
> > > On Tue, May 27, 2003 at 07:50:21PM +0200, Petr Vandrovec wrote:
> > > > Hi,
> > > >   I just created stripped down version of matroxfb - it is available
> > > > as diff for 2.5.70 at 
> > > > ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/mga-stripdown-2.5.70.gz.
> > > > 
> > > >   I'll still update my own version of fbdev layer and matroxfb, as
> > > > this stripped down driver is quite unusable for me.
> > > >                       Petr Vandrovec
> > > 
> > > What do you mean exactly?
> > 
> > What I say... matroxfb driver & fbcon layer which supports fbset, updates
> > all visible screens, supports text mode, implements clear_margins
> > as black color and not current background color.
> > 
> > You can download that patch for several months from
> > ftp://platan.vc.cvut.cz/pub/linux/matrox-latest - current latest is
> > mga-2.5.69-c1155.gz, it applies to 2.5.70 with one offset. If you
> > do not have Matrox graphics card in your device, then this patch is
> > of no use for you.
> 
> If i have a matrox card and another supported by the new API, will both
> work with this latest patch ?

Unfortunately no. It should work if you'll add dummy 'con' argument
to the fb_ioctl, and dummy struct vc_data* to fb_check_var. Rest of
code should correctly branch according to the value of fbinfo's 
matroxfb_switch_con field, and fbops's fb_{get,set}_cmap, fb_putcs,
set_font and cursor fields (NULL => use cfb_imageblit for putc,
fb_cursor for cursor, and generic code for setfont and cmap).

I never tried to update new vesafb to this interface, as supporting
fbset on /dev/tty* was already vetoed long ago, and I have no problem
with maintaining it outside of tree.
                                            Best regards,
                                                Petr Vandrovec
                                                vandrove@vc.cvut.cz
                                                



-------------------------------------------------------
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

[PATCH] matroxfb update to new API

[Petr Vandrovec]

Hi,
  I just created stripped down version of matroxfb - it is available
as diff for 2.5.70 at 
ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/mga-stripdown-2.5.70.gz.

  I'll still update my own version of fbdev layer and matroxfb, as
this stripped down driver is quite unusable for me.
						Petr Vandrovec

----- Forwarded message from Petr Vandrovec <vandrove@vc.cvut.cz> -----

Date: Tue, 27 May 2003 19:46:31 +0200
From: Petr Vandrovec <vandrove@vc.cvut.cz>
To: torvalds@transmeta.com
Subject: [PATCH] matroxfb update to new API

Hi Linus,
  as it appears that current fbdev layer is not going to disappear,
there is update of matroxfb. I'm sorry that it is quite large, but
due to completely changed underlying API there is no reasonable way 
how to split it into smaller pieces.

(Mis) Features:
Removed support for text mode. No way for it with current API.
Removed support for hardware cursor. Generic cursor code has enough 
	troubles as is, in software mode.
No reasonable fbset support... It is especially annoying on multihead
	system, as 'stty cols XXX rows YYY' does not change pixclock...
Removed fastfont support. No way for it with current API.

(Mis) Features inherited from generic fbdev API:
Cursor on other framebuffers than primary one does not blink.
Contents of visible, but not foreground, display is not updated.

						Thanks,
							Petr Vandrovec

Re: [PATCH] matroxfb update to new API

[Nicolas Souchu]

On Tue, May 27, 2003 at 07:50:21PM +0200, Petr Vandrovec wrote:
> Hi,
>   I just created stripped down version of matroxfb - it is available
> as diff for 2.5.70 at 
> ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/mga-stripdown-2.5.70.gz.
> 
>   I'll still update my own version of fbdev layer and matroxfb, as
> this stripped down driver is quite unusable for me.
> 						Petr Vandrovec

What do you mean exactly?

-- 
Nicholas Souchu - nsouch@free.fr - nsouch@FreeBSD.org


-------------------------------------------------------
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

Re: [PATCH] matroxfb update to new API

[James Simmons]

> (Mis) Features:
> Removed support for text mode. No way for it with current API.

The issue is putc[s]. Th eothers could be done pretty easy. The question 
is do we want to use fbcon for text modes. Fbcon is so big and heavy for
text mode. The /dev/fb interface in this case also doesn't make sense.

> Removed support for hardware cursor. Generic cursor code has enough 
> 	troubles as is, in software mode.

I have patches that explain the new cursor api. Right now I'm recovering 
from being sick so I haven't worked on fixes.

> No reasonable fbset support... It is especially annoying on multihead
> 	system, as 'stty cols XXX rows YYY' does not change pixclock...

Look at fbmon.c. There are functions that can generate reasonable values.
Personally I like to see tha ability to set the pixclock via sysfs.
The truth is that I never had go luck with that functionality. Many 
drivers would freak out when I switched modes.

> Removed fastfont support. No way for it with current API.

Its there but I haven't implemented it yet, struct pixmap. In this case 
struct pixmap would be a static map not a dynamic map as it is currently. 
We can fix that one together.  

> (Mis) Features inherited from generic fbdev API:
> Cursor on other framebuffers than primary one does not blink.

Each framebuffer will need a indepenednt timer. 

> Contents of visible, but not foreground, display is not updated.

Ah the broken console system. Blanking is the same way. When the console 
system blank all VTs blank. I will be working on my VGA/MDA system and 
then all the sudden both console go blank. This will take some magic to do 
without touching the core console code.