When kdmtheme is in use and /etc/init.d/splash gets started after kdmtheme has drawn the desktop, the splash border gets drawn on top of the kdmtheme screen. This has no adverse effects on functionality and can be cleared up by switching out of X to a virtual console and back again, but it is irritating. On my system, I'm using NVidia TwinView's Xinerama emulation and this results in an additional interesting quirk. The unwanted border is drawn once per screen with the aspect ratio of the combined 2048x768 desktop, but at half size, so each screen gets the top half of the screen framed in a 1024x384 box.
Is this still an issue? I have a TwinView system using the binary nVidia driver. I do not use the fbsplah stuff though. I have never had issues like this. I doubt it is a KDE issue if it is still happening - sounds more like a driver issue to me which is very tough to fix or even investigate in a closed source driver... If it is still an issue I will try to find the time to see if I can reproduce it here. We will need your emerge --info. I use an ~amd64 system here. Reassigning to X11 drivers herd and adding KDE to CC - do you guys have any ideas on this one or the best way to proceed?
yep. this is a bad interaction between VESA and binary nVidia drivers. The proper way would be to fix the init script order (you almost sound like you're using parallel init scripts, which you should turn off) and it won't happen anymore. Your last re-course is to contact nVidia.
RC_PARALLEL_STARTUP="no" in /etc/conf.d/rc but my system DOES start X before starting the splash initscript. Is there another parallel startup control I should check?
try adding "before xdm" to the fbsplash init script. the fbsplash init script is just called "splash" correct?
It is called "splash", but it already has a "before xdm" in the depend function.
2 year old bug, I'll assume it's now fixed. Please don't hesitate to reopen this bug if the issue still appears on an up-to-date system. Thanks
