At 11:23 PM -0500 12/13/04, Tim Kelly wrote:
>Even more extreme, in Brian Hechinger's case, ofb0 was attaching to a video
>card that didn't even have a node in OF, due to some as yet unresolved
>issue. The real OF console was /chaos/control, at ofb1.

More specifically, with the existing ofb.c code, Brian was seeing

ofb0 at pci0 dev 13 function 0: ATI Technologies Radeon 7000/VE
ofb0: 640 x 480, 8bpp
wsdisplay0 at ofb0 kbdmux 1: console (std, vt100 emulation)
wsmux1: connecting to wsdisplay0
...
ofb1 at pci1 dev 11 function 0: Apple Computer Control
ofb1: 640 x 480, 8bpp
wsdisplay at ofb1 not configured

The ATI card was discovered (by the kernel) through PCI device discovery,
not through OF. The reason this attracted my attention is because I had
been asked why the card was not getting a node in the OF tree (for which I
do not have an answer).

The kernel was claiming that the wsdisplay was the ATI card, but the video
out was going to /chaos/control. Since GENERIC has wsdisplay0 hard wired,
only one wsdisplay will be attached, and in this case, it was attached to a
device with no OF and was not even recognized by OF. All of the display
values were based on what /chaos/control configured.

After the ofb.c patch, he now has

ATI Technologies Radeon 7000/VE (VGA display) at pci0 dev 13 function 0 not
configured
...
ofb0 at pci1 dev 11 function 0: Apple Computer Control
ofb0: 640 x 480, 8bpp
wsdisplay0 at ofb0 kbdmux 1: console (std, vt100 emulation), using wskbd0
wsmux1: connecting to wsdisplay0

(edited to remove debugging messages)

tim