[Arm-netbook] (unofficial) Debian packages for Toshiba AC100 (Tegra; armel and armhf)
gordan at bobich.net
Mon Jul 25 15:40:47 BST 2011
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
changes? When I upgraded the screen in my Genesi Efika Smartbook to
1280x720 (see here: http://www.altechnative.net/?p=152 ) I also tried
upgrade the screen on my AC100, using the same panel, and also using a
1366x768 panel didn't work at all (blank screen).
1280x720 panel showed a perfect 1024x600 picture in the top left
Forcing the modeline in xorg.conf to 1280x720 produced a scaled down
of what 1280x720 would look like in the same 1024x600 field in the top
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
and anti-useful bodge, but given that nvidia aren't renowned for
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
what is programmed into it's EDID rather than what is hard-coded into
> what is the best way to actually take into account, *without*
> requiring a total recompile of the linux kernel, *without* requiring
> 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
> for reading EDID data off of the LCD panel, to obtain its size...
> just that this simply isn't done in the linux kernel source code
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
Sorry, but unless you have access to the firmware code for Tegra,
More information about the arm-netbook