This is a patch to downgrade the framebuffer files in linux-2.5.53 back
to 2.5.50, where the matrox-framebuffer worked perfectly.
It's rather annoying that in a feature-freeze period a change goes in
that cripples the one framebuffer with the best speed and features -
the matrox framebuffer. The author mentioned it could be weeks or months
before he would be able to get his matrox framebuffer working with the
new framework, since its simple API doesn't fit the possibilities of the
matrox framebuffer. Read more about it on the fbdev-users or
fbdev-developers mailinglist on sourceforge.
He advised people to stay at 2.5.50, or copy some files from
drivers/video etc. from 2.5.50 into 2.5.53.
That's what I did, some small changes were also necessary.
This patch has _no_ support. Don't tell me devfs stopped working, don't
tell me multiple-head output doesn't work, don't ask me to update it to
a newer kernel-version.
All I know is:
- it works here, on a smp X86 system with a G400 & preempt on.
- switching to XFree and back works.
- switching consoles works.
That's enough for me.
The patch is at
http://www.xs4all.nl/~thunder7/matroxfb_2553.diff.bz2
Good luck,
Jurriaan
--
When asked by an anthropologist what the Indians called America
before the white men came, an Indian said simply "Ours."
Vine Deloria, Jr.
GNU/Linux 2.5.50 SMP/ReiserFS 2x2752 bogomips load av: 1.85 2.21 1.38
On Thu, 26 Dec 2002 15:20:32 +0100
Jurriaan <[email protected]> wrote:
> This is a patch to downgrade the framebuffer files in linux-2.5.53 back
> to 2.5.50, where the matrox-framebuffer worked perfectly.
Would be nice if the radeonfb worked too. Is this driver ever going to be fixed
in 2.5?
Paulo Andre'
> It's rather annoying that in a feature-freeze period a change goes in
> that cripples the one framebuffer with the best speed and features -
> the matrox framebuffer.
Because a driver has over 10,000 lines of code does not mean it is a
quality driver.
> The author mentioned it could be weeks or months
> before he would be able to get his matrox framebuffer working with the
> new framework, since its simple API doesn't fit the possibilities of the
> matrox framebuffer. Read more about it on the fbdev-users or
> fbdev-developers mailinglist on sourceforge.
Petr is expressing his political view. It has nothing to do with technical
arguments. In fact I place a bet. I will port the matrox driver and it
will have the same functionality as the previous driver except for text
mode support. If I can't do it I will not only revert the changes but I
will give Petr his wetdream. I will start inetergrating vt.c and
vt_ioctl.c into each fbdev driver. Each fbdev driver will be its own
console system. We will not longer need vt.c and vt_ioctl.c as each driver
will have its own version intergated into the driver. Sound fair?
On Thu, Dec 26, 2002 at 07:47:52PM +0000, James Simmons wrote:
>
> > It's rather annoying that in a feature-freeze period a change goes in
> > that cripples the one framebuffer with the best speed and features -
> > the matrox framebuffer.
>
> Because a driver has over 10,000 lines of code does not mean it is a
> quality driver.
I do not say that driver is perfect. But at least it worked... on wide variety
of architectures.
> > The author mentioned it could be weeks or months
> > before he would be able to get his matrox framebuffer working with the
> > new framework, since its simple API doesn't fit the possibilities of the
> > matrox framebuffer. Read more about it on the fbdev-users or
> > fbdev-developers mailinglist on sourceforge.
>
> Petr is expressing his political view. It has nothing to do with technical
> arguments. In fact I place a bet. I will port the matrox driver and it
> will have the same functionality as the previous driver except for text
> mode support. If I can't do it I will not only revert the changes but I
Yes. Without text mode support. But without textmode support that driver is
of no use for me because of it is not compatible with VMware then.
You know that I'm not forcing my view to anybody. I just wrote matroxfb to
fullfill my needs, and that's everything.
> will give Petr his wetdream. I will start inetergrating vt.c and
> vt_ioctl.c into each fbdev driver. Each fbdev driver will be its own
> console system. We will not longer need vt.c and vt_ioctl.c as each driver
> will have its own version intergated into the driver. Sound fair?
I do not need that. I just need API which will allow at least same functionality
which old API offered. Nothing more, and of course, nothing less. For now
I just added putc/putcs into the fbops, and matroxfb uses its own while
other drivers can use default accel_putc(s) directly. Of course uploading
font data to the hardware will need more hooks... Another interesting question
is how can I have different resolutions on different virtual terminals...
An 640x16 bitmap is of no use for me if I just want to put 80 characters
on text terminal. Or if I want to tell to the accelerator what character it
should retrieve from its onboard font cache...
Petr Vandrovec
[email protected]
On Thu, Dec 26, 2002 at 07:15:10PM +0000, Paulo Andre' wrote:
> On Thu, 26 Dec 2002 15:20:32 +0100
> Jurriaan <[email protected]> wrote:
>
> > This is a patch to downgrade the framebuffer files in linux-2.5.53 back
> > to 2.5.50, where the matrox-framebuffer worked perfectly.
>
> Would be nice if the radeonfb worked too. Is this driver ever going to be fixed
> in 2.5?
With Jurriaan's hack ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/radeon.tgz
should work - it is 2.4.18 version of driver ported to 2.5.50. Only thing I can
say about it is that it works on my Compaq notebook in 1600x1200, with
2.5.51-bkSomething.
I did not talked to Ani Joshi about it yet, as it does not work in latest 2.5.x
kernels, so as is patch is of no use for anyone using 2.5.52+.
Petr Vandrovec
[email protected]
On Fri, 27 Dec 2002, Petr Vandrovec wrote:
> On Thu, Dec 26, 2002 at 07:47:52PM +0000, James Simmons wrote:
> > Petr is expressing his political view. It has nothing to do with technical
> > arguments. In fact I place a bet. I will port the matrox driver and it
> > will have the same functionality as the previous driver except for text
> > mode support. If I can't do it I will not only revert the changes but I
>
> Yes. Without text mode support. But without textmode support that driver is
> of no use for me because of it is not compatible with VMware then.
What exactly in the new fbdev API is preventing you from having text mode
support?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
Jurriaan wrote:
> The patch is at
> http://www.xs4all.nl/~thunder7/matroxfb_2553.diff.bz2
Thanks! Your updated diff works for me too. Mathijs' timer
warning fix applies to it too:
http://marc.theaimsgroup.com/?l=linux-fbdev-devel&m=103875174429829&w=2
Petr's matroxfb is truely an amazing programming feat.
I use a 3 year old G400 instead of a newer nVidia card
with more memory on my main box because of matroxfb's
vast superiority in text mode.
http://home.earthlink.net/~rwhron/hardware/matrox.html
--
Randy Hron
http://home.earthlink.net/~rwhron/kernel/bigbox.html
Linux rushmore 2.5.53-mm1 #1 Fri Dec 27 08:41:11 EST 2002 i686
On Fri, Dec 27, 2002 at 12:05:38PM +0100, Geert Uytterhoeven wrote:
> On Fri, 27 Dec 2002, Petr Vandrovec wrote:
> > On Thu, Dec 26, 2002 at 07:47:52PM +0000, James Simmons wrote:
> > > Petr is expressing his political view. It has nothing to do with technical
> > > arguments. In fact I place a bet. I will port the matrox driver and it
> > > will have the same functionality as the previous driver except for text
> > > mode support. If I can't do it I will not only revert the changes but I
> >
> > Yes. Without text mode support. But without textmode support that driver is
> > of no use for me because of it is not compatible with VMware then.
>
> What exactly in the new fbdev API is preventing you from having text mode
> support?
Problem is that in new framework driver does not get in touch with characters.
It gets only prepared bitmap passed to imageblit callback (because of fbcon_putcs
unconditionally calls accel_putcs, which does character -> bitmap conversion). Of
course it is possible to convert bitmap back to character number, but it is very
time consuming, and it looks illogical to me first convert character number to its
graphic image, and then convert graphic image back to character number... Not even
talking about 9x16 character cell.
Next problem is that fbdev driver is no more notified (if I understand code correctly)
about font changes, so it even cannot upload correct font into the hardware, and
so it must rely on accel_putcs at the time of character print.
If nothing else, VMware can be happy with just black screen in text mode, it will
paint proper characters directly...
Much worse problem is that I do not see any way how to have different resolutions
on different virtual terminals, and I do not know how to work around this.
Best regards,
Petr Vandrovec
[email protected]
On Fri, 27 Dec 2002, Petr Vandrovec wrote:
> On Fri, Dec 27, 2002 at 12:05:38PM +0100, Geert Uytterhoeven wrote:
> > On Fri, 27 Dec 2002, Petr Vandrovec wrote:
> > > On Thu, Dec 26, 2002 at 07:47:52PM +0000, James Simmons wrote:
> > > > Petr is expressing his political view. It has nothing to do with technical
> > > > arguments. In fact I place a bet. I will port the matrox driver and it
> > > > will have the same functionality as the previous driver except for text
> > > > mode support. If I can't do it I will not only revert the changes but I
> > >
> > > Yes. Without text mode support. But without textmode support that driver is
> > > of no use for me because of it is not compatible with VMware then.
> >
> > What exactly in the new fbdev API is preventing you from having text mode
> > support?
>
> Problem is that in new framework driver does not get in touch with characters.
Oops, I forgot about that...
> It gets only prepared bitmap passed to imageblit callback (because of fbcon_putcs
> unconditionally calls accel_putcs, which does character -> bitmap conversion). Of
> course it is possible to convert bitmap back to character number, but it is very
> time consuming, and it looks illogical to me first convert character number to its
> graphic image, and then convert graphic image back to character number... Not even
> talking about 9x16 character cell.
>
> Next problem is that fbdev driver is no more notified (if I understand code correctly)
> about font changes, so it even cannot upload correct font into the hardware, and
> so it must rely on accel_putcs at the time of character print.
So we need to find a way to provide putcs() and font operations by a fbdev,
without sucking in the whole fbcon layer.
Basically you need putcs(), which is really just a simple way to do multiple
image blits in one call, and set_font(), right? And if the fbdev doesn't
provide those, we must fallback to accel_putcs().
James (and Petr, of course), what do you think? And I guess this will make
Davem happy as well.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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