Re: (unofficial) Debian packages for Toshiba AC100 (Tegra; armel and armhf)
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: alain says, effectively (not literally) "kernel developers on
a per-device basis will need to make the decision to leverage the
capabilities of devicetree in the linux kernel source to solve this
one".
answer: no, you didn't miss it :)
within the devicetree framework, i suggest creating files (not in the
linux kernel at all) in somewhere like /lib/firmware/edid_data/ which
have the required info (on a per-hardware-device basis). no static
datastructures at all.
hey, you know what: actually... it'd probably fit quite well into
udev, as a new bus type. pci, usb, and now "lcd". same sort of
thing: you need rules which either detect the generic LCD type and
it's all happy, or you go "sod this: just use that one".
trouble is: that's quite a long way into the boot process to be
without an LCD, but, tough shit: as alain points out, you can always
override it. even with a kernel boot parameter, yeah i know i said
they're not suitable for mass-market, but "it don't work it need
diagnosing" ain't mass-market is it? :)
l.
Reply to: