[interfacekit] R3 legacy code in R5 drivers?!?

Hi everyone,

I realize I'm a bit of an outsider here, but I can imagine what I have to say 
(or ask) could be meaningfull on _some_ occasions (sooner or later).

Recently I got an Email from a user that works with the Allegro game library. 
Also he pointed me at the PageFlipper demo app on everyone's HD (sample 
code).

There seems to be something I can't  exacly put my finger on yet. If you run 
either of these things on a stock R5 driver (Tested on G400 and Millenium), 
you can use functions (from within BWindowScreen) that still use the R3 style 
graphicsdriver interface. 
This does not work with my drivers, nor will it work with any other non Be 
driver I expect.

To be precise: Everything based on Be's header GraphicsCard.h is R3, 
Accelerant.h is R4/R5. So any function using things from GraphicsCard.h (or 
referenced to that by the R5 BeBook) does _not_ work on my drivers.

BWindowScreen R3 Examples:
CardHookAt();
CardInfo();
FrameBufferInfo().

BWindowScreen R5 compatible examples (so updated by Be)
SetFrameBuffer();
CanControlFrameBuffer();
MoveDisplayArea().


I confirmed that no G400 and Millenium R3 drivers are present on R5: those 
should be in:
/boot/beos/system/add_ons/app_server/
There are still a few there though..
(Or am I mistaken here??)

Here are my questions that keeps me awake at night ATM ;-)

->Did R3 drivers work in kernelspace, userspace or both?
->If both, where does: 
long control_graphics_card(ulong message,void *buf)
 and 'underlying' code go? 
->Does anyone know how to modify an R5 graphics driver to be BWindowScreen R3 
compatible?
->Would this use the old interface control_graphics_card or would Be have 
setup something new that fits better with the current driverstyle?

I simply put the mentioned function inside an R5 accelerant, and also I 
tested in the kerneldriver, but nogo :-/

Most R3 functions can be performed in another way (BScreen I think), but 
acceleration would be a problem AFAIK. I only (think I) know of one method: 
privately loading a clone accelerant and using the acc_engine (I can imagine 
the app_server releases the acc_engine on BWindowSCreen activation, so a 
clone could claim the engine. As long as it releases it again on quitting the 
BWindowScreen or changing workspaces.)

->Does anyone know of (sample) (source)code using this way for acceleration? 
I'd like to have a look :)
->Is there yet another way to get acceleration??

I think not, so this would be the main reason for Be holding on, or creating 
an R3 like interface in R5 drivers until BWindowScreen would be finally and 
largely revised...


Well, that's it. I included the mail I sent to the allegro maintainer 
(BeBits) below for your reference.


Best regards, and thanks for any input in advance..

Rudolf Cornelissen.


----------

Hi there,

My name is Rudolf Cornelissen. I am writing the (open)BeOS nVidia, Matrox and 
NeoMagic driver.
The problem I'll describe will influence other non-Be drivers as well.

OK, here it is.

I got an Email from "Cyan Helkaraxe" <manic@xxxxxxxxxxxxxxxxx> about the 
Allegro game library. He sent me the included (exe and source) testapp.

What happens is this:
->this app runs fine on R5, with the Be G400 or Millenium Matrox driver. It 
is capable of setting virtualscreens with BWindowScreen, and using 
acceleration (blit).

->On my drivers, all of them, the app partly runs. It is not capable of 
setting virtualscreens, nor using acceleration.

--------

I've been looking at the allegro library source, downloaded from bebits 
today, latest stable version. I've also been looking at full logging from two 
of my drivers via a remote computer telnetted into the testmachine, so I can 
actually see 'on the spot' what allegro does with my drivers.

The problem is plain and simple: Be's BWindowScreen implementation is 
outdated, and adheres to the BeOS R3 graphics drivers architecture.
To be precise, you may _not_ use any function or struct found in the header 
file: GraphicsCard.h.

This means, acceleration hooks cannot be fetched (CardHookAt()), and you may 
not rely on BWindowScreen->CardInfo(), or FrameBufferInfo() and the such. All 
those functions are based on R3, as you can find in the BeBook because it 
references to the GraphicsCard.h file.

The reason this _does_ work with Be's Stock drivers, is that Be has 
implemented some sort of unpublished legacy code inside the R5 drivers, that 
still respond to the old style commands. I've tried to mimic this behaviour 
inside my drivers, but I did not succeed (yet). Even if I were to succeed, 
you are _strongly_ adviced to avoid R3 graphicsdriver calls.

I want to add here, that my drivers _do_ support acceleration and 
virtualscreens (with BWindowScreen). You can safely use BWindowScreen->
SetFrameBuffer(). Also CanControlFrameBuffer() work OK. MoveDisplayArea() 
also works OK. This means Be revised these functions to use the R4/R5 
graphics driver interface.

For the functions you may not use, you should use R5 versions instead. 
Everything you can find in Accelerant.h applies to R5. Probably most of the 
things you find there have a userspace counterpart. So my advice is to look 
at Accelerant.h for reference, and then find the appropriate userspace 
counterpart for that. My guess (by heart): BScreen.

If you want to use hardware acceleration, the only way you can use that is by 
privately loading a clone of the accelerant. While I did not test that 
myself, it seems logical to me that BeOs app_server releases the acc_engine 
as soon as you setup a BWindowScreen. Once that happens, you can aquire it, 
and use all accelration functions setup via the clone accelerant. 
On exiting the BWindowScreen (or a workspace switch), you have to relinquish 
the acc_engine so the app_server can re-aquire it.

I can imagine acc this way is difficult to setup at first glance, so you 
could do that in a later stage. The other problems can be easily fixed 
though.
Please have a look at:
http://web.inter.nl.net/users/be-hold/BeOS/NVdriver/index.html

Goto the 'TechInfo' page, and download my command line testapps Virtualscreen 
and WindowScreen. These apps demonstrate to you that the functions work very 
nicely with my drivers (as with most Be drivers) using the R5 interface.
You'll also see you can do more with BScreen than you'd expect while 
BWindowScreen is active. (Though I realize it doesn't look that neat.)

BTW: ProposeMode() might be a nice function to ask the driver if some things 
are possible or not... 


One more thing, for your reference:
In the allegro file 'bgfxapi.cpp', function 
'be_sort_out_virtual_resolution()', there's mention of a tweak because of 
strange behaviour with R5.

Here's some additional info: While the app interface uses 32bit words, the 
accelerant interface uses 16bit words. This is why things go wrong. 
Unfortunately, Be made a mistake when dealing with this, because a size above 
32768 x 32768 so (above 15 bit + 1), rolls over some internal app_server 
variable. The drivers (my drivers) work OK upto 65535 though (if hardware 
supports it).

Note that the app_server limits calculations at 10000x10000 pixels workspace 
size. If for instance the app_server internal software fill_rect command is 
executed, you'll see this. This also applies with hardware acceration: the 
app_server simply clips (instructions) at 10000x10000. (The drivers/cards can 
do more sometimes..)

Of course this is not interesting for BWindowScreen use. I did not test if 
BWindowScreen works OK upto 16-bit sizes, only with virtual desktops!

->You might want to update the library to make use of upto 256Mb cardRAM, as 
my nVidia driver supports that much. I have successfully setup workspaces 
using up the entire 128Mb RAM on my cards over here. You can test that if you 
have such a card, and use my testing app virtualscreen.

The RAM amount a card has can be asked to the driver BTW: It reflects the 
correct RAM amount size in a (R5) struct (accelerant_device_info), so you 
won't have to quess.

Another 'trick' way of determining max RAM is by setting up a large X 
coordinate, and also a large Y coordinate. If the drivers can't do that, they 
will decrease the Y value to be 'just' possible. See my virtualscreen app 
sourcecode for more on that.


OK, that's it for now. I hope you'll make sure this mail will reach the right 
person(s) if you are not or nolonger working on allegro..


Best regards,

Rudolf Cornelissen.

Other related posts: