[haiku-appserver] Cloning accelerant method

  • From: "Rudolf" <drivers.be-hold@xxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Thu, 04 May 2006 18:18:03 +0200 CEST

Hi Axel,

Just looked at your fix for that fixed graphics/vesa returned for 
BWindowScreen.
Here's something I encountered (but could not recreate myself)

All drivers written outside be will indeed probably adhere to this 
'quasi standard' as you put it. Mine do at least. Be's drivers however, 
do not. At least: not all of them.

We have the freedom to send over other stuff here. For instance, the 
file-descriptor of the already opened kerneldriver for the 'primary' 
accelerant. This is (as far as I understand) what Be did with it's 
Matrox drivers, and maybe others.

If you carefully examine their behaviour, you'll find this:
-kerneldriver: acepts just _one_ open. All others fail.
-accelerant: INIT_ACCELERANT gets the fd from the fileserver, it opened 
it this once that it's possible.
-if the accelerant gets cloned, the kerneldriver is _not_ re-opened a 
second time. Instead, it gets the fd feeded from the first kerneldriver 
open. 
-why do they do that? Well, that's easy: it's a very interesting way to 
tell any other application trying to use a certian card that it's *
already in use*. The idea behind it will be that just one 'client' at a 
time should use a device. That means that both original accelerant 
instances, and clones, should all belong to the same client.

This method is interesting, because it's very quick, and easy. If you 
look at my code for the VGADeviceOutput node, you'll recognize that I 
check for this. You'll also recognize that for other drivers I must try 
to open the accelernant (INIT). You'll also see that I modified my 
drivers to only let you use a accelerant via INIT _once, and via CLONE, 
only (multiple times) if first a primary instance was done. In all 
other cases I now return B_NOT_ALLOWED.

We need a (simple) method to tell possible clients that a device is in 
use, after all...

So, there you have another type of use of CLONE_INFO. I might not be 
exaclty right, because I could not reproduce this way of working. It 
turns out that the filescriptor used by the primary accelerant is *not 
valid* for a cloned accelerant. I assumed that I simply lack some 
knowledge here, and I aborted on this road. Instead, I modified the 
accelerants for B_NOT_ALLOWED checks.
(we spoke about this subject a bit once if you remember..).

--------

Unfortunately, this is not the only reason used by be for blocking 
secondary or higher opens on kerneldrivers. The SiS driver blocks this 
instead/as-well if it finds the card wasn't coldstarted by it's BIOS 
(so at POST time). 
And, Both 'explanations' for a blocked open on kerneldrivers were 
abandoned by Be, as we all know. At this point it doesn't matter as the 
above reasons contradict each other a bit (have a look at VGADEvOut if 
you want to learn more).

All in all this three-way approach is killing compatibility as soon as 
we want to use multiple cards in a system. So, I vote for a better 
defined rule for behaviour. Since I expect that Be abandoned the old 
method(s) for a reason, I vote for the accelerant B_NOT_ALOWED checks I 
alreayd have in place. I also vote that B_NOT_ALLOWED should be 
returned in case a accelerant finds its hardware isn't coldstarted 
while the driver hasn't got the means to do that itself.

This is a reasonable simple way to make sure no cards in use will be 
used again, and unusuble cards will be left alone.
I vote for the fixed name thing indeed, and kill the vagueness. 
Downside, if you will, is that we can't use old Be drivers. Which I 
think is no problem, since these have additional trouble: they tend to 
intermix each others areas: for instance, you should not be surprized, 
if you find a Be Matrox driver messing up a nVidia card programmed by 
another Be driver(!!!).

Hope this info clears enough up for you. If you have lots of time, you 
could try to investigate that old matrox driver to see how they did it 
so we could use that old method. Anyhow, I vote against it, since it's 
less logical: the accelerant does most of the programming, and has most 
of the inteligence to ascertain if certain conditions apply.

Best regards,

Rudolf.







Other related posts:

  • » [haiku-appserver] Cloning accelerant method