On Sat, 14 Dec 2024 04:21:26 +0100, "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2024-12-14 03:05, bent fender wrote:
Fri, 13 Dec 2024 15:58:43 +0100 "Carlos E. R." <robin.listas@telefonica.net> :
There is a hack you can do. In any of the possible places to call a script at desktop startup, call another script in background (&).
This other script starts has:
sleep 5 xeyes ...
did that too (in ~/.xprofile this time) no cigar
I think the problem is the appearance of the low res screen at all.
WHAT IS IT DOING THERE?
SDDM comes up in it, with the 5 second sleep it's obvious that it's staying in that screen. When the timer rings THEN the eyballs appear and THEN kde rolls into 1920x10980
That's probably because you are not calling a second script in background. The screen is waiting for ~/.xprofile to finish. You have to detach the second script.
Yes, without having the sleep command, which the xeyes commands wait for, also in the background (executed asynchronously), then the whole startup process waits till after the sleep ends, and it defeats the purpose of using the sleep to try to run the xeyes at a later point in the process. So you are suggesting (in .xprofile or other init script): sleep_then_xeyes_script & An alternative that does the same thing, but without a separate script, is to put the commands in a sub-shell, run in the background: ( sleep 5 xeyes -geometry 70x50+36+420 & xeyes -geometry 70x50-36+420 & ) &
but the eyes, having been opened in low res stay at the coordinates SDDM was in. If I call xeyes in the KDE autostart the situation is more 'normal' because KDE stars a 1920x1080 screen and the eyes get placed in that and thus correctly. The Y coordinate is affected the same way but that's less evident because it's not being called to screen lower limit.
sleep 5 xeyes -geometry 70x50+36+420 & xeyes -geometry 70x50-36+420 &
-- Robert Webb