VESA (Generic) video driver and (yab?) window position keeping between boots

Ahoy Devs,

I do not know exactly what part responsible for keeping window positions and icon positions between boots - I thought the housekeeping process that runs while shutdown do the job.

I have a Dell Precision M6400 laptop with Intel Extreme Core2 Quad processor QX9300 -

Based on (THIS datasheet), the integrated VGA was optional - motherboard vendor dependent : was a chipset feature -
It seems Dell was determined that not complicate this WST-grade laptop.
It was just provided a dedicated GPU from NVIDIA or ATI/AMD for engineering and 3D works.

In this/my case an NVIDIA Quadro FX 3700M (Details here) installed in this machine, but unfortunately Haiku does not have a driver for it, so I must accept that the fallback solution – a VESA driver (Generic VESA) provides the screen output.

Basically it is OK, but as this is the one and only difference between the other DELL Precision laptop and this one .. I suspect that the way Haiku’s video drivers interact with the mechanism responsible for remembering window positions might be the cause of an issue I’m seeing: the window of a clock application written in yab always appears in the center of the desktop, rather than where I last placed it, in the upper left corner, along the Deskbar. (On another laptop running Haiku – which uses the intel_extreme driver – the window does reappear in its previous location.) This suggests that window positions are being handled differently in the two environments.

It seems that either the app_server or another system component is failing to save the window’s position upon shutdown – or perhaps it simply resets the position to the default when the application loads.

Could it be that yab has an issue specifically with the VESA driver?
Tracker windows remain in their correct positions, but the yab application window never remembers its location on this particular machine – which is limited to using the VESA driver.

While the icon layout issue was resolved when I switched from Beta6 to a Nightly build, this specific window still consistently appears in the center of the screen. I suspect the problem lies either with the VESA driver or with the Haiku component responsible for managing window positions.

:cowboy_hat_face:

Did you try running that script from terminal to see if there are any errors? Yab doesn’t have a built-in centeronscreen() , so probably this is a fallback when there is not a saved settings, or the settings are corrupted, try to delete its current settings and try again.

All right.
Recently I just ran Haiku 32 bit on this machine. I switched to Nightly on both x86 architecture.

Can cause troubles if the settings comes from a 64 bit system ?
I copied some settings to have more quickly the same config on these Haiku systems as well.
Until now I had not experienced issue with it.
Can some application settings refer to driver, memory and architecture 32 and 64 bit differencies ?
I always thought what can cause problems like memory addressing and some library names diffrencies are lower deep than some application settings.

After I installed some dozen fonts to the 32 bit Haiku, the system never reached the Desktop after boot.
I got message that writes on full white screen

debugger for specific team on interface Local created and initialized successfully !

Sometimes that some threads stopped and the same white screen - presumably the debugger console, just somehow whole screen, and unfortunately does not respond.

The one and only solution is power off - by the power button .. CTRL_ALT_DEL does not work at all.

Now on hrev60317 I can reach the Desktop with resolution 1024 x 768, but if I increase the resolution to the native display resolution 1920 x 1200 : I get the same error. White screen and short message about thread stopped. Actually I get message about which thread :

(w Deskbar)

and when I tried to increase only 1280 x 1024, then I got stopped threads for

(w Deskbar)
(w Képernyő) <— Screen (setting applet) in Hungarian.

I will try your hint on a downgraded Haiku where the native resolution works, and still no those further fonts installed yet.

I cannot imagine what the relation can be. Somehow not enough memory ? Or addresses of programs or any other data conflicts each other in the memory ?

Anyway - I take a try ..

EDIT No.01 :

I followed your advice, I opened your yap script with editor, as first I had not found the directory and setings file.
Now I know you created to put them in the ..config/zuMI/ dir. and after the application name.
I found the “FineDigiClock” dir, but actually it is empty. I forgot that I may somehow saved the program settings on my main Haiku Nightly system. The Help hints does not mention it how this should be invoked.

I used power off many times - fortunately the filesystem (by checkfs) is still healthy, not needed any fix.

I had run the yab script in Terminal, on the affected Haiku 32 bit system, I submit this supplemental on my Linux system, to continue with adding the output here, as meanwhile I secured the Webpositive forum access there as well.
(It was necessary as that post-install activities I used to follow still were not completed : e.g. the Haiku related pages calling in Webpositive there yet.
I reinstalled that Haiku instance at least a dozen times, switched to Hsaiku Nightly again, and I just started to reinstall application and other packages, when I run into those new errors with GUI rendering and Haiku crash .. I detailed above - after installing fonts, and meanwhile continously upgrading this 32 bit Nightly - hoping the issues would be fixed for me by new patches.)

Edit No.02 :

~/config/settings/boot/launch> ./FineDigiClock.yab 
t application/x-vnd.zuMis-FineDigiClock
Signature in rsrc doesn't match constructor arg. (application/x-vnd.zuMis-FineDigiClock, application/x-vnd.yab-app)
NULL

This is the actual state here. I’m on downgraded 32 bit Haiku

~> uname -a
Haiku HaiQ32_R1NLY-DELL-M6400 R1~beta6+development hrev60299+6 Oct 27 2026 06:29:0 BePC BePC Haiku
~> 

:cowboy_hat_face:

If your system boots to a full white screen with black text on it,please make a screenshot and share it here,so that developers can identify the cause and fix it.
Especially in your case where you expect it to be related to installed fonts or screen resolution,that can point to an interesting cause that probably isn’t known yet.

For the error in Edit 2,that’s because you’re starting it with a application signature that doesn’t match.
Try to run the .yab command without the application/ part behind it,then the error should go away.

I can do only 320 x 240 blurry image - I have no smartphone or digicam actually.
The Haiku screenshot does not work on an unresponsive Haiku - unfortunately even the debug console is frozen, I mean so the input from keyboard was not worked when I tried it.

I provided the Terminal output for @zuMi as it was advised to do the yab program launch in Terminal … to see : is there any error ?

I can’t remember which version I shared but probably it’s saving its settings as an attribute, so it’s normal that the dir is empty - you can try to run listattr and catattr for its _app/* attributes and let’s see what it has, or try this more recent version, xtn.sh - Easy and fast file sharing from the command-line., perhaps you won’t like its name, but it had a lot of fixings