behold: Rudolf's corner

I've been playing around a lot lately with multiple graphicscards in one system, seeing what happens if you try to use the second (or tertiary or whatever) card in there. It turns out to be quite interesting, a lof of things happen I didn't really expect.


What card will be used by the BeOS to display the Desktop?
If you start a terminal session, and type:
ls -l /dev/graphics
You'll get a list of kerneldrivers currently loaded for graphicscards. The first one listed is tried first by BeOS. If it determines that one doesn't work, it will try the second one listed etc. 'Stub' is not a real driver, but a fallback option to display your Desktop if no suitable real driver is found.

How does a driver signal that it won't work?
This is rather interesting, and rather unspecified. remember, a driver consists of two parts: the kerneldriver and the accelerant. The kerneldriver is the one creating the /dev/graphics/ entries.
So: the system (app_server) tries to open the kerneldriver first. Some closed source drivers will block more than one open instance.
- The matrox driver(s) do this to signal that the card in question is already in use: handy for me if I want to determine which cards are still free for a video consumer node for instance.
- However: the sis driver does this if it determines that the card can't be made to work: i.e. it sees that this card wasn't coldstarted by the system BIOS (displaying POST messages etc). The sis driver itself doesn't feature internal coldstart support, so if a sis card is non-primary according to your system BIOS, the driver will signal that it can't be used.

While I personally like the first 'feature', I don't really like the second one: it's likely that a accelerant will be the better place to check if a card can be really used: the kerneldriver's functionality should only be mapping the device: not *using* it.

On a sidenote I can tell you I tried converting the Haiku nVidia driver to use this signalling for 'being busy', but I miserably failed. I am no expert here, but it seems that the cookie managed by the system somehow is causing trouble. And besides: Be probably documented multiple-opens to be supported in their Graphics Driver kit for a good reason, although their own drivers (sometimes) work differently.

So, I modified the Accelerant's INIT_ACCELERANT and CLONE_ACCELERANT hooks to return B_NOT_ALLOWED in case the order of them being executed is not valid. Also I'll add aborting on unuseable cards later on in INIT_ACCELERANT.

Driver errors encountered during node development
For some reason most Be drivers can't seem to correctly identify their own hardware. Say you have two cards in a system, the desktop displayed on card 1, and card 2 not used. If you start using card 2, you might well discover that the driver for card 2 somehow gains access to card 1 and messes up it's programming. I have a feeling this has to do with non-system-wide-unique named areas mapped by the kerneldrivers.
Luckily the Haiku drivers don't have this issue: I guess the Be Alpha driver kit has a fix for this problem in it.

Other errors encounted were:
- Be SiS driver has overlay support, but it's broken. It supports single buffered overlay only, but vertical 'bars' of repeating video are shown instead of normal video. Also shutting of overlay doesn't work: once enabled it stays enabled.
- Be unified nVidia driver has broken GET_ACCELERANT_DEVICE_INFO hook: you need to issue it twice to get valid info (after that it's OK).
- DPMS state preservation over SetMode() calls is 'broken' on most Be drivers. Apparantly they didn't have time to update all of their drivers to what the alpha driver kit prescribes. (SiS driver is OK, nVidia and Matrox are 'broken'). BTW, I think preserving DPMS state is the way to go indeed. :-)


Well, that's about it I guess. This is the third time I am trying to write this 'article', so forgive me if I'm a bit sloppy. The fun in writing an article fades away fast if browsers and sites constantly mess-up...