[Arm-netbook] (unofficial) Debian packages for Toshiba AC100 (Tegra; armel and armhf)

[Gordan Bobic]

 On Mon, 25 Jul 2011 10:13:35 +0100, Luke Kenneth Casson Leighton 
 <lkcl at lkcl.net> wrote:
> On Sun, Jul 24, 2011 at 9:24 PM, Luke Kenneth Casson Leighton
> <lkcl at lkcl.net> wrote:
>> On Fri, Jul 22, 2011 at 4:42 PM, Julian Andres Klode 
>> <jak at debian.org> wrote:
>>> I just finished the creation of a repository on people.debian.org
>>> that provides the packages needed to run Debian GNU/Linux on the
>>> Toshiba AC100 notebook device.
>>
>>  good call, julian!  btw do you happen to know of anyone who's
>> replaced the screen with a 1280x800 or even a 1200x720?
>
>  ok, julian: thank you to anders for notifying me that someone has in
> fact changed their LCD display on their toshiba AC100 to something
> that's actually useable for a programmer.  or a human.

 I must have missed the important part of the context here. Care to post
 the instructions, specifically the part relating to the low level 
 firmware
 changes? When I upgraded the screen in my Genesi Efika Smartbook to
 1280x720 (see here: http://www.altechnative.net/?p=152 ) I also tried 
 to
 upgrade the screen on my AC100, using the same panel, and also using a
 1366x768 panel.

 1366x768 panel didn't work at all (blank screen).

 1280x720 panel showed a perfect 1024x600 picture in the top left 
 corner.
 Forcing the modeline in xorg.conf to 1280x720 produced a scaled down 
 image
 of what 1280x720 would look like in the same 1024x600 field in the top 
 left.
 That means that somebody specifically made the firmware hard-coded to
 1024x600 and went out of their way to ignore EDID or any specific mode
 instructions to the frame buffer.

 I would love to see the detailed instructions on how to undo this 
 brain-dead
 and anti-useful bodge, but given that nvidia aren't renowned for 
 releasing
 code and given that I rather doubt that anybody would have bothered to
 reverse engineer Toshiba's abortion of a firmware, I'll believe it only
 when I see the firmware patch that enables the screen to function based 
 on
 what is programmed into it's EDID rather than what is hard-coded into 
 the
 laptop's firmware.

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

 Where on Earth did you get that? On the AC100 it is static in the
 firmware and has nothing to do with the Linux kernel or anything in
 userspace. EDID info that gets sent back is firmware's override, not
 what is actually in the EDID. The screen gets locked into 1024x600
 before the kernel boots. Hold down the home key at boot time and
 wait for the firmware boot prompt (recovery vs normal startu) and
 you will see that this happens BEFORE the kernel loads.

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

 Wrong. It is read by the kernel's FB drivers, and by everything else
 that needs access to it (e.g. xorg). The problem in the AC100 is that
 some intellectually challenged individual broke it in firmware by
 overriding EDID access.

>  2ndary question: has anyone encountered any linux kernel source code
> where reading of the LCD panel's I2C ROM is actually done and used to
> correctly start up whatever quotes embedded quotes LCD panel is
> attached to the device?

 For starters, if it was just a kernel issue, it wouldn't be affecting
 xorg, and it most certainly wouldn't be overriding xorg's explicitly
 specified mode-lines.

 Sorry, but unless you have access to the firmware code for Tegra,
 you're SOL.

 Gordan