Created attachment 400234 [details] xorg.conf, Xorg.0.log, emerge --info Mouse/keyboard stopped working after relatively recent upgrade of xorg-server or systemd, not sure which one, around 1.16 and/or 3.18, about 2 months ago. I used this xorg.conf (attached) for more than a year without issues, until that recent upgrade. I am using same xorg.conf right now in FreeBSD 10.1, working like a charm! Long time Gentoo user (since 2003), been through all, HAL, udev, systemd, you name it, on various desktops and laptops, always worked nice until now. After that event, I reinstalled Gentoo, starting from stage 3 up to xorg-x11 and fluxbox, just to try X, to no avail: fluxbox starts, conky comes up nice, but no keyboard, nor mouse. The only way to get out is Alt-SysRq-e,i,u and reboot. Attached Xorg.0.log where I marked the lines on input devices. Assume it's a systemd issue, maybe in combination with X. Mouse works just fine in console, with gpm. Decided to finally file a bug report, because did not see a similar bug reported and too puzzled: one moment everything works, the next complete fail, plus same machine works perfectly in FreeBSD. Thanks for any help that could point me in the right direction.
Yes, seems related to systemd. Those "systemd-logind: got fd for /dev/input/..." lines look suspicious. How are you launching X? Systemd is very strict about e.g. using what it thinks is the right vt for X. If you have a login manager (gdm, xdm, etc.) with USE=systemd and launch that login manager from systemctl, it should generally take care of things for you. (If it doesn't - that's a bug.) But if you are manually running startx or xinit from the console, well, you will need to read a lot of documentation ;)
(In reply to Alexandre Rostovtsev from comment #1) > Yes, seems related to systemd. Those "systemd-logind: got fd for > /dev/input/..." lines look suspicious. > > How are you launching X? > > Systemd is very strict about e.g. using what it thinks is the right vt for > X. If you have a login manager (gdm, xdm, etc.) with USE=systemd and launch > that login manager from systemctl, it should generally take care of things > for you. (If it doesn't - that's a bug.) > > But if you are manually running startx or xinit from the console, well, you > will need to read a lot of documentation ;) Like forever I manually start X from console using startx -- .xinitrc is just one line: exec startfluxbox Probably that's why nobody else reports this, because I guess most people use a login manager. I always felt more comfortable with the console. Read and applied all systemd documentation when I started using it, not lately. What I simply can't understand is why is this happening all of a sudden. Installed openSUSE just for fun and it works fine, exactly like FreeBSD. openSUSE is using an older kernel and systemd, this tells me that it's related to the latest few versions of systemd used in Gentoo.
FreeBSD uses a different method of input device enumeration compared to udev based Linux systems. So it is very well possible that a configuration works on one OS but not on the other. Try starting without any xorg.conf at all.
(In reply to Chí-Thanh Christopher Nguyễn from comment #3) > FreeBSD uses a different method of input device enumeration compared to udev > based Linux systems. So it is very well possible that a configuration works > on one OS but not on the other. > > Try starting without any xorg.conf at all. Cristopher, Starting X without xorg.conf was one of the first things I tried. Doesn't help, same results regarding input devices, even worse in another way: X server is not capable of detecting my dual monitor configuration without an xorg.conf. I tend to concur with previous Alexandre suggestion that all this is happening because of starting X from console using startx, without using a login manager. What I like about Gentoo philosophy is the freedom of choice and I don't see why I should be forced to use a login manager (gdm, kdm etc). This could raise another discussion about other forced options in Gentoo... for example Gnome 3 forces us to install modemmanager and ppp, even if many modern systems don't have a need for those things anymore. Eugen
startx works fine with systemd; I think Alexandre is a bit behind the times on that. A somewhat recent /etc/X11/xinit/xserverrc takes care of the vt selection, and x11-apps/xinit[systemd] will even make it work if you don't use that xserverrc. In any case, X running on the wrong vt would cause problems for systemd-logind, but should not affect the input devices detected by the X server. This is a problem that is isolated to the reporter's system.
$ grep pam_systemd /etc/pam.d/* please.
(In reply to Michał Górny from comment #6) > $ grep pam_systemd /etc/pam.d/* > > please. Will do when I get home this evening.
(In reply to Michał Górny from comment #6) > $ grep pam_systemd /etc/pam.d/* > > please. Michał, The above command gives: /etc/pam.d/system-auth:-session optional pam_systemd.so Removed the "-" in front of "session:, rebooted, no positive effect.
(In reply to Mike Gilbert from comment #5) > startx works fine with systemd; I think Alexandre is a bit behind the times > on that. A somewhat recent /etc/X11/xinit/xserverrc takes care of the vt > selection, and x11-apps/xinit[systemd] will even make it work if you don't > use that xserverrc. > > In any case, X running on the wrong vt would cause problems for > systemd-logind, but should not affect the input devices detected by the X > server. > > This is a problem that is isolated to the reporter's system. Mike, I launch startx from the first vt, the one that comes up when booting the system.
A normal Xorg.log entry for a keyboard looks something like this one taken from my desktop. [ 241.353] (II) config/udev: Adding input device Microsoft Comfort Curve Keyboard 2000 (/dev/input/event2) [ 241.353] (**) Microsoft Comfort Curve Keyboard 2000: Applying InputClass "evdev keyboard catchall" [ 241.354] (II) systemd-logind: got fd for /dev/input/event2 13:66 fd 16 paused 0 [ 241.354] (II) Using input driver 'evdev' for 'Microsoft Comfort Curve Keyboard 2000' [ 241.354] (**) Microsoft Comfort Curve Keyboard 2000: always reports core events [ 241.354] (**) evdev: Microsoft Comfort Curve Keyboard 2000: Device: "/dev/input/event2" [ 241.354] (--) evdev: Microsoft Comfort Curve Keyboard 2000: Vendor 0x45e Product 0xdd [ 241.354] (--) evdev: Microsoft Comfort Curve Keyboard 2000: Found keys [ 241.354] (II) evdev: Microsoft Comfort Curve Keyboard 2000: Configuring as keyboard [ 241.354] (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:12.0/usb6/6-3/6-3:1.0/0003:045E:00DD.0001/input/input3/event2" [ 241.354] (II) XINPUT: Adding extended input device "Microsoft Comfort Curve Keyboard 2000" (type: KEYBOARD, id 8) [ 241.354] (**) Option "xkb_rules" "evdev" [ 241.354] (**) Option "xkb_model" "pc104" [ 241.354] (**) Option "xkb_layout" "us" In your log, I'm seeing this: [ 552.483] (II) config/udev: Adding input device SIGMACHIP USB Keyboard (/dev/input/event4) [ 552.483] (**) SIGMACHIP USB Keyboard: Applying InputClass "evdev keyboard catchall" [ 552.483] (II) systemd-logind: got fd for /dev/input/event4 13:68 fd 29 paused 1 [ 552.483] (II) systemd-logind: releasing fd for 13:68 I'm not quite sure what that last line indicates. It seems to have something to do with systemd-logind, but I'm not familiar enough with it to say exactly what is wrong there.
All respondents seem to agree that it's a systemd issue, but it doesn't look like we have the in depth knowledge to dig further. Again, another linux distro, with an older systemd, works just fine. Unless a systemd expert gets on board, I would call it a dead end. Anyway, I kind of gave up using Gentoo on a regular basis because of this bug. Thanks everybody for looking into it.
(In reply to Eugen from comment #11) > Unless a systemd expert gets on board, I would call it a dead end. > Anyway, I kind of gave up using Gentoo on a regular basis because of this > bug. You need someone who actually understands how systemd interacts with X. That's probably a very small group of people. You might try asking the upstream developers who created the integration. > Thanks everybody for looking into it. Sorry we aren't more helpful.
Have you tried downgrading systemd on Gentoo to the version as in the 'other distro'?
(In reply to Michał Górny from comment #13) > Have you tried downgrading systemd on Gentoo to the version as in the 'other > distro'? I'd also try to reproduce this in a VM with a fresh install of Gentoo and a minimal tracked set of changes (I'd suggest sticking /etc in a git repo and then cherry-picking the minimal commits to get it to break). I've used systemd and X11 both with and without display managers without issue. But, that is in a relatively generic Gentoo install as far as stuff like pam/udev/polkit and so on go.
Sorry for not answering sooner, I was away for 2 days. The story is getting even better: Downgraded to stable systemd-216-r3. Still not good. Then, just added the followings to xorg.conf: Section "ServerFlags" Option "AllowEmptyInput" "off" Option "AutoAddDevices" "off" EndSection Section "InputDevice" Identifier "keyboard" Driver "kbd" EndSection Section "InputDevice" Identifier "mouse" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/input/mice" Option "ZAxisMapping" "4 5 6 7" EndSection Section "ServerLayout" ... ... ... InputDevice "keyboard" "CoreKeyboard" InputDevice "mouse" "CorePointer" EndSection and I have a usable mouse and keyboard! This tells me that it may not systemd at fault, but xf886-input-evdev. Now, I want to put back systemd-219. In the meantime I updated my portage tree and see that gcc-4.8.4 is available. Upgrade gcc to this new version, got a message at the end about preserved libraries... and when trying to update systemd, I see that I have an unusable Gentoo system, because the new gcc "cannot create executables". Nice! No time and patience anymore for this. So, after 12 years of joy and pain, Gentoo is going to be flushed down the drain pronto!
I'm closing this; there is nothing useful to be garnered from this bug report.
