Subject: Re: qtopia
To: Garrett D'Amore <>
From: Michael Lorenz <>
List: tech-kern
Date: 06/03/2006 16:43:16
Hash: SHA1


>>>> 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 
>>>> applications
>>>> can detect monitor changes.  E.g. some boards have a way to check 
>>>> for
>>>> 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
>>>> opinions.
>> I think video mode and colour depth should be programmed
>> independently, especially with boards that support multiple depths
>> simultaneously.
> I'm reasonably okay with that, I think.  The considerations here are as
> follows:
> * changing _either_ depth or resolution changes the memory layout in 
> the
> framebuffer
> * 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. :-)

Hmm, interesting.

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

have fun
Version: GnuPG v1.2.4 (Darwin)