Subject: proplib and wsdisplay drivers
To: None <email@example.com>
From: Michael Lorenz <firstname.lastname@example.org>
Date: 12/17/2006 00:12:36
-----BEGIN PGP SIGNED MESSAGE-----
the way we currently implement wsdisplay drivers has a few serious
drawbacks which force us to put machine dependent code into otherwise
1. determining if the resp. device is going to be console
Currently each driver has to decide that for itself. This is fine for
SBus drivers where we can always assume some sort of OpenPROM or
OpenFirmware but it's intolerable on pretty much anything else,
especially PCI. For instance, on macppc we'd ask OpenFirmware. On
sparc(64) we'd use promlib. I have no ides how i386 determines which
PCI display device becomes console, if any. A driver /should be told/
wether it's going to become console or not, this decision needs to be
moved into MD code, out of MI drivers.
2. framebuffer parameters
Same again, we might want to re-use whatever the firmware set up but
the way to determine this involves either talking to the firmware which
is MD ( and on macppc you even get different properties on different
graphics devices, like 'width' on most but 'screen-width' on some etc.
) or somehow get the video mode out of the chip in question. If we ever
want to implement a really hardware-independent dumb framebuffer driver
we need a clean, MI way to find framebuffer parameters. Besides that
some firmware supports stuff like DDC2 - I've seen this on sparc64 and
some macppc machines, passing those to the driver needs to be
3. picking video modes
No matter if we're going to recycle what the firmware set up or switch
to something the user passed as kernel parameter - currently there is
no way to tell the kernel to run a graphical console in a given video
mode. MI drivers shouldn't have to decide which mode to use - they
should be told by (probably) MD code. And whatever finally decides
should be overridable by kernel parameter.
To deal with this I propose the following:
All platforms that use graphical consoles on more or less MI bus
systems are required to implement device_register(), intercept all
attachments of potential console output devices, determine if any of
them is going to be system console in whatever way is appropriate on
the resp. platform and add the following property to the device's
'is_console', type bool, can be true on up to one device.
A driver is going to become console only when it finds 'is_console'
with the value 'true' in its dictionary.
If the firmware or anything set up a usable graphics mode add the
'width', 'height', 'linebytes' - width and height in pixels, line size
'depth' - colour depth in bits
'address' - physical address of the framebuffer ( or rather, address of
the upper left pixel )
we'll probably need more properties to support less than 8 bit,
amiga-like interleaved bitmaps etc. the properties mentioned above are
essentially what OpenFirmware gives us, usually in 8 bit.
We may also need to define names and formats for
- - refresh rate in Hz. Or maybe a whole modeline resp. struct videomode?
- - EDID data from DDC or DDC2 compatible monitors ( most driver will
implement DDC/DDC2 themselves but that's not always possible or
feasible, an example for this is machfb. Sun firmware implements DDC
but machfb can't do it for various reasons ( lack of documentation,
gazillions of variations among different mach64 chips etc. ) - it would
be nice if we could use the firmware-provided EDID data in a MI way )
- - monitor constraints. Some iMacs and eMacs have rather weird monitors
which require fixed line frequencies, those monitors don't provide EDID
but we can deduce the monitor type from the firmware-provided model
name. We'd need an MI way to pass either monitor parameters or a
specific video mode here since not all drivers are happy with whatever
the firmware set up ( radeonfb is such an example - it really only
works properly in 32bit colour so until someone with access to ATI docs
fixes that we need to work around it )
I did the conversion on macppc for the machfb and chipsfb drivers,
changes are mostly trivial. What's missing is a way to pass a video
mode as kernel parameter.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
-----END PGP SIGNATURE-----