|
From: Geert U. <ge...@li...> - 2003-03-02 12:17:48
|
On Thu, 27 Feb 2003, James Simmons wrote:
> > On Don, 2003-02-27 at 15:15, Antonino Daplas wrote:
> > > On Thu, 2003-02-27 at 09:18, James Simmons wrote:
> > >
> > > > > Thus, the restriction that the buffer must be completely copied by the
> > > > > driver before returning. And because of this restriction, an extra copy
> > > > > which might be unnecessary cannot be avoided (this was noted by Petr).
> > > > >
> > > > > Treating the buffer as a ringbuffer, we eliminate these restrictions.
> > > >
> > > > I didn't realize that the below was a ringbuffer implementation. The name
> > > > threw me off.
> > >
> > > Well, it's not strictly a ringbuffer implementation. This would require
> > > a head and tail pointer where fbcon will adjust the tail and the
> > > driver/hardware will adjust the head. This will be very difficult to
> > > implement in a device independent manner. So we just cheat by issuing
> > > an fb_sync() per loop to flush all pending commands.
> >
> > That still seems suboptimal though. What the DRM often does is have the
> > chip write an age value to a scratch register when it's done processing
> > something. Maybe something like that could be used to avoid waiting for
> > the chip to go idle at all?
>
> Don't waste your time. I'm removing all the changes that have been done
> since 2.5.51. After that I will no longer be co-maintainter of the
> framebuffer layer.
Are you sure about that?!?!?
What about adding a pointer to a
struct con_ops {
set_font();
putc();
putcs();
}
to struct fb_info as an interim solution, until tile blitting has matured? That
would make Petr (matroxfb) and Davem (sbusfb) happy?
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
|