1. YWRAP scrolling.
There appears to be something weird going on with fbcon scrolling in 2.5.59
when using YWRAP. The best example is what happens when scrolling a large
file (say, /etc/termcap) in less.
While scrolling down in the file, the screen scrolls correctly for the
most part. At some point, the screen stops scrolling and the last line
which normally displays the less prompt character ":" is replaced by
the next line of text. Continuing to scroll down produces no visible
changes.
Once enough scrolling has occurred, suddenly the screen jumps and we get
the proper text displayed.
Also, if you scroll line by line until the ":" is replaced by text as
above, scrolling back up one line replaces the ":" and scrolling upwards
scrolls the screen up correctly.
As an additional behaviour point, if you scroll down until the ":" just
disappears and then some extra lines, hit 'q' to exit less, followed by
^L, most of the screen is cleared, except for the very top few lines.
I haven't checked, but I suspect the number of lines left at the top of
the screen is equal to the number of lines we're off the bottom of the
screen.
2. Initialisation
Machine 1: (acornfb)
parport0: PC-style at 0x278 (0x678) [PCSPP(,...)]
i2c-dev.o: i2c /dev entries driver module version 2.6.4 (20020719)
Acornfb: 2048kB VRAM, VIDC20, using 1280x1024, 63.885kHz, 59Hz
Acornfb: Monitor: 30.000-85.000kHz, 56-76Hz, DPMS
--> Console: switching to colour frame buffer device 160x128
pty: 256 Unix98 ptys configured
i2c-dev.o: Registered 'IOC/IOMD' as minor 0
mice: PS/2 mouse device common for all mice
input: Acorn RiscPC mouse
input: AT Set 2 keyboard on rpckbd/serio0
...
SCSI device sda: drive cache: write back
sda: sda1 sda2
Attached scsi removable disk sda at scsi0, channel 0, id 2, lun 0
--> Console: switching to colour frame buffer device 160x128
NET4: Linux TCP/IP 1.0 for NET4.0
IP: routing cache hash table of 512 buckets, 4Kbytes
Machine 2: (sa1100fb)
i2c-dev.o: i2c /dev entries driver module version 2.6.4 (20020719)
i2c-proc.o version 2.6.4 (20020719)
i2c-dev.o: Registered 'l3-bit-sa1100-gpio' as minor 0
dma period = 1372168 ps, clock = 206400 kHz
--> Console: switching to colour frame buffer device 40x30
pty: 256 Unix98 ptys configured
SA1100 Real Time Clock driver v1.00
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
--> Console: switching to colour frame buffer device 40x30
drivers/mtd/maps/pcmciamtd.c: PCMCIA Flash memory card driver $Revision: 1.36 $
We seem to be initialising the console twice? Certainly the position of the
text vs the logo seems to jump around with the second initialisation.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Mon, 2003-01-20 at 04:03, Russell King wrote:
> 1. YWRAP scrolling.
>
> There appears to be something weird going on with fbcon scrolling in 2.5.59
> when using YWRAP. The best example is what happens when scrolling a large
> file (say, /etc/termcap) in less.
>
> While scrolling down in the file, the screen scrolls correctly for the
> most part. At some point, the screen stops scrolling and the last line
> which normally displays the less prompt character ":" is replaced by
> the next line of text. Continuing to scroll down produces no visible
> changes.
>
> Once enough scrolling has occurred, suddenly the screen jumps and we get
> the proper text displayed.
>
> Also, if you scroll line by line until the ":" is replaced by text as
> above, scrolling back up one line replaces the ":" and scrolling upwards
> scrolls the screen up correctly.
>
> As an additional behaviour point, if you scroll down until the ":" just
> disappears and then some extra lines, hit 'q' to exit less, followed by
> ^L, most of the screen is cleared, except for the very top few lines.
> I haven't checked, but I suspect the number of lines left at the top of
> the screen is equal to the number of lines we're off the bottom of the
> screen.
>
fb_pan_display() does not test for YWRAP. Can you try this?
Tony
diff -Naur linux-2.5.59/drivers/video/fbmem.c linux/drivers/video/fbmem.c
--- linux-2.5.59/drivers/video/fbmem.c 2003-01-20 01:10:12.000000000 +0000
+++ linux/drivers/video/fbmem.c 2003-01-20 01:14:27.000000000 +0000
@@ -724,11 +724,15 @@
{
int xoffset = var->xoffset;
int yoffset = var->yoffset;
+ int ybottom = var->yoffset;
int err;
+ if (!(var->vmode & FB_VMODE_YWRAP))
+ ybottom += info->var.yres;
+
if (xoffset < 0 || yoffset < 0 || !info->fbops->fb_pan_display ||
xoffset + info->var.xres > info->var.xres_virtual ||
- yoffset + info->var.yres > info->var.yres_virtual)
+ ybottom > info->var.yres_virtual)
return -EINVAL;
if ((err = info->fbops->fb_pan_display(var, info)))
return err;
On Mon, Jan 20, 2003 at 09:29:38AM +0800, Antonino Daplas wrote:
> fb_pan_display() does not test for YWRAP. Can you try this?
This doesn't appear to solve the ywrap problem - I still get
places where the screen doesn't scroll. I decided to write a
small program to dump out the contents of fb_var_screeninfo, and
where stuff goes horribly wrong:
bash-2.04# ./tst
Visible: 1280x1024
Virtual: 1280x1632
BPP : 8
Offset : +0+2352
bash-2.04# ./tst
Visible: 1280x1024
Virtual: 1280x1632
BPP : 8
Offset : +0+2392
Up to the point where it goes wrong:
bash-2.04# ./tst
Visible: 1280x1024
Virtual: 1280x1632
BPP : 8
Offset : +0+528
bash-2.04# ./tst
Visible: 1280x1024
Virtual: 1280x1632
BPP : 8
Offset : +0+568
bash-2.04# ./tst
Visible: 1280x1024 <--- this is the last line on the screen
Virtual: 1280x1632
BPP : 8
Offset : +0+608
bash-2.04#
So it looks like something isn't limiting the yoffset in the generic
console layer; an xoffset of 2392 when the maximum virtual Y is 1632
is just nonsense.
I also noticed an additional problem with fbcon: if I change the
resolution using fbset, the change occurs, except I end up with
corrupted mess on the screen (the reminents of the original display.)
The shell prompt is nowhere to be seen.
Hitting ^L clears the screen and then the shell prompt is visiable.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
No one's commented on this yet.
James?
On Sun, Feb 02, 2003 at 07:57:44PM +0000, Russell King wrote:
> This doesn't appear to solve the ywrap problem - I still get
> places where the screen doesn't scroll. I decided to write a
> small program to dump out the contents of fb_var_screeninfo, and
> where stuff goes horribly wrong:
>
> bash-2.04# ./tst
> Visible: 1280x1024
> Virtual: 1280x1632
> BPP : 8
> Offset : +0+2352
> bash-2.04# ./tst
> Visible: 1280x1024
> Virtual: 1280x1632
> BPP : 8
> Offset : +0+2392
>
> Up to the point where it goes wrong:
>
> bash-2.04# ./tst
> Visible: 1280x1024
> Virtual: 1280x1632
> BPP : 8
> Offset : +0+528
> bash-2.04# ./tst
> Visible: 1280x1024
> Virtual: 1280x1632
> BPP : 8
> Offset : +0+568
> bash-2.04# ./tst
> Visible: 1280x1024 <--- this is the last line on the screen
> Virtual: 1280x1632
> BPP : 8
> Offset : +0+608
> bash-2.04#
>
> So it looks like something isn't limiting the yoffset in the generic
> console layer; an xoffset of 2392 when the maximum virtual Y is 1632
> is just nonsense.
>
> I also noticed an additional problem with fbcon: if I change the
> resolution using fbset, the change occurs, except I end up with
> corrupted mess on the screen (the reminents of the original display.)
> The shell prompt is nowhere to be seen.
>
> Hitting ^L clears the screen and then the shell prompt is visiable.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Mon, 2003-02-03 at 03:57, Russell King wrote:
> On Mon, Jan 20, 2003 at 09:29:38AM +0800, Antonino Daplas wrote:
> > fb_pan_display() does not test for YWRAP. Can you try this?
>
> This doesn't appear to solve the ywrap problem - I still get
> places where the screen doesn't scroll. I decided to write a
> small program to dump out the contents of fb_var_screeninfo, and
> where stuff goes horribly wrong:
>
> bash-2.04# ./tst
> Visible: 1280x1024
> Virtual: 1280x1632
> BPP : 8
> Offset : +0+2352
> bash-2.04# ./tst
> Visible: 1280x1024
> Virtual: 1280x1632
> BPP : 8
> Offset : +0+2392
>
> Up to the point where it goes wrong:
>
> bash-2.04# ./tst
> Visible: 1280x1024
> Virtual: 1280x1632
> BPP : 8
> Offset : +0+528
> bash-2.04# ./tst
> Visible: 1280x1024
> Virtual: 1280x1632
> BPP : 8
> Offset : +0+568
> bash-2.04# ./tst
> Visible: 1280x1024 <--- this is the last line on the screen
> Virtual: 1280x1632
> BPP : 8
> Offset : +0+608
> bash-2.04#
>
> So it looks like something isn't limiting the yoffset in the generic
> console layer; an xoffset of 2392 when the maximum virtual Y is 1632
> is just nonsense.
It might be a problem with display.vrows not being updated during
fbcon_resize(). I think I sent James some patches before that added
that.
Can you try adding this at the end of fbcon_resize() in
drivers/video/fbcon.c?
p->vrows = info->var.yres_virtual/vc->vc_font.height;
Tony
PS: I never encountered your problem, but I don't have hardware that's
capable of ywrap.
> No one's commented on this yet.
>
> James?
Sorry about the silence. The last month I have been devoting all my time
to look for work. As of next month I will be out of money. Meaning no home
to live in thus no internet. Because of this I like to have someone
replace me. Antonino you have done some really great work. I like you to
replace me to work with Geert to further the framebuffer layer. I still
have a month left to live on so I will contribute as much as I can. Thank
you.
> So it looks like something isn't limiting the yoffset in the generic
> console layer; an xoffset of 2392 when the maximum virtual Y is 1632
> is just nonsense.
I'm going to need to do some heavy cleaning in the next few days.
> I also noticed an additional problem with fbcon: if I change the
> resolution using fbset, the change occurs, except I end up with
> corrupted mess on the screen (the reminents of the original display.)
> The shell prompt is nowhere to be seen.
>
> Hitting ^L clears the screen and then the shell prompt is visiable.
The method to use now is stty to change the console mode. It works :-)
fbset is used to change the variable the vt terminals are not familiar
with such as bpp.
On Wed, Feb 12, 2003 at 08:26:10PM +0000, James Simmons wrote:
> > So it looks like something isn't limiting the yoffset in the generic
> > console layer; an xoffset of 2392 when the maximum virtual Y is 1632
> > is just nonsense.
>
> I'm going to need to do some heavy cleaning in the next few days.
>
> > I also noticed an additional problem with fbcon: if I change the
> > resolution using fbset, the change occurs, except I end up with
> > corrupted mess on the screen (the reminents of the original display.)
> > The shell prompt is nowhere to be seen.
> >
> > Hitting ^L clears the screen and then the shell prompt is visiable.
>
> The method to use now is stty to change the console mode. It works :-)
> fbset is used to change the variable the vt terminals are not familiar
> with such as bpp.
How do I ensure that such parameters as the refresh rate, hsync width and
offset, vsync width and offset are too my liking?
I've noticed that there seems to be some variation between the parameters
used, and I'd prefer to use my set since they match the host OS (it means
I don't have to keep readjusting the screen each time I change OS.)
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html