Hi everybody,
under certain circumstances the X trident driver does disable mmio
upon returning to a linux console. As mapped ioports are no longer
available, this is an immediate problem.
I never had expected that upon switching from X to a linux console
drawing functions like fb_imageblit would be called before the
fb_check_var and fb_set_par functions have been called. But that´s
definitely the case.
Cyblafb now has a workaround for the problem, but I do believe that
this odd behaviour could also be the reason for failure or problems of
some other drivers that do work fine as long as X is not involved,
but fail or show problems upon switching between the linux console
and X.
Please have a look at the code.
cu,
Knut
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
From: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2005-08-25 14:05:59
Knut Petersen wrote:
Hi everybody,
under certain circumstances the X trident driver does disable mmio
upon returning to a linux console. As mapped ioports are no longer
available, this is an immediate problem.
I never had expected that upon switching from X to a linux console
drawing functions like fb_imageblit would be called before the
fb_check_var and fb_set_par functions have been called. But that´s
definitely the case.
I'm surprised. That was a problem in earlier versions of the kernel
but I think that was fixed. If you look at fbcon code, all calls to
drawing functions:
putcs, bmove, scroll, cursor, flashcursor, etc has an
if (fbcon_is_inactive()) in the beginning.
And everytime the vt switches from KD_GRAPHICS to KD_TEXT (ie from X),
a set_var()/ set_par() will be called automatically to reset the fbdev
drivers before the "drawing" functions are called.
Can you instrument where this is happening? Because if it still is,
then that is a show-stopping bug.
Tony
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Hi Antonino,
BTW: Thanks to Jochen Hein for testing cyblafb and reporting the
very long timeout after switching from X to console!
quoted
I never had expected that upon switching from X to a linux console
drawing functions like fb_imageblit would be called before the
fb_check_var and fb_set_par functions have been called. But that´s
definitely the case.
I'm surprised. That was a problem in earlier versions of the kernel
but I think that was fixed. If you look at fbcon code, all calls to
drawing functions:
My system is based on SuSE 9.2.
Kernel 2.6.13-rc7
1. If I do compile cyblafb as a module, there is no problem.
2. If I compile cyblafb into the kernel, there is no problem if
the first runlevel is 3 and I switch to runlevel 5 after login to
a console.
3. If I compile cyblafb into the kernel, the problem is 100% reproducible
if the first runlevel is 5. ps ax -H in that case:
1342 ? Ss 0:00 /usr/sbin/cron
1352 ? Ss 0:00 /usr/sbin/gpm -m /dev/ttyS0 -t ms
1362 ? S 0:00 /opt/kde3/bin/kdm
1385 ? S 0:20 /usr/X11R6/bin/X -nolisten tcp -br vt7
-auth /var/lib/xdm/authdir/authfiles/A:0-Zgg52m
1392 ? S 0:00 -:0
1681 ? S 0:00 /bin/sh /usr/X11R6/bin/kde
1716 ? S 0:00 gpg-agent --daemon --no-detach
--keep-display /bin/bash /etc/X11/xinit/xinitrc
1786 ? S 0:00 kwrapper ksmserver
1648 ? Ss 0:00 login -- root
1744 tty1 Ss+ 0:00 -bash
1649 tty2 Ss+ 0:00 /sbin/mingetty tty2
The very first time I switch back from X to a linux console the bug
is triggered. cyblafb_sync() , called from cyblafb_imageblit(), times
out because mmio is switched off. Then a number of drawing functions
is called before the checkvar() and the setpar() are executed.
Let´s count in /var/log/messages .... exactly 64 calls.
64 (rows) * 16 (font height) = 1024 (screen height). I have not verified
that
all those calls are imageblits, but it seems that somebody wants to redraw
the screen.
After that the bug never triggers again.
I wonder why there should be a difference between kdm executed first
or login executed first, but that´s the case.
Feel free to send patches.
cu,
Knut
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
From: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2005-08-25 18:09:29
Knut Petersen wrote:
Hi Antonino,
BTW: Thanks to Jochen Hein for testing cyblafb and reporting the
very long timeout after switching from X to console!
quoted
quoted
I never had expected that upon switching from X to a linux console
drawing functions like fb_imageblit would be called before the
fb_check_var and fb_set_par functions have been called. But that´s
definitely the case.
I'm surprised. That was a problem in earlier versions of the kernel
but I think that was fixed. If you look at fbcon code, all calls to
drawing functions:
My system is based on SuSE 9.2.
Kernel 2.6.13-rc7
1. If I do compile cyblafb as a module, there is no problem.
2. If I compile cyblafb into the kernel, there is no problem if
the first runlevel is 3 and I switch to runlevel 5 after login to
a console.
3. If I compile cyblafb into the kernel, the problem is 100% reproducible
if the first runlevel is 5. ps ax -H in that case:
1342 ? Ss 0:00 /usr/sbin/cron
1352 ? Ss 0:00 /usr/sbin/gpm -m /dev/ttyS0 -t ms
1362 ? S 0:00 /opt/kde3/bin/kdm
1385 ? S 0:20 /usr/X11R6/bin/X -nolisten tcp -br vt7
-auth /var/lib/xdm/authdir/authfiles/A:0-Zgg52m
1392 ? S 0:00 -:0 1681 ? S
0:00 /bin/sh /usr/X11R6/bin/kde
1716 ? S 0:00 gpg-agent --daemon --no-detach
--keep-display /bin/bash /etc/X11/xinit/xinitrc
1786 ? S 0:00 kwrapper ksmserver
1648 ? Ss 0:00 login -- root 1744 tty1 Ss+
0:00 -bash
1649 tty2 Ss+ 0:00 /sbin/mingetty tty2
The very first time I switch back from X to a linux console the bug
is triggered. cyblafb_sync() , called from cyblafb_imageblit(), times
out because mmio is switched off. Then a number of drawing functions
is called before the checkvar() and the setpar() are executed.
Let´s count in /var/log/messages .... exactly 64 calls.
64 (rows) * 16 (font height) = 1024 (screen height). I have not verified
that
all those calls are imageblits, but it seems that somebody wants to redraw
the screen.
After that the bug never triggers again.
I wonder why there should be a difference between kdm executed first
or login executed first, but that´s the case.
I tried to duplicate the problem, but failed.
First, I inserted stub calls, disable_device(info). I inserted it in fbcon_blank(),
if blank != 0 and mode_switch != 0. I also inserted another one in fbcon_switch(),
if vc->vc_mode == KD_GRAPHICS. These are the circumstances when the console is
about to be acquired by a graphics apps like X. Then the stub function,
disable_device(), in the fbdev driver, just sets a flag. This flag is cleared
on a set_par(). This flag is also checked by the sync, imageblit, fillrect and
copyarea functions, which prints something when this flag != 0. I'm not getting
any messages. Which, if I interpret this correctly, that a set_par will always
be called before any of the drawing functions.
The circumstance I can think of that this can happen is when the app fails to
set the VT to KD_GRAPHICS mode, but I'm pretty sure kdm does it properly, in
my machine at least (Suse 9.0).
Perhaps, if you have the time, you can instrument it better so we can pinpoint
where this unwanted calls are coming from. Months were spent trying to fix this
problem, mainly by BenH, and I don't want any stones left unturned.
Tony
PS: I don't know the console subsystem that well, so there may be pathways that
I don't know about.
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Perhaps, if you have the time, you can instrument it better so we can
pinpoint
where this unwanted calls are coming from. Months were spent trying
to fix this
problem, mainly by BenH, and I don't want any stones left unturned.
So lets conclude: The problem is _not_ fixed and still present in
2.6.13-rc7.
I added BenH and Andrew Morton to the cc-list.
I added a printk at the start of redraw_screen() and a show_trace() in
cyblafb_sync().
Imho
- there is a bug of the trident driver in X that should _never_
disable mmio for
the cyberblade core if it is started with mmio enabled. A bug Alan
Hourihane
should fix.
- there also is a serious kernel bug as no drawing function must be called
prior to setting up the framebuffer driver by executing the
set_par() call.
I´m happy to have learned enough about the low -level framebuffer layer,
but I´m definitely not qualified to do fixed in char/vt.c,
char/vt_ioctl.c etc.
Read some shortened dmesg logs:
(cyblafb: Switching ... marks the start of the fb_set_par function)
==========
First log:
==========
1-init to runlevel 3
2-login as root on tty1
3-init 5
4-switching back to tty1 with ctrl-alt-f1
...
Detected 533.506 MHz processor.
Using tsc for high-res timesource
redraw_screen: called with is_switch 0 and vc->vc_mode 0
Console: colour dummy device 80x25
...
ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
Boot video device is 0000:01:00.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
...
cyblafb: CyblaFB version 0.53 initializing
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
PCI: setting IRQ 11 as level-triggered
ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [LNKA] -> GSI 11 (level,
low) -> IRQ 11
cyblafb: framebuffer size = 8192 Kb
cyblafb: detected startup mode: fbset -g 1280 1024 1280 ??? 8 -t 7407
232 16 39 0 160 3
redraw_screen: called with is_switch 0 and vc->vc_mode 0
cyblafb: Switching to new mode: fbset -g 1280 1024 1280 2662 8 -t 7407
232 16 39 0 160 3
redraw_screen: called with is_switch 0 and vc->vc_mode 0
redraw_screen: called with is_switch 0 and vc->vc_mode 0
Console: switching to colour frame buffer device 160x64
...
ACPI: PCI Interrupt 0000:00:11.5[C] -> Link [LNKC] -> GSI 12 (level,
low) -> IRQ 12
PCI: Setting latency timer of device 0000:00:11.5 to 64
redraw_screen: called with is_switch 0 and vc->vc_mode 0
eth0: no IPv6 routers present
redraw_screen: called with is_switch 0 and vc->vc_mode 0
******** Now logged in as root on tty1
redraw_screen: called with is_switch 1 and vc->vc_mode 0
******** X has been started here, we are in xterm. Now ctrl-alt-f1:
redraw_screen: called with is_switch 1 and vc->vc_mode 0
cyblafb: Switching to new mode: fbset -g 1280 1024 1280 2662 8 -t 7407
232 16 39 0 160 3
redraw_screen: called with is_switch 0 and vc->vc_mode 0
******** We switched back to tty1
As you can see, redraw_screen is called prior to cyblafb_setpar, but
nothing bad is
triggered because the X trident buffer does not disable mmio.
===========
Second log:
===========
1-init to runlevel 5
2-switching to tty1 with ctrl-alt-f1
...
Detected 533.508 MHz processor.
Using tsc for high-res timesource
redraw_screen: called with is_switch 0 and vc->vc_mode 0
Console: colour dummy device 80x25
...
ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
Boot video device is 0000:01:00.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
...
cyblafb: CyblaFB version 0.53 initializing
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
PCI: setting IRQ 11 as level-triggered
ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [LNKA] -> GSI 11 (level,
low) -> IRQ 11
cyblafb: framebuffer size = 8192 Kb
cyblafb: detected startup mode: fbset -g 1280 1024 1280 ??? 8 -t 7407
232 16 39 0 160 3
redraw_screen: called with is_switch 0 and vc->vc_mode 0
cyblafb: Switching to new mode: fbset -g 1280 1024 1280 2662 8 -t 7407
232 16 39 0 160 3
redraw_screen: called with is_switch 0 and vc->vc_mode 0
redraw_screen: called with is_switch 0 and vc->vc_mode 0
Console: switching to colour frame buffer device 160x64
...
ACPI: PCI Interrupt 0000:00:11.5[C] -> Link [LNKC] -> GSI 12 (level,
low) -> IRQ 12
PCI: Setting latency timer of device 0000:00:11.5 to 64
redraw_screen: called with is_switch 0 and vc->vc_mode 0
eth0: no IPv6 routers present
redraw_screen: called with is_switch 1 and vc->vc_mode 0
******** X has been started here, we are in xterm
******** ctrl-alt-f1
redraw_screen: called with is_switch 1 and vc->vc_mode 0
cyblafb: GRAPHICS ENGINE TIMED OUT!
[<c0246abd>] cyblafb_imageblit+0xad/0x230
[<c0241a3b>] bit_putcs+0x2eb/0x560
[<c01138a5>] __wake_up_common+0x35/0x70
[<c023dba8>] fbcon_putcs+0x168/0x210
[<c028c11b>] do_update_region+0x11b/0x180
[<c028cc13>] redraw_screen+0x143/0x1e0
[<c0288788>] complete_change_console+0x28/0xd0
[<c0287cbd>] vt_ioctl+0x111d/0x1aa0
[<c014886e>] __handle_mm_fault+0x13e/0x180
[<c011174d>] do_page_fault+0x19d/0x550
[<c03a7dd7>] schedule+0x337/0x670
[<c0286ba0>] vt_ioctl+0x0/0x1aa0
[<c0281fbc>] tty_ioctl+0x17c/0x410
[<c011364a>] scheduler_tick+0x17a/0x310
[<c0169d98>] do_ioctl+0x48/0x80
[<c0169f2a>] vfs_ioctl+0x5a/0x1d0
[<c016a0e6>] sys_ioctl+0x46/0x60
[<c0102909>] syscall_call+0x7/0xb
cyblafb: Switching to new mode: fbset -g 1280 1024 1280 2662 8 -t 7407
232 16 39 0 160 3
redraw_screen: called with is_switch 0 and vc->vc_mode 0
******** Now logged in as root on tty1
redraw_screen: called with is_switch 1 and vc->vc_mode 1
******** switched to xterm
redraw_screen: called with is_switch 1 and vc->vc_mode 0
cyblafb: Switching to new mode: fbset -g 1280 1024 1280 2662 8 -t 7407
232 16 39 0 160 3
redraw_screen: called with is_switch 0 and vc->vc_mode 0
******** switched back to tty1
cu,
Knut
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
From: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2005-08-26 14:02:17
Knut Petersen wrote:
Hi Antonio,
quoted
Perhaps, if you have the time, you can instrument it better so we can
pinpoint
where this unwanted calls are coming from. Months were spent trying
to fix this
problem, mainly by BenH, and I don't want any stones left unturned.
So lets conclude: The problem is _not_ fixed and still present in
2.6.13-rc7.
I added BenH and Andrew Morton to the cc-list.
I added a printk at the start of redraw_screen() and a show_trace() in
cyblafb_sync().
Imho
- there is a bug of the trident driver in X that should _never_
disable mmio for
the cyberblade core if it is started with mmio enabled. A bug Alan
Hourihane
should fix.
- there also is a serious kernel bug as no drawing function must be called
prior to setting up the framebuffer driver by executing the
set_par() call.
I´m happy to have learned enough about the low -level framebuffer layer,
but I´m definitely not qualified to do fixed in char/vt.c,
char/vt_ioctl.c etc.
Read some shortened dmesg logs:
(cyblafb: Switching ... marks the start of the fb_set_par function)
==========
First log:
==========
1-init to runlevel 3
2-login as root on tty1
3-init 5
4-switching back to tty1 with ctrl-alt-f1
...
Detected 533.506 MHz processor.
Using tsc for high-res timesource
redraw_screen: called with is_switch 0 and vc->vc_mode 0
Console: colour dummy device 80x25
...
ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
Boot video device is 0000:01:00.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
...
cyblafb: CyblaFB version 0.53 initializing
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
PCI: setting IRQ 11 as level-triggered
ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [LNKA] -> GSI 11 (level,
low) -> IRQ 11
cyblafb: framebuffer size = 8192 Kb
cyblafb: detected startup mode: fbset -g 1280 1024 1280 ??? 8 -t 7407
232 16 39 0 160 3
redraw_screen: called with is_switch 0 and vc->vc_mode 0
cyblafb: Switching to new mode: fbset -g 1280 1024 1280 2662 8 -t 7407
232 16 39 0 160 3
redraw_screen: called with is_switch 0 and vc->vc_mode 0
redraw_screen: called with is_switch 0 and vc->vc_mode 0
Console: switching to colour frame buffer device 160x64
...
ACPI: PCI Interrupt 0000:00:11.5[C] -> Link [LNKC] -> GSI 12 (level,
low) -> IRQ 12
PCI: Setting latency timer of device 0000:00:11.5 to 64
redraw_screen: called with is_switch 0 and vc->vc_mode 0
eth0: no IPv6 routers present
redraw_screen: called with is_switch 0 and vc->vc_mode 0
******** Now logged in as root on tty1
redraw_screen: called with is_switch 1 and vc->vc_mode 0
******** X has been started here, we are in xterm. Now ctrl-alt-f1:
redraw_screen: called with is_switch 1 and vc->vc_mode 0
cyblafb: Switching to new mode: fbset -g 1280 1024 1280 2662 8 -t 7407
232 16 39 0 160 3
redraw_screen: called with is_switch 0 and vc->vc_mode 0
******** We switched back to tty1
As you can see, redraw_screen is called prior to cyblafb_setpar, but
nothing bad is
triggered because the X trident buffer does not disable mmio.
===========
Second log:
===========
1-init to runlevel 5
2-switching to tty1 with ctrl-alt-f1
...
Detected 533.508 MHz processor.
Using tsc for high-res timesource
redraw_screen: called with is_switch 0 and vc->vc_mode 0
Console: colour dummy device 80x25
...
ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
Boot video device is 0000:01:00.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
...
cyblafb: CyblaFB version 0.53 initializing
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
PCI: setting IRQ 11 as level-triggered
ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [LNKA] -> GSI 11 (level,
low) -> IRQ 11
cyblafb: framebuffer size = 8192 Kb
cyblafb: detected startup mode: fbset -g 1280 1024 1280 ??? 8 -t 7407
232 16 39 0 160 3
redraw_screen: called with is_switch 0 and vc->vc_mode 0
cyblafb: Switching to new mode: fbset -g 1280 1024 1280 2662 8 -t 7407
232 16 39 0 160 3
redraw_screen: called with is_switch 0 and vc->vc_mode 0
redraw_screen: called with is_switch 0 and vc->vc_mode 0
Console: switching to colour frame buffer device 160x64
...
ACPI: PCI Interrupt 0000:00:11.5[C] -> Link [LNKC] -> GSI 12 (level,
low) -> IRQ 12
PCI: Setting latency timer of device 0000:00:11.5 to 64
redraw_screen: called with is_switch 0 and vc->vc_mode 0
eth0: no IPv6 routers present
redraw_screen: called with is_switch 1 and vc->vc_mode 0
******** X has been started here, we are in xterm
So X is already started here, but vc->vc_mode is still KD_TEXT.
******** ctrl-alt-f1
redraw_screen: called with is_switch 1 and vc->vc_mode 0
Back to console mode, vc->vc_mode is correctly KD_TEXT. But
the kernel never detected a mode change. How could it, if the
previous mode was also KD_TEXT?
And there you go, without a mode change (KD_GRAPHICS->KD_TEXT),
the console thinks a set_var/set_par is unnecessary. This triggers
the bug (ouch).
cyblafb: Switching to new mode: fbset -g 1280 1024 1280 2662 8 -t 7407
232 16 39 0 160 3
redraw_screen: called with is_switch 0 and vc->vc_mode 0
******** Now logged in as root on tty1
redraw_screen: called with is_switch 1 and vc->vc_mode 1
******** switched to xterm
At this point, everything works. In this case, X is active, so
vc->vc_mode is correctly set to KD_GRAPHICS.. .
redraw_screen: called with is_switch 1 and vc->vc_mode 0
... and when it switches to KD_TEXT, the kernel detects the change,...
cyblafb: Switching to new mode: fbset -g 1280 1024 1280 2662 8 -t 7407
232 16 39 0 160 3
...calls set_var()/set_par...
redraw_screen: called with is_switch 0 and vc->vc_mode 0
******** switched back to tty1
...and the driver happily draws to the screen. No bug.
I believe, from here on, everything will work as expected.
So it seems that when kdm loads the first time, it failed to set the
mode to KD_GRAPHICS which triggered the bug. Maybe it's a bug in
kdm then?
Tony
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
...and the driver happily draws to the screen. No bug.
I believe, from here on, everything will work as expected.
So it seems that when kdm loads the first time, it failed to set the
mode to KD_GRAPHICS which triggered the bug. Maybe it's a bug in
kdm then?
Well, it might be a kdm bug, but that bug is widely spread then. SuSE
9.2 and Debian Sarge
are affected at least. I would call it a kernel design flaw / bug if we
allow this kind of
situation to happen. But why does this happen only if kdm is started
early? This question
must be answered. Even if the answer is that kdm does something wrong,
it would be
a good idea to call e.g. *fb_set_par() unconditionally for every console
switch ...
cu,
Knut
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
From: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2005-08-26 17:01:13
Knut Petersen wrote:
Hi Antonino,
quoted
...and the driver happily draws to the screen. No bug.
I believe, from here on, everything will work as expected.
So it seems that when kdm loads the first time, it failed to set the
mode to KD_GRAPHICS which triggered the bug. Maybe it's a bug in
kdm then?
Well, it might be a kdm bug, but that bug is widely spread then. SuSE
9.2 and Debian Sarge
are affected at least. I would call it a kernel design flaw / bug if we
allow this kind of
situation to happen.
Well, that's why X runs as root, and the kernel will practically do anything
for root.
But why does this happen only if kdm is started early?
I don't know. The kdm I in suse 9.0 seems not to exhibit this behavior.
This question
must be answered. Even if the answer is that kdm does something wrong,
it would be
a good idea to call e.g. *fb_set_par() unconditionally for every console
switch ...
This has been discussed before. Not all hardware can do a set_par()
instantaneously, some may require seconds. And that will become a usability
problem. Just imagine switching from one console to another and it takes
5 seconds.
Tony
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
This has been discussed before. Not all hardware can do a set_par()
instantaneously, some may require seconds. And that will become a
usability
problem. Just imagine switching from one console to another and it takes
5 seconds.
That would be unacceptable, agreed. But it´s also not really acceptable
to risk to execute a few
dozend imageblits in redraw_screen() while the hardware might be in an
unusable state. Checking
for that situation every imageblit would have a big performance penalty.
knut
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
From: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2005-08-27 00:37:00
Knut Petersen wrote:
quoted
This has been discussed before. Not all hardware can do a set_par()
instantaneously, some may require seconds. And that will become a
usability
problem. Just imagine switching from one console to another and it takes
5 seconds.
That would be unacceptable, agreed. But it´s also not really acceptable
to risk to execute a few
dozend imageblits in redraw_screen() while the hardware might be in an
unusable state.
It doesn't. but it depends what you mean by unusable state. In the
console/fbcon/fbdev subsystem an unusable state can be any of the ff:
- KD_GRAPHICS mode
- between coming from KD_GRAPHICS to KD_TEXT and before set_par()
- graphics device in a suspended state
If any the above are true, no drawing functions gets called.
Checking
for that situation every imageblit would have a big performance penalty.
Maybe. I've measured this before, you lose something like 3-5%. Hardly
noticeable in real-world usage. So I would gladly sacrifice a little
performance for stability. Doing a set_par() for each switch, in turn,
will be noticeable and is a great blow to usability. It really boils down
to a balance between usability, stability and performance. Throw in code
readability and maintainability also.
(Note: In the case of a bug in an app that runs as root, I think everyone will
agree that the bug must be fixed in the app, not the kernel.)
(Note 2: Even with those checks in place, the 2.6 framebuffer system is still
faster than 2.4)
Tony
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf