-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

>>>> 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
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iQEVAwUBRIH0ZcpnzkX8Yg2nAQIUSQf6AwLmEw0J5wbz0u/gMj8Dd/ryKdWpe6f+
CXySmaHm23TkOMTFhoYOlevpmQRijq1lTDckIwi3RIWtF9nrb0+/sq/8IaAibUdT
di6owmxEy/3bTypcRFVsrU4P4Kv/W1SwwodZb+y6l3yVjE7I2jm0MJJhGYcA0G2T
LVmQug8N7gtBgHct9LawftgnuUGRtzfAHVVTgzB1iCbGS27dHVQxAszu8VMUN57P
gFlbddCMf7yTll8yXwdzowjOwasp4LflwOkHO7wiXTiUnkyg8YGGBi0e9gFgj0Rc
KFWW//OKXuQWzDq6FRP/poICLm9PHe5EU7jAY2W1JJGsrsaVeHop8w==
=n6Qi
-----END PGP SIGNATURE-----