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.