Subject: proplib and wsdisplay drivers
To: None <>
From: Michael Lorenz <>
List: tech-kern
Date: 12/17/2006 00:12:36
Hash: SHA1


the way we currently implement wsdisplay drivers has a few serious 
drawbacks which force us to put machine dependent code into otherwise 
machine-independent drivers.
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 
following properties:
'width', 'height', 'linebytes' - width and height in pixels, line size 
in bytes
'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.

have fun
Version: GnuPG v1.2.4 (Darwin)