dynamic LCD support for "embedded" systems

dynamic LCD support for "embedded" systems

[Luke Kenneth Casson Leighton]

[wookey: taking the liberty of cc'ing your message to lkml]
[lkml: this came from an announcement of debian packages for toshiba ac100]

On Mon, Jul 25, 2011 at 11:26 AM, Wookey <wookey@wookware.org> wrote:
> +++ Luke Kenneth Casson Leighton [2011-07-25 10:13 +0100]:
>>  question:
>>
>>  what is the best way to actually take into account, *without*
>> requiring a total recompile of the linux kernel, *without* requiring a
>> rebuild of any debian gnu/linux packages, variations in LCD screen
>> size when the "norm" is that both the LCD and the data structures in
>> the linux kernel are typically static and non-changeable?
>
> That's a question that has bugged me for a long time too.
>
>>  in some ways this is a rhetorical / leading question (but isn't
>> really) - i'm aware that there's usually an I2C ROM or other mechanism
>> for reading EDID data off of the LCD panel, to obtain its size... it's
>> just that this simply isn't done in the linux kernel source code
>> itself.
>
> And sometimes there isn't even that (SFAIK). With a direct LCD connection
> sometimes it's just a matter of what's plugged in. Ballon could have 4
> different displays 3 LCD lanels or a VGA monitor-hack (to get monitor
> signals out of the LCD connector). And I never worked out how to
> switch between displays without making a new kernel, because
> everything was clearly designed on the assumption that if the display
> was LCD then it was of a fixed type.
>
> This is really a question for the kernel list rather than debian-arm.
> I keep hoping some infrastructure for better switching and magic-id
> would appear. Maybe it has for all I know, and I missed it. (I last
> looked at this some time ago).

 ok, so.  does anyone on LKML happen to know if there exists in the
linux kernel a method for dynamic detection and booting off of
absolutely any type of LCD panel?  even if it's a predefined list of
say 10 quotes supported quotes static LCD panels?

 the reason i ask is because although the original request was about
one and only one person ever having publicly reported that they
successfully upgraded their toshiba ac100 tegra2-based laptop to a
decent human-useable 1280x768 LCD panel, i have been working for over
a year to bring about user-hot-swappable CPU "modules" where you would
be able to buy that CPU "module" off-the-shelf in a supermarket and
plug it quite literally into any chassis: 7in tablet, 10in laptop,
desktop PC you don't _give_ a monkey's "it just works".  and under
these circumstances, the present static LCD data structure declaration
system in the linux kernel source code is a recipe for absolute hell
on earth.

 ideas anyone?

 tia,

 l.

 p.s. linus - this is another example of where the complete total
utter lack of hardware standardisation and of the complete
non-existence of a BIOS in the embedded / ARM world (for very good
technical reasons) makes life continued and absolute hell.  ref:
https://lkml.org/lkml/2011/7/1/473

Re: dynamic LCD support for "embedded" systems

[Alan Cox]

>  ok, so.  does anyone on LKML happen to know if there exists in the
> linux kernel a method for dynamic detection and booting off of
> absolutely any type of LCD panel?  even if it's a predefined list of
> say 10 quotes supported quotes static LCD panels?

It depends entirely on the platform, the interconnect, the panel and the
controller. You may have a way of probing it, but even on a PC in a lot
of cases the knowledge is actually in the firmware not in the panel
itself. In some cases the relationship is even more incestuous (eg look
at some of the MIPI drivers).

>  p.s. linus - this is another example of where the complete total
> utter lack of hardware standardisation and of the complete
> non-existence of a BIOS in the embedded / ARM world (for very good
> technical reasons) makes life continued and absolute hell.  ref:
> https://lkml.org/lkml/2011/7/1/473

Well really the panel belongs in devicetree. That would I think sort much
of the mess out.

Alan

Re: dynamic LCD support for "embedded" systems

[Luke Kenneth Casson Leighton]

On Mon, Jul 25, 2011 at 1:17 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>>  ok, so.  does anyone on LKML happen to know if there exists in the
>> linux kernel a method for dynamic detection and booting off of
>> absolutely any type of LCD panel?  even if it's a predefined list of
>> say 10 quotes supported quotes static LCD panels?
>
> It depends entirely on the platform, the interconnect, the panel and the
> controller. You may have a way of probing it, but even on a PC in a lot
> of cases the knowledge is actually in the firmware not in the panel
> itself. In some cases the relationship is even more incestuous (eg look
> at some of the MIPI drivers).

 euurgh, inspire me with confidence, why not? :)  yes, virtually every
datasheet for an RGB/TTL LCD panel i've looked at has EDID data which
is typically accessible over an I2C bus.  hilariously (ok maybe not)
i've heard of manufacturers getting this data wrong.  then, you
_still_ need some offsets (the Horizontal and Vertical tuning which
you simply don't have on an embedded LCD panel - there's no buttons
and no adjustment menu on an embedded system!)

 ... but, think about it: that LCD panel goes into a VGA monitor (or
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.

 so, basically, unless you absorb the capabilities of a VGA monitor
*into* the linux kernel and/or the OS running on top of it (think of
that menu system on a VGA monitor), as well as the capabilities
normally offered by a PC "BIOS", true "dynamic" LCD capabilities on an
embedded system - to adapt to literally any LCD panel - are a
pipe-dream.

 so *sigh* that means having a list of static pre-arranged data
structures associated with pre-vetted pre-tested LCD panels (and
identifying them correctly).

> Well really the panel belongs in devicetree. That would I think sort much
> of the mess out.

 *lol* yehhs... drag hundreds of chinese tablet manufacturers kicking
and screaming into the C21st^H^H^H^H^H device tree era - oh god i hope
it's not 2.4 kernel all over again [note for people who may not be
aware: in the embedded world, the 2.4 linux kernel, especially the
2.4.18 and 2.4.20 ones, had a massively extended lifetime because of a
significant performance drop, and increases in compiled size and also
resident memory usage over the 2.6 kernel.  2.4 kernels could be 600k
compiled whilst 2.6 with the exact same options came out at 900k]

 but seriously: i talked with david (from linaro) a few months back,
and he mentioned what the aims of devicetree are, and yes i believe
it's an excellent technical solution, into which something like
dynamic LCD panel startup would fit very well.

 oh.

 wait.

 i have an idea.

 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?

 thanks alain.

 l.

Re: dynamic LCD support for "embedded" systems

[Alan Cox]

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

Re: dynamic LCD support for "embedded" systems

[Luke Kenneth Casson Leighton]

On Mon, Jul 25, 2011 at 2:06 PM, Alan Cox <alan@lxorguk.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.

Re: dynamic LCD support for "embedded" systems

[Peter Korsgaard]

>>>>> "Alan" == Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

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

 Alan> I'm not convinced it is the same stuff for various reaosns and bits of
 Alan> historical bug fixing and observation.

Indeed. Often, raw LVDS panels just have power, LVDS and (potentially)
backlight signals - No EDID. eDP panels might be different though, and
some newer LVDS panels do have a DDC channel with EDID.

-- 
Bye, Peter Korsgaard

Re: dynamic LCD support for "embedded" systems

[Luke Kenneth Casson Leighton]

On Mon, Jul 25, 2011 at 1:40 PM, Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:

>  i have an idea.
>
>  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?

 sorry to be following-up to my own posts: thought-continuation error,
Does Not Compute :)

 ok, the context is as follows:

 * plugnpray CPU module, de-facto standard interface(s), USB2, I2C,
Ethernet, LCD, GPIO, blah blah
 * Motherboards (conforming to de-facto standard interface), but apart
from that, can be any design.

 examples:

 * CPU module Cortex A8, 1gb RAM
 * CPU module Cortex A9, 1gb RAM
 * CPU module MIPS Ingenic jz4770
 * Motherboard 7in tablet, 800x480 LCD
 * Motherboard 11in laptop, 1280x768 LCD
 * Desktop PC (VGA or DVI converter on LCD data)

 i.e. radically different CPU modules, and radically different motherboards.

 that's the context.

 question: how the bloody hell do you make sure that any of the CPU
modules can plug into any of the motherboards... *including* future
CPU modules and including *unknown* motherboards yet to be designed..
and actually boot up the LCD. correctly.

  i thought: yeah, yeah, make a devicetree-compliant dynamic module,
put it on some storage on the motherboard: CPU module boots up, mounts
the motherboard storage, loads the module, everything hunky-dory.

 except... then you're into "linux kernel upgrade hell".  and you'd
have to have, pre-loaded on the motherboard storage, a
devicetree-compliant LCD dynamic module for 2.6.N for MIPS, another
one for the 2.6.N Cortex A8 CPU(s) ... no, it's hell on earth.

 but then it occurred to me... well... why bother having that data in
a kernel module (esp. if it has to go on a filesystem anyway), why not
just have that LCD data in a text file?   somewhere in
/lib/firmware/edid_data or something like that?

 so, you go through the heuristics-process (arnaud's just kindly
described some of what is needed here:
http://lists.debian.org/debian-arm/2011/07/msg00054.html ) and then
you go look up the actual required LCD settings off of
/lib/firmware/{somewhere}, drop them into the one generic (and
statically-loaded, yaay!) devicetree-compliant module, everything's
hunky-dory.

 does that sound like a reasonable plan, or have i completely lost
everyone at this point? :)

 l.