[fedora-arm] 1ghz ARM Laptop (12in 1280x800 LCD)

[Matt Sealey]

On Wed, Feb 2, 2011 at 9:30 AM, Luke Kenneth Casson Leighton
<luke.leighton at gmail.com> wrote:
> On Wed, Feb 2, 2011 at 1:41 PM, Gordan Bobic <gordan at bobich.net> wrote:
>>>  ARM CPUs don't have the concept of a BIOS, so the screen timings are
>>> hard-coded into the kernel driver.  you *can't* just whop a new screen
>>> in and expect it to work, you *have* to recompile the kernel,
>>> hard-coding the hsync, vsync, offsets, hclock, vclock, pixel rate,
>>> pixel density *everything*.
>>
>> So, I should blame the kernel for not reading the EDID on the panel?
>
>  the EDID data is generally completely ignored by the linux kernel for
> LCD panels, in embedded systems.  it's only typically when that panel
> ends up in an LCD monitor and shoved over DVI, HDMI or VGA by virtue
> of the IC controller chip having the necessary I2C logic that EDID
> data ends up being read.  but in embedded systems, changing the LCD
> panel _just_ doesn't happen, and the linux kernel source code for such
> devices typically reflects this by having the panel's settings
> hard-coded in.
>
>  so... yes :)

No, Luke. This is a complete misconception.

Most panels have EDID data that is perfectly valid.

Not reading the EDID is laziness.

99% of embedded panels expose the DDC lines to the host - you just
wire up an i2c controller. It is not common for the panel controller
(either LVDS or TMDS or whatever) to arbitrate access to the i2c bus
used for DDC except when HDCP is required (and accessing DDC data is a
violation of the security framework).

Embedded systems that have anything approaching a VGA sized panel
should be reading the EDID, but most devices *never* accept more than
one panel. In this case reading the EDID is redundant. Some developers
consider it a waste of time to plug in the one mode supported from the
EDID when they can copy the data from the spec sheet.

In the event a different panel is used, the EDID is the sole, only way
of differentiating between panels without additional hardware support
or having a kernel for each panel.

>> If you're right, then a
>> 720p panel may not be implausible. But my understanding is that the screen
>> gets setup by the boot loader, and the Tegra FB driver just works based on
>> that, it doesn't configure anything itself.
>
>  hmmm, that sounds about right.  and if you don't mind a bit of
> "bzzzt" and not being able to see anything during the boot process,
> you should be able to overwrite whatever crud settings the bootloader
> decided to set, once you've started the linux kernel.

The screen on the Smartbook is set up by the MTL017 driver. It's been
coded in Taiwan so it hardcodes the MTL017 configuration as an
unhealthy block of 256 byte values and just hammers the chip with it.
Genesi accepts that it is godawful way to do it and we are not happy
with the code we were provided with. But it does read the EDID so it
knows what panel data to send depending on the panel attached via the
EDID. We're rewriting it to use the EDID properly here.

-- 
Matt