Re: [Linux-fbdev-devel] fbdv/fbcon pending problems

[Geert Uytterhoeven]

On Wed, 25 Feb 2004, Sven Luther wrote:
> On Wed, Feb 25, 2004 at 12:41:25PM +0100, Geert Uytterhoeven wrote:
> > On Tue, 24 Feb 2004, Otto Solares wrote:
> > > On Wed, Feb 25, 2004 at 01:21:39AM +0000, James Simmons wrote:
> > > > > On the other side i see a lot of effort in the fbdev acceleration,
> > > > > it is nice but that effort should be better spent on fixing the layer,
> > > > > imo, the only user for acceleration is fbcon, any userland app that
> > > > > use fbdev disables that acceleration so it can map the vmem and ioregs,
> > > > > and do it's own voodoo if it wants acceleration.  That acceleration
> > > > > is not "exported" to user space.  I am working in a open source project
> > > > > that uses mesa-solo with fbdev and many limitations from the layer
> > > > > itself have been seen.
> > > >
> > > > That is true so far for fillrect and copyarea functions. Imageblit will be
> > > > used for read and writes on /dev/fbX. Also it is used for software
> > > > cursors.
> > >
> > > But if acceleration is not disabled you can't map the vmem and io regions.
> >
> > I don't expect an app that mmap()s mmio to read/write from /dev/fb* at the same
> > time. So I see no problem disabling accelerated read/write while mmio is
> > mapped.
>
> I wonder about X though. It uses mmio for accels (in the non fbdev case
> though) and needs to map the memory area for fallback case, like the non
> supported bressenham lines on permedia 2/3 for example. Altough it is
> possible that the fact that X does its own mapping, and anyway, has very
> little interaction with fbcon and fbdev anyway.

That's mmap(2) of the frame buffer, not read(2)/write(2).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/