scroll modes

scroll modes

[Knut Petersen]

Hi everybody,

Is there a patch for "true ywrap" scrolling?

Lets have a look at a mode xres=vxres=1024, yres=768, depth=32. As there
is 8 Mb of available memory, we can use a vyres of 2048. With an 8x16 font
this gives exactly 128 lines of text in virtual memory, 48 lines are 
displayed.

Current code stops to ypan at text line 80, moves image data to the 
beginning of the
video memory and continues. The frequent calls to copyarea are a major 
cause of
slowing down at high image depths.

Optimal scrolling for the cyberblade would mean nothing but to emit new 
lines
with hwaccel imageblit up to the very end of video memory and to ypan 
accordingly.
There is no need for moving data around in video memory or to redraw the 
screen
as the cyberblade hardware handles wrapping at the end of the video 
memory perfectly
fine.

cu,
 knut


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: scroll modes

[Geert Uytterhoeven]

On Wed, 30 Nov 2005, Knut Petersen wrote:
> Is there a patch for "true ywrap" scrolling?

Is there a need for a patch (except for a patch to cyblafb)?

> There is no need for moving data around in video memory or to redraw the
> screen
> as the cyberblade hardware handles wrapping at the end of the video memory
> perfectly
> fine.

Ywrap has been working fine with amifb since ages (unless someone broke it very
recently).

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


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: scroll modes

[Knut Petersen]

Geert Uytterhoeven wrote:

>Ywrap has been working fine with amifb since ages (unless someone broke it very
>recently).
>
>  
>
We are talking about scrollmode = SCROLL_WRAP_MOVE ?
I put printk()s in the imageblit(), copyarea() and pan_display() 
functions of
cyblafb and in updatescrollmode() of fbcon.c. A "cat somefile" after loading
cyblafb produces the following log, you can see that the vyres == 2048 
and that
the maximum yoffset passed to pan_display() is 2048-768==1280. To call
that mode SCROLL_WRAP_SOMETHING the maximum yoffset should be
2048-16==2032. In reality it seems to be some kind of SCROLL_BROKEN_PAN ;-)


[43673.343266] cyblafb: CyblaFB version 0.56 initializing
[43673.345864] cyblafb: Pixmap size = 8188, alignement = 1
[43673.348147] ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [LNKA] -> GSI 
11 (level, low) -> IRQ 11
[43673.351810] cyblafb: region 0x3c0/0x20 already reserved
[43673.353941] cyblafb: framebuffer size = 8192 Kb
[43673.356006] cyblafb: region 0xe1800000/0x800000 already reserved
[43673.358274] cyblafb: detected startup mode: fbset -g 1024 768 1024 
??? 32 -t 15389 160 24 29 3 136 6
[43673.366685] cyblafb: Switching to new mode: fbset -g 1024 768 1024 
2048 32 -t 15389 160 24 29 3 136 6
[43673.368795] cyblafb: pixclock = 129.96 MHz, k/m/n 0 b 6e
[43673.368858] Scrollmode = SCROLL_WRAP_MOVE

[...]

[43674.319558] cyblafb: panning to xoffset 0, yoffset 1200
[43674.319836] cyblafb: blit to 0 / 1952, w/h 1024 / 16
[43674.319997] cyblafb: panning to xoffset 0, yoffset 1216
[43674.320260] cyblafb: blit to 0 / 1968, w/h 1024 / 16
[43674.320423] cyblafb: panning to xoffset 0, yoffset 1232
[43674.320710] cyblafb: blit to 0 / 1984, w/h 1024 / 16
[43674.320881] cyblafb: panning to xoffset 0, yoffset 1248
[43674.321147] cyblafb: blit to 0 / 2000, w/h 1024 / 16
[43674.321307] cyblafb: panning to xoffset 0, yoffset 1264
[43674.321582] cyblafb: blit to 0 / 2016, w/h 1024 / 16
[43674.321769] cyblafb: panning to xoffset 0, yoffset 1280
[43674.322050] cyblafb: blit to 0 / 2032, w/h 1024 / 16
[43674.322471] cyblafb: blit to 0 / 0, w/h 1024 / 16
[43674.322902] cyblafb: blit to 0 / 16, w/h 1024 / 16
[43674.344359] cyblafb: blit to 8 / 32, w/h 1016 / 16
[43674.346218] cyblafb: blit to 0 / 48, w/h 1024 / 16
[43674.348017] cyblafb: blit to 0 / 64, w/h 1024 / 16
[43674.349780] cyblafb: blit to 0 / 80, w/h 1024 / 16
[43674.351794] cyblafb: blit to 0 / 96, w/h 1024 / 16
[43674.353558] cyblafb: blit to 0 / 112, w/h 1024 / 16

[...]

[43674.647018] cyblafb: blit to 0 / 1984, w/h 1024 / 16
[43674.647184] cyblafb: panning to xoffset 0, yoffset 1248
[43674.647472] cyblafb: blit to 0 / 2000, w/h 1024 / 16
[43674.647646] cyblafb: panning to xoffset 0, yoffset 1264
[43674.647918] cyblafb: blit to 0 / 2016, w/h 1024 / 16
[43674.648085] cyblafb: panning to xoffset 0, yoffset 1280
[43674.648351] cyblafb: blit to 0 / 2032, w/h 1024 / 16
[43674.648767] cyblafb: blit to 0 / 0, w/h 1024 / 16
[43674.649068] cyblafb: blit to 0 / 16, w/h 16 / 16
[43674.668394] cyblafb: blit to 16 / 16, w/h 1008 / 16
[43674.670569] cyblafb: blit to 0 / 32, w/h 1024 / 16
[43674.672304] cyblafb: blit to 0 / 48, w/h 1024 / 16

cu,
 knut


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: scroll modes

[Antonino A. Daplas]

Knut Petersen wrote:
> Geert Uytterhoeven wrote:
> 
>> Ywrap has been working fine with amifb since ages (unless someone
>> broke it very
>> recently).
>>
>>  
>>
> We are talking about scrollmode = SCROLL_WRAP_MOVE ?

Try this patch.

Tony

diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index 1a8f0ea..5ebe68f 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -1972,12 +1972,6 @@ static __inline__ void updatescrollmode(
 	int fast_imageblit = (cap & FBINFO_HWACCEL_IMAGEBLIT) &&
 		!(cap & FBINFO_HWACCEL_DISABLED);
 
-	p->vrows = vyres/fh;
-	if (yres > (fh * (vc->vc_rows + 1)))
-		p->vrows -= (yres - (fh * vc->vc_rows)) / fh;
-	if ((yres % fh) && (vyres % fh < yres % fh))
-		p->vrows--;
-
 	if (good_wrap || good_pan) {
 		if (reading_fast || fast_copyarea)
 			p->scrollmode = good_wrap ?
@@ -1991,6 +1985,16 @@ static __inline__ void updatescrollmode(
 		else
 			p->scrollmode = SCROLL_REDRAW;
 	}
+
+	p->vrows = vyres/fh;
+
+	if (p->scrollmode != SCROLL_WRAP_MOVE &&
+	    (yres > (fh * (vc->vc_rows + 1))))
+		    p->vrows -= (yres - (fh * vc->vc_rows)) / fh;
+
+	if ((yres % fh) && (vyres % fh < yres % fh))
+		p->vrows--;
+
 }
 
 static int fbcon_resize(struct vc_data *vc, unsigned int width, 


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: scroll modes

[Knut Petersen]

Antonino A. Daplas schrieb:

>Knut Petersen wrote:
>  
>
>>Geert Uytterhoeven wrote:
>>
>>    
>>
>>>Ywrap has been working fine with amifb since ages (unless someone
>>>broke it very
>>>recently). 
>>>      
>>>
>>We are talking about scrollmode = SCROLL_WRAP_MOVE ?
>>    
>>
>
>Try this patch.
>
>  
>
It doesn´t help. I cecked the values for rows and vrows and believe that 
they are ok.
To be sure that we are not talking about different things: How _should_ 
this mode
work? If I use ywrap, why is it called scroll_wrap_MOVE? It should not 
be necessary
to move anything around  when using ywrap ...

cu,
 Knut


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: scroll modes

[Antonino A. Daplas]

Knut Petersen wrote:
> Antonino A. Daplas schrieb:
> 
>> Knut Petersen wrote:
>>  
>>
>>> Geert Uytterhoeven wrote:
>>>
>>>   
>>>> Ywrap has been working fine with amifb since ages (unless someone
>>>> broke it very
>>>> recently).     
>>> We are talking about scrollmode = SCROLL_WRAP_MOVE ?
>>>   
>>
>> Try this patch.
>>
>>  
>>
> It doesn´t help. I cecked the values for rows and vrows and believe that
> they are ok.
> To be sure that we are not talking about different things: How _should_
> this mode
> work? If I use ywrap, why is it called scroll_wrap_MOVE? It should not
> be necessary
> to move anything around  when using ywrap ...

You still have to, because the console can ask for a partial scroll.
For example, assume you have a screen of 20 lines, the console can, for
example, ask to scroll rows 5-10 up by 1 line to row 4-9, leave rows 0-3 and
11-19 in the same place. So fbcon will adjust the yoffset, but has to move
rows 0-3 and 11-19 so they appear stationary to the user.

However, if the request for scrolling is a screenful at at time (ie,
move entire screen contents up by 1 line), then I don't think any
bmoves will be called.  Here's a snippet from the fbcon_scroll
(comments are mine):

	if (t > 0) /* if top is at origin, do not move */
		fbcon_bmove(vc, 0, 0, count, 0, t,
			    vc->vc_cols);
	ywrap_up(vc, count); /* adjust yoffset */

	if (vc->vc_rows - b > 0) /* if bottom is at end, do not move */
		fbcon_bmove(vc, b - count, 0, b, 0,
			    vc->vc_rows - b,
			    vc->vc_cols);

Tony

P.S: Ywrapping is very old code, and I think Geert can explain the code
much better than I.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: scroll modes

[Knut Petersen]

Hi Geert/Antonino,

YWRAP_MOVE now does work on the cyberblade/i1. The following change
to bitblit.c is necessary:

static int bit_update_start(struct fb_info *info)
{
        struct fbcon_ops *ops = info->fbcon_par;
        int err;

-         err = fb_pan_display(info, &ops->var);
+        err = info->fbops->fb_pan_display(&ops->var,info);;
        ops->var.xoffset = info->var.xoffset;
        ops->var.yoffset = info->var.yoffset;
        ops->var.vmode = info->var.vmode;
        return err;
}

I have to admit that I´m not one of those gurus who fully understand the 
fbcon
console layer in all details ... so please check that this does not 
break anything else.

cu,
 knut


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: scroll modes

[Antonino A. Daplas]

Knut Petersen wrote:
> Hi Geert/Antonino,
> 
> YWRAP_MOVE now does work on the cyberblade/i1. The following change
> to bitblit.c is necessary:
> 
> static int bit_update_start(struct fb_info *info)
> {
>        struct fbcon_ops *ops = info->fbcon_par;
>        int err;
> 
> -         err = fb_pan_display(info, &ops->var);
> +        err = info->fbops->fb_pan_display(&ops->var,info);;

Well, no.  If there is something wrong with fb_pan_display() let's fix that.
I don't want any code calling fbops->fb_pan_display() directly.

What's wrong with fb_pan_display() that requires fixing?

Tony


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: scroll modes

[Antonino A. Daplas]

Knut Petersen wrote:
> Hi Geert/Antonino,
> 
 > I have to admit that I´m not one of those gurus who fully understand the
> fbcon
> console layer in all details ... so please check that this does not
> break anything else.
> 

I think I see the problem.  Can you try this instead?

Tony

PS: Do you still need the previous patch?  The one that adjusts
p->vrows?

diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index eda237e..587b70e 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -727,13 +727,18 @@ fb_pan_display(struct fb_info *info, str
 {
         int xoffset = var->xoffset;
         int yoffset = var->yoffset;
-        int err;
+        int err, yres;
 
-        if (!info->fbops->fb_pan_display || xoffset < 0 || yoffset < 0 ||
-	    xoffset + info->var.xres > info->var.xres_virtual ||
-            yoffset + info->var.yres > info->var.yres_virtual)
-                return -EINVAL;
+	if (var->vmode & FB_VMODE_YWRAP)
+		yres = 0;
+	else
+		yres = info->var.yres;
 
+        if (!info->fbops->fb_pan_display || xoffset < 0 || yoffset < 0 ||
+	    var->yoffset + yres > info->var.yres_virtual ||
+	    var->xoffset + info->var.xres > info->var.xres_virtual)
+		return -EINVAL;
+	
 	if ((err = info->fbops->fb_pan_display(var, info)))
 		return err;
 


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: scroll modes

[Knut Petersen]

Antonino A. Daplas schrieb:

>I think I see the problem.  Can you try this instead?
>
>  
>
I have to get up in 6 hours, so I will check it tomorrow. I think your 
fix is right, the problem
was  returning with -EINVAL if yoffset + info->var.yres > 
info->var.yres_virtual instead of
calling the drivers panning function.

>Tony
>
>PS: Do you still need the previous patch?  The one that adjusts
>p->vrows?
>
>  
>
Don´t know,  but it´s in my working configuration, so at least it does 
not break anything.

Geert stated that ywrap scrolling should be fine on amifb ... is that 
really true with
current code?

cu,
 Knut




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: scroll modes

[Antonino A. Daplas]

Knut Petersen wrote:
> Antonino A. Daplas schrieb:
> 
>> I think I see the problem.  Can you try this instead?
>>
>>  
>>
> I have to get up in 6 hours, so I will check it tomorrow. I think your
> fix is right, the problem
> was  returning with -EINVAL if yoffset + info->var.yres >
> info->var.yres_virtual instead of
> calling the drivers panning function.
> 
>> Tony
>>
>> PS: Do you still need the previous patch?  The one that adjusts
>> p->vrows?
>>
>>  
>>
> Don´t know,  but it´s in my working configuration, so at least it does
> not break anything.
> 

I think it's needed, otherwise the entire memory will not be used. But
I'll wait for you to check this out.

> Geert stated that ywrap scrolling should be fine on amifb ... is that
> really true with
> current code?

Most probably, amifb broke too.

Tony


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: scroll modes

[Knut Petersen]

Hi Tony

first of all, in updatescrollmode we introduce a the local fh, but lateron
vc->vc_font.height is often read again. Fixing that would be a cosmetic 
change, as
the compiler should optimize that anyway.

>diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
>index 1a8f0ea..5ebe68f 100644
>--- a/drivers/video/console/fbcon.c
>+++ b/drivers/video/console/fbcon.c
>@@ -1972,12 +1972,6 @@ static __inline__ void updatescrollmode(
> 	int fast_imageblit = (cap & FBINFO_HWACCEL_IMAGEBLIT) &&
> 		!(cap & FBINFO_HWACCEL_DISABLED);
> 
>-	p->vrows = vyres/fh;
>-	if (yres > (fh * (vc->vc_rows + 1)))
>-		p->vrows -= (yres - (fh * vc->vc_rows)) / fh;
>-	if ((yres % fh) && (vyres % fh < yres % fh))
>-		p->vrows--;
>-
> 	if (good_wrap || good_pan) {
> 		if (reading_fast || fast_copyarea)
> 			p->scrollmode = good_wrap ?
>@@ -1991,6 +1985,16 @@ static __inline__ void updatescrollmode(
> 		else
> 			p->scrollmode = SCROLL_REDRAW;
> 	}
>+
>+	p->vrows = vyres/fh;
>  
>
ok, does not change anything.

>+
>+	if (p->scrollmode != SCROLL_WRAP_MOVE &&
>+	    (yres > (fh * (vc->vc_rows + 1))))
>+		    p->vrows -= (yres - (fh * vc->vc_rows)) / fh;
>+
>  
>
1024x768, vyres 2048, seems to  work with and without that extra
"p->scrollmode != SCROLL_WRAP_MOVE", but could you please
explain when  "yres > (fh * (vc->vc_rows + 1))" will be true?

>+	if ((yres % fh) && (vyres % fh < yres % fh))
>+		p->vrows--;
>  
>
ok, does not change anything.

Further comments to updatescrollmode:

      int good_wrap = (cap & FBINFO_HWACCEL_YWRAP) &&
              divides(ywrap, vc->vc_font.height) &&
              divides(vc->vc_font.height, vyres);

is broken as it does not check that vyres * vxres == whole available video
memory. Or is there hardware that has an adjustable wrap address? Hmm, I
even can think of a way to reprogram the cyberblade/i1 to wrap at the 1, 2,
4 or 8MB boundaries while the system is running.

Even if that additional check would be introduced it would have problems
- with drivers like vesafb that do not map all available memory
- with drivers that do not know about all available memory
- with drivers that allow users to specify arbitraty values for the 
video memory size.

I don´t like the whole concept of updatescrollmode based on the evaluation
of various flags, asumptions and values.

Scrolling with YWRAP_MOVE is faster than scrolling with YPAN_MOVE,
often much faster. Execution time of  a "cat testfile" drops for mode 
1024x768-32
from 1.225s to 0.835s with cyblafb.

But I don´t like that the bottom status line of my curses based editor 
jumps while
scrolling up/down. So I have several options:

  - Don´t use ywrap scrolling
  - Ignore the anoying flicker of the base line
  - change the working YWRAP_MOVE
  - submit an alternative YWRAP_SOMETHING

But how should that YWRAP_SOMETHING be selected by updatescrollmode?
The individual driver does know best about the hardware about user 
preferences
and of the supported scroll modes in any situation.

========================================================
Wouldn´t it be easier and cleaner to introduce a new optional fb_ops 
function
fb_scrollmode(...) that would, if implemented in the driver, replace and 
extend
the functionality  implemented in updatescrollmode?!
========================================================

cu,
 Knut



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: scroll modes

[Geert Uytterhoeven]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; CHARSET=UTF-8, Size: 1330 bytes --]

On Fri, 2 Dec 2005, Knut Petersen wrote:
> Antonino A. Daplas schrieb:
> > I think I see the problem.  Can you try this instead?
> >  
> I have to get up in 6 hours, so I will check it tomorrow. I think your fix is
> right, the problem
> was  returning with -EINVAL if yoffset + info->var.yres >
> info->var.yres_virtual instead of
> calling the drivers panning function.
> 
> > Tony
> > 
> > PS: Do you still need the previous patch?  The one that adjusts
> > p->vrows?
> > 
> >  
> Don´t know,  but it´s in my working configuration, so at least it does not
> break anything.
> 
> Geert stated that ywrap scrolling should be fine on amifb ... is that really
> true with
> current code?

To be honest, I don't know. The last kernel I booted on real Amiga hardware
was 2.6.8.1.

Anyone who can confirm that amifb works fine in recent kernels? Or perhaps
ywrap got disabled somewhere (which reminds me I still have to benchmark the
various scrollmodes to find the optimal value for amifb)?

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

Re: scroll modes

[Antonino A. Daplas]

Knut Petersen wrote:
> Hi Tony
> 
> first of all, in updatescrollmode we introduce a the local fh, but lateron
> vc->vc_font.height is often read again. Fixing that would be a cosmetic
> change, as
> the compiler should optimize that anyway.
> 
>> diff --git a/drivers/video/console/fbcon.c
>> b/drivers/video/console/fbcon.c
>> index 1a8f0ea..5ebe68f 100644
>> --- a/drivers/video/console/fbcon.c
>> +++ b/drivers/video/console/fbcon.c
>> @@ -1972,12 +1972,6 @@ static __inline__ void updatescrollmode(
>>     int fast_imageblit = (cap & FBINFO_HWACCEL_IMAGEBLIT) &&
>>         !(cap & FBINFO_HWACCEL_DISABLED);
>>
>> -    p->vrows = vyres/fh;
>> -    if (yres > (fh * (vc->vc_rows + 1)))
>> -        p->vrows -= (yres - (fh * vc->vc_rows)) / fh;
>> -    if ((yres % fh) && (vyres % fh < yres % fh))
>> -        p->vrows--;
>> -
>>     if (good_wrap || good_pan) {
>>         if (reading_fast || fast_copyarea)
>>             p->scrollmode = good_wrap ?
>> @@ -1991,6 +1985,16 @@ static __inline__ void updatescrollmode(
>>         else
>>             p->scrollmode = SCROLL_REDRAW;
>>     }
>> +
>> +    p->vrows = vyres/fh;
>>  
>>
> ok, does not change anything.
> 
>> +
>> +    if (p->scrollmode != SCROLL_WRAP_MOVE &&
>> +        (yres > (fh * (vc->vc_rows + 1))))
>> +            p->vrows -= (yres - (fh * vc->vc_rows)) / fh;
>> +
>>  
>>
> 1024x768, vyres 2048, seems to  work with and without that extra
> "p->scrollmode != SCROLL_WRAP_MOVE", but could you please
> explain when  "yres > (fh * (vc->vc_rows + 1))" will be true?

If console window size is less than display resolution.  For example,
1024x768 with 8x16 font will have rows == 48.  It is possible to do an
stty rows 40 and still maintain a 1024x768 resolution, ie vesafb.

> 
>> +    if ((yres % fh) && (vyres % fh < yres % fh))
>> +        p->vrows--;
>>  
>>
> ok, does not change anything.
> 
> Further comments to updatescrollmode:
> 
>      int good_wrap = (cap & FBINFO_HWACCEL_YWRAP) &&
>              divides(ywrap, vc->vc_font.height) &&
>              divides(vc->vc_font.height, vyres);
> 
> is broken as it does not check that vyres * vxres == whole available video
> memory.

The driver's check_var should have done that for you.

> Or is there hardware that has an adjustable wrap address? Hmm, I
> even can think of a way to reprogram the cyberblade/i1 to wrap at the 1, 2,
> 4 or 8MB boundaries while the system is running.
> 
> Even if that additional check would be introduced it would have problems
> - with drivers like vesafb that do not map all available memory
> - with drivers that do not know about all available memory
> - with drivers that allow users to specify arbitraty values for the
> video memory size.

When that happens, the driver should disable ywrap by setting ywrapstep to
zero, or clearing the HWACCEL_YWRAP flag during set_par.

> 
> I don´t like the whole concept of updatescrollmode based on the evaluation
> of various flags, asumptions and values.
> 
> Scrolling with YWRAP_MOVE is faster than scrolling with YPAN_MOVE,
> often much faster. Execution time of  a "cat testfile" drops for mode
> 1024x768-32
> from 1.225s to 0.835s with cyblafb.
> 
> But I don´t like that the bottom status line of my curses based editor
> jumps while
> scrolling up/down. So I have several options:
> 
>  - Don´t use ywrap scrolling
>  - Ignore the anoying flicker of the base line
>  - change the working YWRAP_MOVE
>  - submit an alternative YWRAP_SOMETHING

You can implement YWRAP_REDRAW.  As mentioned in fbcon.h, this is the
scrollmode that is not implemented yet. You can also optimize 
SCROLL_WRAP_MOVE so it eliminates extra blits.

> 
> But how should that YWRAP_SOMETHING be selected by updatescrollmode?
> The individual driver does know best about the hardware about user
> preferences
> and of the supported scroll modes in any situation.

See fbcon.h. For example to prefer YWRAP_REDRAW from YWRAP_MOVE, one
can clear the HWACCEL_COPYAREA and set HWACCEL_IMAGEBLIT.


Tony



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click