Subject: Re: qtopia
To: Garrett D'Amore <email@example.com>
From: Michael Lorenz <firstname.lastname@example.org>
Date: 06/03/2006 16:43:16
-----BEGIN PGP SIGNED MESSAGE-----
>>>> Even with a single output port (typically VGA) you
>>>> have the questions of detecting monitor resolutions, virtual vs.
>>>> physical resolutions (you can use a much bigger virtual desktop with
>>>> panning), and e.g. autoexpansion to drive a lower resolution on a
>>>> higher resolution monitor (ratiometric expansion that is supported
>>>> on Radeon
>>>> and perhaps other devices.)
>> And then there are things like the FFB which support multiple colour
>> depths on the same screen.
> Hmm... so its not a linear framebuffer I guess? Or does it use some
> weird combination of indexing and 24bpp?
Several more or less linear framebuffer views, a few in 8 bit, others
in 24/32 bit, and some control planes. Depends on the chip - the tcx
has three views - 8bit, 32bit, control, the ffb has a few more, like
framebuffer views with or without rasops being carried out on whatever
you write etc.
>>>> It might also be nice to have an event call back so that
>>>> can detect monitor changes. E.g. some boards have a way to check
>>>> the existence of a monitor. (And DVI/TMDS actually has pins
>>>> defined for the purpose.) But maybe we can leave this a poll
>>>> interface for now.
>> Yes, tctrl actually does that and enables the VGA port when it detects
>> a monitor.
> Interesting. I should take a look at that.
the microcontroller sends a message when it detects a change, i simply
catch it and enable or disable the port.
>>>> No doubt I've missed things. I've not tried to implement any of
>>>> this - this is all just intended to act as food for thought. Let
>>>> me know your
>> I think video mode and colour depth should be programmed
>> independently, especially with boards that support multiple depths
> I'm reasonably okay with that, I think. The considerations here are as
> * changing _either_ depth or resolution changes the memory layout in
> * some cards have limitations that are imposed by the combination of
> resolution and depth. (I.e. can run at SXGA at 16bpp, but only XGA or
> 24bpp or somesuch, depending on available memory)
Exactly, we should have a list with supported resolutions and then
supported colour depths for each.
> The other interesting piece in here is for OLPC, where they have a
> display that can do either mono/grayscale or color depending on power
> conditions. I have no idea how exactly that works, but I can see it
> breaking whatever abstraction we're likely to come up with. :-)
> FWIW, I only bother to run radeon at 32-bpp. I can't see a compelling
> reason to run it lower resolution. (At this resolution I can still run
> even the lowest end board at 1920x1200 on two independent displays.
> They don't come with less than 32MB, AFAIK.)
I'm thinking about machines where the firmware sets up the graphics
display, usually whatever resolution it considers 'native' in 8 bit. I
see no real reason to switch to something higher just for text display
- - on older hardware using more than 8 bit may be considerably slower -
that's why I want colour depth switching. Leave the display timing,
resolution etc. alone.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
-----END PGP SIGNATURE-----