linux-kernel - Re: dynamic LCD support for "embedded" systems

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:	Mon, 25 Jul 2011 14:18:38 +0100
From:	Luke Kenneth Casson Leighton <lkcl@...l.net>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	debian-arm@...ts.debian.org, linux-kernel@...r.kernel.org,
	Wookey <wookey@...kware.org>
Subject: Re: dynamic LCD support for "embedded" systems

On Mon, Jul 25, 2011 at 2:06 PM, Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
>> DVI monitor), and that EDID data just gets passed-through via the VGA
>> IC. so it's all the same stuff... so what's the damn difference
>> between a system with a VGA monitor and a system with the exact same
>> LCD panel *from* that VGA monitor, ehn? :)  ok, rhetorical question.
>
> I'm not convinced it is the same stuff for various reaosns and bits of
> historical bug fixing and observation.

 yehhs... and arnaud's post also provides some more background, which
includes in some cases intermediate ICs that trash / strip out the
required info.  classic...

 http://lists.debian.org/debian-arm/2011/07/msg00054.html

>>  devicetree LCD modules.  these could still be dynamically loaded,
>> right?  i mean, it's a bit crazy, but you could have associated with a
>> particular LCD panel a devicetree-compliant dynamic loaded module
>> which had the correct LCD settings (including the required pre-tested
>> hsync and vsync data), right?
>
> In theory, or passed to the kernel at boot.

 he-he that's not user-friendly, alain :)  the context is a
mass-produced device.

> The obvious long term path I
> would have thought would have been to move to 'device tree if data present
> else...' in the various panel drivers. That way there are no sudden bumps
> in the road for distributors but a device tree data set from any source
> would trump the data extracted by other means.

 ok.  right.  whew.  a migration path.  thank god for that.  no
terrifying all-convert-to-devicetree-or-die approach, then.  shaaame
:)

 l.
--
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/