2003-05-27 17:37:17

by Petr Vandrovec

[permalink] [raw]
Subject: [PATCH] matroxfb update to new API

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 <[email protected]> -----

Date: Tue, 27 May 2003 19:46:31 +0200
From: Petr Vandrovec <[email protected]>
To: [email protected]
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


2003-05-27 22:07:11

by James Simmons

[permalink] [raw]
Subject: Re: [PATCH] matroxfb update to new API


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