See also bug #10947; the description in there is different, however, and may be referring to an unrelated problem with KDE 3.0.5; it is not clear from the description therein. On a 1.8 GHz P4, the time from the gray stippled X screen to the appearance of the login window (kdm_greet) is approximately a minute. In addition, directories with names consisting of 10-digit random strings of digits are created in /tmp on each run and never cleaned up. Investigation with strace revealed that kdm_greet was enumerating all of the X fonts on the system on each startup. Further inspection revealed the following code in kdm_greet.c: /* for QSettings */ srand( time( 0 ) ); for (i = 0; i < 10000; i++) { sprintf( qtrc, "/tmp/%010d", rand() ); if (!mkdir( qtrc, 0700 )) goto okay; } LogPanic( "Cannot create $HOME\n" ); okay: if (setenv( "HOME", qtrc, 1 )) LogPanic( "Cannot set $HOME\n" ); This code is creating a fake $HOME in /tmp with the described name each time kdm_greet is run. However, when Xft2 is active, it looks for a font cache in $HOME, and if not found scans all the fonts; in kdm_greet, of course, the cache is never there. As a temporary workaround, I replaced the above code with strcpy(qtrc, "/home/xdm"); (and of course created the above directory). The startup time went from 60 seconds to 2 to 3 seconds once Xft had created its cache file. The above code exists as quoted in the current KDE CVS (http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdebase/kdm/kfrontend/kdm_greet.c) at line 649 and following. I have not determined if this problem exists in versions prior to 3.1. I would suggest that kdm_greet have a configuration item for the configuration files; it may be desirable to create subdirectories within there using the value of $DISPLAY.
this might be the same issue as in bug #15161, just as i suspected this is xft related problem (slowdown happens also to gnome/gdm). does anyone know what should one do to fix gnome startup? regards, artb.
*** Bug 15161 has been marked as a duplicate of this bug. ***
OK. I've talked to ossi, the kdm maintainer, and he'll imlpement a fix upsteam and drop us a note to put a patch in our ebuilds. We'll have a static cache file in e.g. /var/cache/kdm and when kdm creates its temp HOME dir, it'll create a link there to that cache file. ossi says that beacuse of some braindamage in qt, the temporary dirs with their random names are necessary and cannot be replaced with say a static dir whose contents are removed between runs. gdm btw handles this by setting HOME to point to a static dir since (/var/lib/gdm) since it doesn't have that qt issue to deal with.
*** Bug 16212 has been marked as a duplicate of this bug. ***
This is to confirm that I and a friend have the same problem. Things are fine when using xdm with kde. But as soon as I change DISPLAYMANAGER to kdm it takes a couple of minutes to get the login box.
*** Bug 19349 has been marked as a duplicate of this bug. ***
Anyone know if this is still a problem with more recent kde versions? Should we get a patch into our system somewhere?
Try running fc-cache -f -v as root
resolving as patches have been applied upstream
