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

Hi Jack!

Hi Andrew ;-)

I am working on the problem right now:
Got some updates:

->Just ran BDB: it's being cloned indeed. I am now trying to determine why 
cloning fails on my driver as this seems to be a (the) problem! (found this 5 
minutes ago..)

Looked further into the R3 drivers as app_server addons:
->The drivers there are in fact used as fail-safe B/W 'stub' drivers!
On my system the supervga add on is activated if I remove all supporting 
drivers. Remove that and you'll end up with a hanging system (or app_server, 
did not check).

->The name 'stub' is not exported by those R3 add-ons, but some other way. 
Remove all R3 add-ons, and 'stub' still exists (after rebooting)

->stub is used with stub.accelerant. REmove that and you're 'dead' again ;-)

->Moving my driver to the system hierarchy did not solve the problem
->It's theoretically impossible that such a non-card specific R3 add-on would 
do the R3/R5 translation for those advanced features.

->I'll rule out now if the cloning is the problem, and how. I'll also send a 
new mail to the Allegro maintainer to ignore my previous one for now.

->Still the app_server (at least _that_ part of the system that does 
BWindowScreen app<>driver interfacing) does translation: the accelerant hooks 
as used in BWindowScreen are definately R3 style: back then you'd send the 
engine one command at a time, while now you send a list of (identical) 
commands.

An example is the DANO background coloring for menuitems (blue by default 
instead of R5 grey). The system creates a list of horizontal lines not 
occupying the characters themselves, and sends this list as one accelerant 
fill_span command (list). After this is waits until the engine is idle before 
continuing with other accelrated or direct drawing stuff. Etc....

R5 BTW uses invert_rectangle to do these grey backgrounds for menuitems. 
That's simpler as the server does not need to distinquish between character 
pixels and background pixels: it's just a square box.)

BWindowScreen must translate the acc commands given in R3 style to a list R5 
style with just one single item in it.

------

So: conclusion: Drivers do not implement some R3 translation stuff, but 
BWindowScreen does via a clone accelerant.

Best regards,

Rudolf.

PS I'll keep you posted if I come up with more stuff.

Bye!


>> Hi everyone,
>
>Hi Rudolf!
>
>> 
>> 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).
>
>Hey, you are not an outsider. I would like you to take part here more often 
>:)
>
>> 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.
>
>
>> 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.)
>> 
>
>Well, I tried to recreate BWindowScreen (and I still have some code on my 
>hard drive), but it isn't easy at all, and you are confirming this :)
>Anyway, what I know is that BWindowScreen clones the accelerant, and it uses 
>it directly, without passing through the app_server.
>Moreover, BWindowScreen also loads an add_on (but I don't know which one, I 
>should use the debugger to find it out).
>
>> 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.
>> 
>
>Oh! And I tought I had to look there :)
>That's why I couldn't implement BWindowScreen correctly...
>
>

Other related posts: