Re: scroll modes
flat view
From: "Antonino A. Daplas" <adaplas@gmail.com>
Date: 2005-12-08 21:24:46
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.quoted
diff --git a/drivers/video/console/fbcon.cb/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.quoted
+ + 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.
quoted
+ 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