Re: [PATCH] gma500: gtt based hardware scrolling console

Hi Alan,

On Thu, Sep 22, 2011 at 20:43, Alan Cox [off-list ref] wrote:

diff --git a/drivers/staging/gma500/framebuffer.c

b/drivers/staging/gma500/framebuffer.c
index 7748331..3f39a37 100644

--- a/drivers/staging/gma500/framebuffer.c
+++ b/drivers/staging/gma500/framebuffer.c

Do you really want to set this? I didn't see any other wrapping
support in your patch.
However, I guess you can implement wrapping support using the same
mapping trick?

+       info->fix.ypanstep = gtt_roll;

       if (backing->stolen) {
               /* Accessed stolen memory directly */

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

quoted

+       info->fix.ywrapstep = gtt_roll;

Do you really want to set this? I didn't see any other wrapping
support in your patch.
However, I guess you can implement wrapping support using the same
mapping trick?

It is actually wrapping - it writes the low pages back below the high
ones so it works the GTT as a circular buffer - or am I misunderstanding
this.

One thing I wasn't sure of on the fb side. If I've got a display width
that is annoying and can't fit on a 4Kbyte stride am I right in thinking
I can set this to say 8 and use a 512 byte stride and still get
acceleration for the usual font choice ?

Alan

On Thu, Sep 22, 2011 at 22:21, Alan Cox [off-list ref] wrote:

quoted

quoted

+       info->fix.ywrapstep = gtt_roll;

Do you really want to set this? I didn't see any other wrapping
support in your patch.
However, I guess you can implement wrapping support using the same
mapping trick?

It is actually wrapping - it writes the low pages back below the high
ones so it works the GTT as a circular buffer - or am I misunderstanding
this.

Then it should not set ypanstep to a non-zero value, and set/handle the other
various *YWRAP flags, to communicate with the frame buffer console driver.

Panning is moving inside a virtual screen bigger than the visible screen size.

One thing I wasn't sure of on the fb side. If I've got a display width
that is annoying and can't fit on a 4Kbyte stride am I right in thinking
I can set this to say 8 and use a 512 byte stride and still get
acceleration for the usual font choice ?

Yep, that should work. The console code can use ywrap resp. ypan if the
font height is a multiple of ywrapstep resp. ypanstep.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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