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?
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf