Summary: | x11-base/xorg-server compiled w/ USE=hal crashes and distorts image on dbus/hal restart | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Sascha Hlusiak <bugs> |
Component: | Current packages | Assignee: | Gentoo X packagers <x11> |
Status: | RESOLVED FIXED | ||
Severity: | critical | CC: | agent_jdh, gentoo-bugzilla, gentoo, hans, jakub, tais.hansen |
Priority: | High | Keywords: | Inclusion |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Sascha Hlusiak
2008-01-18 10:47:01 UTC
Yeah, that's the 'progress'. You'll have to take this upstream, not a Gentoo-specific issue at all, also not specific to any video driver at all (reproducible w/ both nvidia drivers). As a workaround, you can recompile xorg-server w/ USE="-hal". I had the same weird thing happen. dbus was in my set of packages that Portage was to be upgrading. I set that in motion, and when I came back to my machine, it was at the KDM login screen. I rebooted the machine, and when I logged in after the reboot, some of my keyboard keys are doing strange things. For example, the Up Arrow key is being interpreted as Print Screen. Someone upstream really screwed something up. Funny, I went into "KDE Settings > Regional & Accessibility > Keyboard Layout" and unchecked "Enable keyboard layouts", clicked OK, and logged out. Restarted X and logged back in, and now all my keys are working, even the special ones like XF86Back and XF86AudioPlay. Go figure. $ fgrep -i xkb /etc/X11/xorg.conf [..no output..] (I have no Xkb options specified in my xorg.conf) (and yet..) $ setxkbmap -print xkb_keymap { xkb_keycodes { include "evdev+aliases(qwerty)" }; xkb_types { include "complete" }; xkb_compat { include "complete" }; xkb_symbols { include "pc+us+inet(evdev)" }; xkb_geometry { include "pc(pc104)" }; }; (somehow it automatically activated the inet symbols) I guess I won't complain again until something else breaks. Please, do NOT flood this bug with off-topic comments. There are other bug reports about keyboard layout issues w/ HAL, search bugzilla. I saw exactly the same issue when upgrading dbus last night (with similar log entries), however the OP doesn't make it clear if X works after a reboot - for me here, dbus-1.1.4 renders X unusable after a reboot. It doesn't appear to even attempt to start (and the xorg and kdm log files do not get updated with any information. All I get is a blinking cursor when I switch to VT7. I don't know if dbus-1.1.3 also exhibited this behaviour, as it was only upgraded to that for 24 hours during which time my machine was not rebooted. Masking dbus-1.1.4 in /etc/portage/package.mask end re-emerging dbus reverts to v1.0.2-r2 - fixes the problems here, X now works OK. I did some testing. The crash happens on /etc/init.d/dbus restart. It does NOT crash when doing only /etc/init.d/hald restart. Unlike said in my first report, Xorg is usable after the crash, just vt1-vt6 is distorted and unusable. My keyboard did not work anymore after kdm came up again, because X crashed when restarting dbus, which was invoked by a terminal in X. Restarting dbus first stops hal, then stops dbus, then Xorg crashed. So no running dbus, no running hal and no hotplugging of my keyboard (I hotplug the keyboard through hal, but let not hotplug the mice; they are static in xorg.conf). Xorg.0.log.old does not contain anything related to the crash, just kdm.log contains the lines mentioned in the first post. I just saw a patch go by on xorg-commit, id 975ab11799c819a81da1dfe83505194410dbcb95, so I'll check into it. I've got a local copy of the upstream git 1.4 branch with a few related patches in it. I'll see if I can get them merged upstream. Should be fixed in xorg-server-1.4.0.90-r4, which I expect to rekeyword as soon as a few last patches find their way in. (In reply to comment #9) > Should be fixed in xorg-server-1.4.0.90-r4, which I expect to rekeyword as soon > as a few last patches find their way in. > I ran into the same problem with my eee pc 702 (of course, running Gentoo). It seems that I also have the Up -> Print mapping, even with xorg-server-1.4.2 , a US layout and the following use flags: $ cat /var/db/pkg/x11-base/xorg-server-1.4.2/USE dri elibc_glibc hal input_devices_evdev input_devices_keyboard input_devices_mouse input_devices_synaptics kernel_linux sdl userland_GNU video_cards_fglrx video_cards_i810 video_cards_radeon video_cards_vesa video_cards_vga x86 xorg xprint $ setxkbmap -print xkb_keymap { xkb_keycodes { include "evdev+aliases(qwerty)" }; xkb_types { include "complete" }; xkb_compat { include "complete" }; xkb_symbols { include "pc+us+inet(evdev)" }; xkb_geometry { include "pc(pc104)" }; }; xorg.conf ================ ... Section "InputDevice" Identifier "Keyboard1" Driver "kbd" Option "AutoRepeat" "500 30" Option "XkbRules" "xorg" Option "XkbLayout" "us" EndSection ... However, I also have some good news. With INPUT_DEVICES="-evdev" USE="-hal" I no longer suffered from the same keyboard remapping bugs. If evdev and hal are the root causes for this bug, I would suggest that a warning is added to the ebuild and that the revision is bumped. In my case, I specifically wanted to use evdev with evtouch for my eGalax touchscreen, but I guess I'll have to wait for a later version (or compile it myself, I guess). (In reply to comment #10) > I ran into the same problem with my eee pc 702 (of course, running Gentoo). It > seems that I also have the Up -> Print mapping Since you're using the evdev keyboard layout, you also need to be using the evdev driver. Don't use "kbd" anymore; it's obsolete. |