
|
[haiku-appserver]
||
[Date Prev]
[05-2006 Date Index]
[Date Next]
||
[Thread Prev]
[05-2006 Thread Index]
[Thread Next]
[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.
|

|