On Mon, Oct 14, 2002 at 09:39:31AM -0700, James Simmons wrote:
drivers/video/clps711xfb.c | 2
Ok, this won't clash with the updates Linus pulled recently from me
that actually allow this driver to build again in 2.5.42.
quoted hunk
diff -Nru a/drivers/video/clps711xfb.c b/drivers/video/clps711xfb.c
--- a/drivers/video/clps711xfb.c Mon Oct 14 09:36:34 2002
+++ b/drivers/video/clps711xfb.c Mon Oct 14 09:36:34 2002
@@ -194,7 +194,6 @@
.owner = THIS_MODULE,
.fb_check_var = clps7111fb_check_var,
.fb_set_par = clps7111fb_set_par,
- .fb_set_var = gen_set_var,
.fb_setcolreg = clps7111fb_setcolreg,
.fb_blank = clps7111fb_blank,
.fb_fillrect = cfb_fillrect,
@@ -322,7 +321,6 @@
clps_writeb(clps_readb(PDDR) | EDB_PD3_LCDBL, PDDR);
}
- gen_set_var(&cfb->var, -1, cfb);
err = register_framebuffer(cfb);
out: return err;
I'm not sure this "set var" business has been thought out as much as it
should be.
If can_soft_blank is not set, the driver will never, ever receive any
calls to perform blanking via the fb_blank callback. Even the power
management blanking calls are blocked, and fbcon clears the screen
instead. This in itself is fine.
However, since the set_var method has gone, drivers are now unable to
set can_soft_blank according to their capabilities because
fbgen.c:gen_set_disp will do it for them thusly:
if (info->fix.visual == FB_VISUAL_PSEUDOCOLOR ||
info->fix.visual == FB_VISUAL_DIRECTCOLOR) {
display->can_soft_blank = info->fbops->fb_blank ? 1 : 0;
display->dispsw_data = NULL;
} else {
display->can_soft_blank = 0;
display->dispsw_data = info->pseudo_palette;
}
This sucks on devices where blanking can be performed by hardware means.
For example, on embedded devices, you can turn off the LCD controller
and LCD panel (and thereby save power). There's no point in having both
these powered/running when the display is not in use, draining valuable
battery power.
This is also true of most, if not all VGA cards when VESA blanking is in
effect. As the code currently stands, if the console is in pseudo colour
or direct colour mode, everything works as expected. However, if it isn't,
you can't even power down your monitor when the screen blanks.
In 2.5.42, there is a work around possible - it is possible to intercept
the call to gen_set_var, and set con_soft_blank according to your driver
capabilities. However, with the fb_set_var method going away, this is no
longer possible.
--
Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
On Tue, 15 Oct 2002, Russell King wrote:
I'm not sure this "set var" business has been thought out as much as it
should be.
If can_soft_blank is not set, the driver will never, ever receive any
calls to perform blanking via the fb_blank callback. Even the power
management blanking calls are blocked, and fbcon clears the screen
instead. This in itself is fine.
However, since the set_var method has gone, drivers are now unable to
set can_soft_blank according to their capabilities because
fbgen.c:gen_set_disp will do it for them thusly:
if (info->fix.visual == FB_VISUAL_PSEUDOCOLOR ||
info->fix.visual == FB_VISUAL_DIRECTCOLOR) {
display->can_soft_blank = info->fbops->fb_blank ? 1 : 0;
display->dispsw_data = NULL;
} else {
display->can_soft_blank = 0;
display->dispsw_data = info->pseudo_palette;
}
This sucks on devices where blanking can be performed by hardware means.
For example, on embedded devices, you can turn off the LCD controller
and LCD panel (and thereby save power). There's no point in having both
these powered/running when the display is not in use, draining valuable
battery power.
This is also true of most, if not all VGA cards when VESA blanking is in
effect. As the code currently stands, if the console is in pseudo colour
or direct colour mode, everything works as expected. However, if it isn't,
you can't even power down your monitor when the screen blanks.
In 2.5.42, there is a work around possible - it is possible to intercept
the call to gen_set_var, and set con_soft_blank according to your driver
capabilities. However, with the fb_set_var method going away, this is no
longer possible.
So the generic part of the code should behave like this:
if (info->fbops->fb_blank && info->fbops->fb_blank(blank_flag)) {
/* use hardware blanking */
} else if (info->fix.visual == FB_VISUAL_PSEUDOCOLOR ||
info->fix.visual == FB_VISUAL_DIRECTCOLOR) {
/* use software blanking */
} else {
/* no blanking possible, except for filling the screen with black, which
is not appropriate (unless we save/restore the contents?) */
}
Is that OK for you?
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:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
So the generic part of the code should behave like this:
if (info->fbops->fb_blank && info->fbops->fb_blank(blank_flag)) {
/* use hardware blanking */
} else if (info->fix.visual == FB_VISUAL_PSEUDOCOLOR ||
info->fix.visual == FB_VISUAL_DIRECTCOLOR) {
/* use software blanking */
} else {
/* no blanking possible, except for filling the screen with black, which
is not appropriate (unless we save/restore the contents?) */
}
Is that OK for you?
I was thinking more like
if (info->fbops->fb_blank && info->fbops->fb_blank(blank_flag)) {
/* use hardware blanking */
} else if (info->var.accel_flags) {
/* Use hardware fillrect to blank the screen */
info->fbops->fb_fillrect(info, whole_screen);
} else {
/* Nothing avaiable. Use set the colormap to black */
}
What do you think?
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
I'm not sure this "set var" business has been thought out as much as it
should be.
<snip>
I see it coming. With the next set of changes it will be possible to
have fbdev with the VT system. So I have been putting into place the
ability to power down the framebuffer via the ioctl. So I want the flow
to be with fbcon from high level console to fbcon layer to fbdev driver.
Without fbcon to go from userland to the fbdev driver directly.
Also we have mode changing. Soon I will add hooks to the VT layer to
allow use to change a single VC via stty. VT_RESIZE can replace the
current method of changing the size of all VCS instead of the fbdev layer
doing it.
So you will see the necessary changes to handle all this.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf