From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
Cc: debian-arm@lists.debian.org, linux-kernel@vger.kernel.org,
Wookey <wookey@wookware.org>
Subject: Re: dynamic LCD support for "embedded" systems
Date: Mon, 25 Jul 2011 14:06:10 +0100 [thread overview]
Message-ID: <20110725140610.47fdda27@lxorguk.ukuu.org.uk> (raw)
In-Reply-To: <CAPweEDzQXUTtAwiU4qEB_eQqNgJeazpeTxixyAnbgscvC5yujQ@mail.gmail.com>
> 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.
> 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. 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.
next prev parent reply other threads:[~2011-07-25 13:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-25 11:58 Luke Kenneth Casson Leighton
2011-07-25 12:17 ` Alan Cox
2011-07-25 12:40 ` Luke Kenneth Casson Leighton
2011-07-25 13:06 ` Alan Cox [this message]
2011-07-25 13:18 ` Luke Kenneth Casson Leighton
2011-07-25 13:32 ` Peter Korsgaard
2011-07-25 13:12 ` Luke Kenneth Casson Leighton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110725140610.47fdda27@lxorguk.ukuu.org.uk \
--to=alan@lxorguk.ukuu.org.uk \
--cc=debian-arm@lists.debian.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkcl@lkcl.net \
--cc=wookey@wookware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®