[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

X start-up delay (was: current testing)



Thank you for the suggestion, Felix, although I'm not quite ready to
levy my scorn and blame on KDE (yet). Since my last post, it turns out
that the full KDE desktop DOES start, but it takes an excruciating
amount of time (more on that in a second). systemd, systemd-analyze
and journald report nothing amiss, save for a few lines in journald to
the effect of "sddm-greeter[3069]: QObject: Cannot create children for
a parent that is in a different thread." I don't know if this is
relevant.

What IS curious is the contents of Xorg.0.log:
https://paste.debian.net/902120/ (link will be good until 17
December). My laptop (Fujitsu LifeBook T4410, for the curious) has an
integrated Wacom touchscreen and tablet. It seems to load the driver
47 seconds into launching at line 393. At line 444 there's an 8
minute, 20 second gap until line 445 gets written. Likewise, there's
another 6 minute gap between lines 514 and 515. This combined gap of
14 minutes, 20 seconds, is consistent with the time it takes to see
the SDDM login screen.

Here are the contents of the last apt-get before everything went south:
xserver-xorg-input-synaptics:amd64 (1.9.0-1, 1.9.0-1+b1),
xserver-xorg-video-vesa:amd64 (1:2.3.4-1+b1, 1:2.3.4-1+b2),
xserver-xorg-core:amd64 (2:1.18.4-2, 2:1.19.0-2), gnokii-cli:amd64
(0.6.30+dfsg-1.1+b2, 0.6.30+dfsg-1.2), xserver-xorg-video-fbdev:amd64
(1:0.4.4-1+b4, 1:0.4.4-1+b5), xserver-xorg-input-libinput:amd64
(0.22.0-1, 0.22.0-1+b1), xgnokii:amd64 (0.6.30+dfsg-1.1+b2,
0.6.30+dfsg-1.2), gnokii:amd64 (0.6.30+dfsg-1.1, 0.6.30+dfsg-1.2),
xserver-xorg-input-wacom:amd64 (0.33.0-1, 0.33.0-1+b1), xwayland:amd64
(2:1.18.4-2, 2:1.19.0-2), xserver-xorg-input-evdev:amd64 (1:2.10.4-1,
1:2.10.4-1+b1), xserver-xorg-input-mouse:amd64 (1:1.9.2-1,
1:1.9.2-1+b1), gnokii-common:amd64 (0.6.30+dfsg-1.1, 0.6.30+dfsg-1.2),
libgnokii6:amd64 (0.6.30+dfsg-1.1+b2, 0.6.30+dfsg-1.2)

You'll notice that the Wacom driver is in that update. The last change
log entry to the Wacom source is from October, so I don't think that's
relevant since it was working until the weekend.

Should I complain to the Wacom maintainers? I'm curious, though: even
if this driver were the culprit, why would it prevent me from
switching virtual terminals?


Reply to: