Implement simple blanking in pseudocolor modes for vt8500lcdfb
This follows the style of some other in-tree drivers by just setting
the hardware palette colors to all black. True Color modes are not
affected, but this at least allows to run xf86-video-fbdev without
errors due to blanking being unimplemented.
Signed-off-by: Alexey Charkov <alchark@gmail.com>
diff --git a/drivers/video/vt8500lcdfb.c b/drivers/video/vt8500lcdfb.c
index 7617f12..0e120d6 100644
--- a/drivers/video/vt8500lcdfb.c
+++ b/drivers/video/vt8500lcdfb.c
@@ -215,6 +215,33 @@ static int vt8500lcd_pan_display(struct fb_var_screeninfo *var,
return 0;
}
+/*
+ * vt8500lcd_blank():
+ * Blank the display by setting all palette values to zero. Note,
+ * True Color modes do not really use the palette, so this will not
+ * blank the display in all modes.
+ */
+static int vt8500lcd_blank(int blank, struct fb_info *info)
+{
+ int i;
+
+ switch (blank) {
+ case FB_BLANK_POWERDOWN:
+ case FB_BLANK_VSYNC_SUSPEND:
+ case FB_BLANK_HSYNC_SUSPEND:
+ case FB_BLANK_NORMAL:
+ if (info->fix.visual = FB_VISUAL_PSEUDOCOLOR ||
+ info->fix.visual = FB_VISUAL_STATIC_PSEUDOCOLOR)
+ for (i = 0; i < 256; i++)
+ vt8500lcd_setcolreg(i, 0, 0, 0, 0, info);
+ case FB_BLANK_UNBLANK:
+ if (info->fix.visual = FB_VISUAL_PSEUDOCOLOR ||
+ info->fix.visual = FB_VISUAL_STATIC_PSEUDOCOLOR)
+ fb_set_cmap(&info->cmap, info);
+ }
+ return 0;
+}
+
static struct fb_ops vt8500lcd_ops = {
.owner = THIS_MODULE,
.fb_set_par = vt8500lcd_set_par,@@ -225,6 +252,7 @@ static struct fb_ops vt8500lcd_ops = {
.fb_sync = wmt_ge_sync,
.fb_ioctl = vt8500lcd_ioctl,
.fb_pan_display = vt8500lcd_pan_display,
+ .fb_blank = vt8500lcd_blank,
};
static irqreturn_t vt8500lcd_handle_irq(int irq, void *dev_id)On Thu, Jan 13, 2011 at 01:14:44AM +0300, Alexey Charkov wrote:
Implement simple blanking in pseudocolor modes for vt8500lcdfb
This follows the style of some other in-tree drivers by just setting
the hardware palette colors to all black. True Color modes are not
affected, but this at least allows to run xf86-video-fbdev without
errors due to blanking being unimplemented.
Signed-off-by: Alexey Charkov <alchark@gmail.com>
Applied, thanks.
On Wed, Jan 12, 2011 at 23:14, Alexey Charkov [off-list ref] wrote:
Implement simple blanking in pseudocolor modes for vt8500lcdfb
This follows the style of some other in-tree drivers by just setting
the hardware palette colors to all black. True Color modes are not
affected, but this at least allows to run xf86-video-fbdev without
errors due to blanking being unimplemented.
Hmm, I seemed to remember this was handled at the generic level if no .fb_blank
implementation was present? That's why e.g. vesafb and macfb don't
have an fb_blank
implementation, while people run/ran X on them for sure.
[ looking in the code and its history ]
According to full-history-linux, it was removed by:
ommit ca2efeeb715e9fc0f12e57b54ba43ee1e1e50524
Author: Antonino Daplas [off-list ref]
Date: Sun Nov 7 04:05:04 2004 -0800
[PATCH] fbcon: "Do not touch hardware if vc_mode != KD_TEXT: fix
Sigh, this patch uncovered a can of worms. I tested different combinations,
those with/without xxxfb_blank implementation, framebuffers in directcolor
or truecolor, etc. I find that there is a problem unblanking if the hardware
has no xxxfb_blank() implementation, and also that the generic fb_blank() in
fbmem.c is problematic with drivers in directcolor or pseudocolor mode when
called by an fb application such as X.
Display blanking is implemented in three ways:
1. using the drivers blanking implementation - info->fbops->fb_blank()
2. clearing the screen with the console erase character - fbcon_blank()
3. setting the color map to all black - fb_blank()
The third method is problematic for these reasons:
- Setting the colormap to all black will not work in truecolor mode
- In directcolor or pseudocolor, it will overwrite the fb application's
color map, producing wrong colors.
So, remove the generic implementation in fb_blank() and just return -EINVAL
if there is no hardware implementation. This will be only used by apps doin
an FBIO_BLANK ioctl, and is a more robust approach.
Other changes:
- Consolidated all tests and created an inlined helper function to check if
the framebuffer console is inactive or not.
- fix unblanking if driver has no xxxfb_blank() hook.
I'm probably missing a few more things, but this patch should be generally
correct. Please apply after the entire patch series to avoid rejects.
Signed-off-by: Antonino Daplas [off-list ref]
Signed-off-by: Andrew Morton [off-list ref]
Signed-off-by: Linus Torvalds [off-list ref]
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
On Thu, Jan 13, 2011 at 07:03:43AM +0100, Geert Uytterhoeven wrote:
The third method is problematic for these reasons:
- Setting the colormap to all black will not work in truecolor mode
- In directcolor or pseudocolor, it will overwrite the fb application's
color map, producing wrong colors.
So, remove the generic implementation in fb_blank() and just return -EINVAL
if there is no hardware implementation. This will be only used by apps doin
an FBIO_BLANK ioctl, and is a more robust approach.
The in-tree drivers that implement the blacking out also don't really
seem to agree on the implementation, with some having more complex
requirements for prodding their controllers than others (such as pxafb).
I'm fairly ambivalent about it however. If people are actively testing X
on their drivers with these configurations and are willing to deal with
the potential issues and restrictions it comes along with, then I don't
mind plugging it in to individual drivers that wish to opt in.
Having a default -EINVAL remains the safest bet in terms of general
correctness, but if this results in an X fbdev driver that is unusable
for most people, then we're still going to have to come up with an
alternative solution.