Michael Lorenz wrote:
> Hello,
>
> >> I've been intending to add some WSDISPLAY ioctls for managing
> >> resolutions/modes.  The problem is a little stickier than you might
> >> suppose at first, especially when you consider devices with multiple
> >> output ports, etc.
>
> Oh, I'm aware of the stickiness, that's why there is no such API so far.

Well, we need to start somewhere....

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

>
> >> One thing missing is the ability to enable/disable active ports.  (I.e.
> >> save power by turning off VGA port on a laptop while using the internal
> >> screen.)
>
> Yeah, the sparcbook has two ports which show the same thing but can be
> powered up and down independently.

Yes, this is common with laptops.

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

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

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

    -- Garrett
>
> have fun
> Michael
>
> -- 
> Garrett D'Amore, Principal Software Engineer
> Tadpole Computer / Computing Technologies Division,
> General Dynamics C4 Systems
> http://www.tadpolecomputer.com/
> Phone: 951 325-2134  Fax: 951 325-2191
>