From: Ondrej Zajicek <hidden> Date: 2006-05-15 21:03:35
Hello
I found that in kernel 2.6.16.16 is some very strange behavior in fbcon.
I added some printks to some functions in fbcon and i found this:
I am on vt0, i have active vt0-vt3. When i modprobe fbcon (having fbdev
driver inserted before), functions fbcon.c/fbcon_init() and
fbcon.c/updatescrollmode() are called for each active vt.
Order is:
fbcon_init(vt0)
updatescrollmode(vt0)
updatescrollmode(vt1)
fbcon_init(vt1)
updatescrollmode(vt2)
fbcon_init(vt2)
updatescrollmode(vt3)
fbcon_init(vt3)
for vt1-vt3 updatescrollmode is called before fbcon_init which caused that
associated struct display::vrows value is computed (in updatescrollmode()
- fbcon.c:1970) from old vc->vc_rows (which is updated in fbcon_init()).
Now second strangeness - I am still on vt0 (immediately after modprobe fbcon),
but during calls to bitblit.c/bit_cursor display structure associated with
vt3 is used (in bitblit.c:244 - ops->p). Combined with previous strangeness
(bad vrows values in vt1-vt3) i get cursor visible on bad row.
When i switch to another vt or switch resolution, then this is corrected
(next calls to bitblit.c/bit_cursor are using correct display structure.).
I don't understand fbcon enough to correct this problem (and be sure not to
make some other :-)).
--
Elen sila lumenn' omentielvo
Ondrej 'SanTiago' Zajicek (email: santiago@mail.cz, jabber: santiago@njs.netlab.cz)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
From: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2006-05-20 00:30:14
Ondrej Zajicek wrote:
Hello
I found that in kernel 2.6.16.16 is some very strange behavior in fbcon.
I added some printks to some functions in fbcon and i found this:
I am on vt0, i have active vt0-vt3. When i modprobe fbcon (having fbdev
driver inserted before), functions fbcon.c/fbcon_init() and
fbcon.c/updatescrollmode() are called for each active vt.
Order is:
fbcon_init(vt0)
updatescrollmode(vt0)
updatescrollmode(vt1)
fbcon_init(vt1)
updatescrollmode(vt2)
fbcon_init(vt2)
updatescrollmode(vt3)
fbcon_init(vt3)
for vt1-vt3 updatescrollmode is called before fbcon_init which caused that
associated struct display::vrows value is computed (in updatescrollmode()
- fbcon.c:1970) from old vc->vc_rows (which is updated in fbcon_init()).
Now second strangeness - I am still on vt0 (immediately after modprobe fbcon),
but during calls to bitblit.c/bit_cursor display structure associated with
vt3 is used (in bitblit.c:244 - ops->p). Combined with previous strangeness
(bad vrows values in vt1-vt3) i get cursor visible on bad row.
When i switch to another vt or switch resolution, then this is corrected
(next calls to bitblit.c/bit_cursor are using correct display structure.).
I don't understand fbcon enough to correct this problem (and be sure not to
make some other :-)).
From: Dennis Munsie <hidden> Date: 2006-05-20 01:40:33
has anyone here actually been able to use the panning support in the intelfb driver? we are having some issues using it, and my quick perusal of the code leads me to believe that it might not actually work.
dennis
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
From: Ondrej Zajicek <hidden> Date: 2006-05-23 21:11:19
On Sat, May 20, 2006 at 08:30:06AM +0800, Antonino A. Daplas wrote:
Ondrej Zajicek wrote:
quoted
Now second strangeness - I am still on vt0 (immediately after modprobe fbcon),
but during calls to bitblit.c/bit_cursor display structure associated with
vt3 is used (in bitblit.c:244 - ops->p). Combined with previous strangeness
(bad vrows values in vt1-vt3) i get cursor visible on bad row.
Yes, this corrects it. Thank you.
--
Elen sila lumenn' omentielvo
Ondrej 'SanTiago' Zajicek (email: santiago@mail.cz, jabber: santiago@njs.netlab.cz)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."