Menu
▾
▴
linux-fbdev-devel
|
From: James S. <jsi...@in...> - 2002-12-26 19:49:00
|
> 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? |
|
From: Petr V. <van...@vc...> - 2002-12-27 02:41:23
|
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 van...@vc... |
|
From: Geert U. <ge...@li...> - 2002-12-27 11:07:55
|
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 -- ge...@li...
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
|
|
From: Petr V. <van...@vc...> - 2002-12-27 23:01:32
|
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 van...@vc... |
|
From: Geert U. <ge...@li...> - 2002-12-27 23:20:57
|
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 -- ge...@li...
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
|
Thanks for helping keep SourceForge clean.
X