Re: [Arm-netbook] (unofficial) Debian packages for Toshiba AC100 (Tegra; armel and armhf)
On Mon, 25 Jul 2011 10:13:35 +0100, Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
On Sun, Jul 24, 2011 at 9:24 PM, Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
On Fri, Jul 22, 2011 at 4:42 PM, Julian Andres Klode
<jak@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
Reply to: