Summary: | x11-apps/xinit + gdm + baselayout-2 = dead keyboard | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Zdenek Behan <rain> |
Component: | [OLD] Unspecified | Assignee: | Gentoo X packagers <x11> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | eva, jiri, roy, xaviermiller, xmw |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Zdenek Behan
2008-03-31 19:15:20 UTC
> However, adding "before *" into
> /etc/init.d/xdm didn't solve the problem, either.
Try:
depend() {
# yada yada
after *
}
You might get some circular dependencies warning if other initscripts use "after *" as well, but the system should sort this out by itself.
I'd be interested in how to properly fix this, too.
Does your gdm log (normally /var/log/gdm/:0.log say anything interesting? I had a similar problem, it said I am missing a evdev module. After I emerged x11-drivers/xf86-input-evdev everything worked again (In reply to comment #2) > Does your gdm log (normally /var/log/gdm/:0.log say anything interesting? > > I had a similar problem, it said I am missing a evdev module. > After I emerged x11-drivers/xf86-input-evdev everything worked again I should probably re-try this bug again, because it's been a few months since i reported it. However, i'm pretty sure i was already using evdev back then. I basically "fixed" it for myself the "crude" way i described in my initial post, and i can transform that into nice wooly cuddly patches, if anyone's interested. However, it's just a workaround. hi there, I started hitting this on my macbook after openrc-0.4 and xorg-server-1.5.3 updates on 21 december. I have rc_parallel set to no for what it's worth. Hi, yeah, funny thing. I've tried following setup with RC_PARALLEL_STARTUP="yes": terminals on tty1 to 10, syslog-ng on 11 and gdm/X on 12. With xdm started by runlevel default ended up with an X on vt7 without keyboard interaction (the agetty thing). xdm restarted via ssh resulted in an X on vt12, perfect. Some tests and dangling with /etc/X11startDM.sh and /etc/conf.d/xdm (CHECKVT=7 or 12) ended in the awareness, that CHECKVT is just ... crap. Later I've tried to start xdm from local.start and got X on random vt's ... there's a race condition between the fork/exec in the backgrounded gdm to X and the startup of the agetty instances after the last init-script. Some straces and strings /usr/bin/gdm revealed a hard coded FirstVT=7 in gdm My solution is /etc/X11/gdm/custom.config: [daemon] FirstVT=12 VTAllocation=true n8 Same problem for my Acer Aspire One laptop (intel 945) in ~x86, with xf86-intel driver. Tested with and without uvesafb, it doesn't matter. On my nVidia + uvesafb ~amd64 desktop, I don't have the problem. *** This bug has been marked as a duplicate of bug 261339 *** |