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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 13 Jan 2011 07:03:43 +0100
From:	Geert Uytterhoeven <geert@...ux-m68k.org>
To:	Alexey Charkov <alchark@...il.com>
Cc:	Paul Mundt <lethal@...ux-sh.org>, linux-fbdev@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	vt8500-wm8505-linux-kernel@...glegroups.com
Subject: Re: [PATCH] fbdev: Implement simple blanking in pseudocolor modes for vt8500lcdfb

On Wed, Jan 12, 2011 at 23:14, Alexey Charkov <alchark@...il.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@...pop.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@....net>
    Signed-off-by: Andrew Morton <akpm@...l.org>
    Signed-off-by: Linus Torvalds <torvalds@...l.org>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/