[PATCH] fbdev: Implement simple blanking in pseudocolor modes for

[PATCH] fbdev: Implement simple blanking in pseudocolor modes for

[Alexey Charkov]

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)

Re: [PATCH] fbdev: Implement simple blanking in pseudocolor modes for vt8500lcdfb

[Paul Mundt]

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.

Re: [PATCH] fbdev: Implement simple blanking in pseudocolor modes for vt8500lcdfb

[Geert Uytterhoeven]

On Wed, Jan 12, 2011 at 23:14, Alexey Charkov <alchark@gmail.com> 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 <adaplas@hotpop.com>
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 <adaplas@pol.net>
    Signed-off-by: Andrew Morton <akpm@osdl.org>
    Signed-off-by: Linus Torvalds <torvalds@osdl.org>

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

Re: [PATCH] fbdev: Implement simple blanking in pseudocolor modes for vt8500lcdfb

[Paul Mundt]

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.