Summary: | x11-drivers/xf86-input-evdev-1.2.0 breaks multi-head /multi-foot xorg layouts | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Sumit Khanna <notify> |
Component: | Current packages | Assignee: | Gentoo X packagers <x11> |
Status: | RESOLVED UPSTREAM | ||
Severity: | major | CC: | dhp_gentoo, peper |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://bugs.freedesktop.org/show_bug.cgi?id=19527 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 210710 | ||
Attachments: |
xorg.conf
Server 0 Log Server 1 Log |
Description
Sumit Khanna
2008-01-09 12:02:23 UTC
Created attachment 140537 [details]
xorg.conf
Created attachment 140538 [details]
Server 0 Log
Created attachment 140540 [details]
Server 1 Log
Here we can see the second Xorg server can't grab any devices because the first one has attached onto them all
On an added note. Masking 1.2.0 and re-emerging doesn't help either. xorg is configured with hal and it tries to grab the devices anyway and then segfaults and two X servers compete for the same devices. I had to turn off hald and remove it as a dependency from the xdm init script to get everything back to normal I also have several regression bugs with X-1.4: bug 204401 and bug 194515 They dont seem to be related; but I think they are: X 1.4 introduce a new way to detect devices and for all those bugs it ends up with missdetected peripherals. This morning I an having 2 more problems: layout broken (I have FR board and X defaulted me in US) and broken evdev/mouse so that the Y axis is inverted. Visit bug 204128 ... that also tell about a HAL problem. Before trying to mask sys-apps/hal-0.5.10 try to add Option "AutoAddDevices" "False" to your ServerLayout. It fixed my layout, but not my mouse. See http://bugs.gentoo.org/show_bug.cgi?id=200061#c22 I added Option "AutoAddDevices" "False" per someone in the #xorg chat room on irc.freenode.net I now no longer had to disable hal before starting X, so I then tried to go back up to evdev 1.2. I removed the mask in /etc/portage/package.mask and when I strated X, I got the following in the logs: (**) Option "CorePointer" (**) MouseConsole: always reports core events (EE) MouseConsole: cannot open input pEvdev (II) UnloadModule: "evdev" (EE) PreInit returned NULL for "MouseConsole" (**) Option "CoreKeyboard" (**) KeyboardConsole: always reports core events (EE) KeyboardConsole: cannot open input pEvdev (II) UnloadModule: "evdev" (EE) PreInit returned NULL for "KeyboardConsole" None of my devices worked. It was a fresh emerge of xf86-input-evdev-1.2 and I am still using the xorg.conf I attached previously. (In reply to comment #7) > I got the following in the logs: > > None of my devices worked. I had the same problem. Xstarted, but was not usable. I mean, USB mouse was broken, but, my PS2 touchpad was still working ... (got a touchpad on workstation ^^ ) This is still a major issue for me and I really think it's related to the Ctrl key modifier in combination with mouse clicks. There is an existing bug on the freedesktop.org Bugzilla and I've added my information to it. Cross referencing it here: https://bugs.freedesktop.org/show_bug.cgi?id=14428 According to the freedesktop bugzilla, the "Name" directive was removed in 1.2 which is why 1.2 wasn't working per my earlier comment (would be nice if they updated the man page wouldn't it?) So I went back to "Device" Someone also sent me an e-mail noticing in my logs that Xorg couldn't connect to acpid. In fact acpid wasn't set to start at boot! If I tried to start it, it said the file it reads from in /proc was in use (turns out hald was grabbing a hold of it). If I stopped HAL, started acpid and then restarted HAL, then hal grabs the socket acpid sets up instead of /proc directly. Xorg also gets a hold of that socket and so does my nvidia driver. My system now runs stable. Adding acpid to my runlevel and upgrading to evdev-1.2 fixed my lockup problem. > turns out hald was grabbing a hold of it
Starting the service at boot may behave a different way than manually. If you disable parallel start, and get acpid starting automatically, then, maybe it could start before hal, and thus, fix your problem. Testing boot services manually is not a revealant method.
This bug has been sitting here for a while. I had my dual-seat layout disabled until just recently. It worked fine when I first used it and then an emerge world killed it. I masked xf86-input-evdev-2.1.0 (dropping to 2.0.8) and my multi-seat worked again. With xf86-input-evdev-2.1.0, the first screen would be shifted about 20% over. EVERY TIME I pressed enter (and sometimes randomly) it would start shifting again. It would also lock up after about 20 min. The entire problem was caused by evdev-2.1.0. (In reply to comment #12) > This bug has been sitting here for a while. I had my dual-seat layout disabled > until just recently. It worked fine when I first used it and then an emerge > world killed it. I masked xf86-input-evdev-2.1.0 (dropping to 2.0.8) and my > multi-seat worked again. > > With xf86-input-evdev-2.1.0, the first screen would be shifted about 20% over. > EVERY TIME I pressed enter (and sometimes randomly) it would start shifting > again. It would also lock up after about 20 min. The entire problem was caused > by evdev-2.1.0. Could you try again with a newer xorg-server (ideally 1.5.3-r1) along with evdev-2.1.2? If you still have issues, please file a bug over to FreeDesktop (with "remi@gentoo.org" as a CC on it so I can keep track of it). Thanks I should have updated this. There is a bug with xorg here: https://bugs.freedesktop.org/show_bug.cgi?id=19527 The solution being to turn on GrabDevices option in the xorg.conf Alright, thanks for the follow up. I've CCed myself on the upstream bug, let's see if Peter improves the documentation a bit. Thanks |