[haiku-appserver] BWindowScreen results /app_server fault

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

Hi,

More detailed info:

CanControlFrameBuffer is actually OK. It checks against B_SCROLL in the 
end, which is correct.
The trouble is this: (inside that routine)

(fAddonImage >= 0) && ...

If I comment addonimage out the B_SCROLL flag is correctly identified.


My own testing app then runs OK, apart from something which turns out 
to be an app_server error:
app_server draws in the screen! This of course is prohibited....
This probably also solves the curved white lines error once solved.

My own app restores the screen itself, so after it quits the desktop is 
correctly restored.

pageflipper depends on BWindowScreen reiniting the original mode 
(somehow), so here it keeps going wrong.

Rudolf.




=======


------ Forwarded Message: ------
To: haiku-appserver@xxxxxxxxxxxxx
From: "Rudolf" <drivers.be-hold@xxxxxxxxxxxx>
Subject: BWindowScreen results
Date: Thu, 04 May 2006 12:28:08 +0200 CEST


Hi,

About BWindowScreen. Just ran two more apps:
-my own testing app: this one reports That CanControlFrameBuffer says ' 
NO'. this is incorrect (should be yes, as far as the driver is 
concerned, and that function should check the driver for MOVE_DISPLAY 
existance I think (am not sure though, I have to look it up to be 
sure))

-pageflipper:
Works partly. Acceleration hooks are exported. The ball is drawn, the 
MOVE_DISPLAY function is called, and gets correct coordinates.
The other intermixed curved white lines picture is missing though.

And a bit more info about quitting: After all: Setmode _is_ called. 
It's just not sending valid parameters! (screen size = 0,0, colorspace 
= 0x00000000). Naturally the driver refuses to set that with the effect 
that from the looks of things onscreen: the mode isn't restored, but 
left at the last used mode issued inside BWindowScreen.

Bye!

Rudolf.





Other related posts: