Michael Lorenz wrote:
> Hello,
>
> there as been some talk about getting qtopia to work on wscons - is
> anyone actually working on it? If so - which version? I might be
> inclined to use my sparcbook as testbed, besides that it would be an
> obvious target for a generic graphics acceleration framework we've
> been talking about as well.
>
> And finally we'll need ways to switch colour depth and video modes
> from userland, at least the former is simple enough. What about
> something like
> ioctl(fd, FBIOSCDEPTH, &bits_per_pixel)
> and
> ioctl(fd, WSDISPLAYIO_SCDEPTH, &bits_per_pixel)
> ?
>
> They would be useful on the P9100 to actually switch colour depth, on
> things like ffb, tcx etc. they could select which colour plane we
> mmap() - 8 or 24 bit.  Things like the cg6 would just ignore it.

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

I should probably write a paper describing this all, but here's a first
pass strawman:

#define   MAXMODES 64
struct wsdisplayio_modelist {
    int nmodes;
    struct videomode   preferred;
    struct videomode   list[MAXMODES];
}


struct wsdisplayio_port {
    int  nport;
    int   flags;
    int   type;   // port type, VGA, DVI, etc
    int   xres;   // virtual resolutions used with panning
    int   yres;
    int  hpos;   //  Xinerama-like offsets
    int  vpos;
    struct wsdisplayio_modelist   modes;
}
#define    WSDISPLAY_PORT_FIXED_RESOLUTION   // for native panels with a
fixed resolution
#define    WSDISPLAY_PORT_PAN
#define    WSDISPLAY_PORT_NPRESENT   // no display plugged in, if can
detect that

#define    WSDISPLAY_PORT_VGA            // external VGA port
#define    WSDISPLAY_PORT_DVI            // external DVI port
#define   WSDISPLAY_PORT_BUILTIN   // ala LVDS or builtin panels
#define   WSDISPLAY_PORT_SVIDEO
#define   WSDISPLAY_PORT_COMPOSITE
#define   WSDISPLAY_PORT_RGB         // old Red/Green/Blue cables
#define   WSDISPLAY_PORT_HDMI
#define   WSDISPLAY_PORT_COMPONENT
#define   WSDISPLAY_PORT_13W3         // old sun monitors
#define   WSDISPLAY_PORT_OTHER

// Hmmm.... should we support using GTF/CVT to support *arbitrary
modes*?  For now I think an enumeration is sufficient.

#define WSDISPLAY_MAXPORTS   4

struct wsdisplay_mode {
    int   xres;
    int   yres;
    int  bpp;
}

int count;
struct wsdisplay_port port;
struct wsdisplay_port mode;

icotl(fd, WSDISPLAY_GNPORTS, &count);
ioctl(fd, WSDISPLAY_GPORTINFO, &port);
ioctl(fd, WSDISPLAY_SPORTINFO, &port);
ioctl(fd, WSDISPLAY_GMODE, &mode);
ioctl(fd, WSDISPLAY_SMODE, &mode);
ioctl(fd, WSDISPLAY_GMAXMODE, &mode);   // query limits of board for
virtual resolutions

By default, setting the mode with SMODE would assume reasonable defaults
for port configuration, which could then be changed for individual ports
(VGA, DVI, LVDS, TV-out, whatever).

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

These ioctls (GPORTINFO in particular) can make use of EDID gathered
data to query physically connected ports.  Basically, the driver should
return a list of valid modes along with

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.

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.

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