At 7:11 PM -0800 12/13/04, Chuck Silvers wrote:
>this has the effect of not matching video cards that are not the console,
>is that the intent?

Specifically ofb*, yes.

>  if a machine has two video cards, shouldn't ofb
>attach to both of them?

Depends on the definition of an Open Firmware Frame Buffer (ofb). OF is
only looking at one of them if it's used as a console (and none if serial).
The current code actually retrieves the values from the stdout, with no
comparison at all that the particular PCI device being attached is the
actual console:

int
ofb_is_console()
{
int chosen, stdout, node;
char type[16];

     chosen = OF_finddevice("/chosen");
     OF_getprop(chosen, "stdout", &stdout, 4);
     node = OF_instance_to_package(stdout);
     OF_getprop(node, "device_type", type, sizeof(type));
     if (strcmp(type, "display") == 0)
           return 1;
     else
           return 0;
}

There's only one stdout, yet in the case of multiple video cards all of
them will indicate that they are the console in OF if only one of them is.
Since ofbattach has

console = ofb_is_console();

if (console) {
      dc = &ofb_console_dc;
      node = dc->dc_node;
      sc->nscreens = 1;
} else {
     stuff for non-console video

}

there is an expectation that ofb_is_console will return false, but all
ofb_is_console does is check if the stdout node is a display device and has
no connection to the device being attached. Under most circumstances, there
is only one video device and it is the console so this is not noticed. In
your case, and in Brian Hechinger's case, this is not true. If
ofb_is_console returns true when the non-console video card is being
attached, the ofb_devconfig *dc gets set to the ofb_console_dc.

In your case, since stdout is serial, neither card will return true for
ofb_is_console, and from there goes to ofb_common_init(node, dc); If the
card has no OF, quite likely at least one of the parameters will be -1 and
this device is not a true Open Firmware frame buffer display device.
However, the card has already attached as an ofb.

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.

>on my 9500 that has two video cards but boots with a serial console,
>this caused neither card to match.  we should make sure that it's still
>possible to run X in this case.  I've done this on sparcs and PCs before
>with netbsd, and it's very useful.

I'm not an expert on this aspect, but my thought would be that if the video
card is a PCI display type device it shouldn't be identified as an ofb
device ad hoc, as it is not guaranteed to fall under the services listed
for OF frame buffers specification. Some of the ofb discovery process falls
back to generic OF words when the node doesn't have the property. If the
video card has no OF, applying OF values to it seems inappropriate, and if
there is another display device with OF and that is used as the console,
the non-OF card gets values that are associated with the OF display. Even
frame-buffer-adr would point to an address on the OF card. This doesn't
sound like a good idea, IMHO (some would say "NS"HO).

It seems to me that one place the patch I posted could run into problems
would be with unaccelerated 8 bit X that falls back on a dumb frame buffer
to work, but there's no ofb0 because serial is the console. I have not
looked into how the dumb frame buffer is obtained in default configurations.

Certainly this is not an attempt to reduce functionality, but instead to
increase it by giving greater granularity over video devices and correct
associations of configuration data with each one.

tim