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] [day] [month] [year] [list]
Date:	Thu, 13 Jan 2011 15:17:43 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:	Alexey Charkov <alchark@...il.com>, 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 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.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ