If I run startx directly after booting and logging in, certain key combinations do not work on my keyboard. This is with the latest xorg-server using HAL and it's fdi files with the evdev drivers. If I run XDM (which, as you know, is launched as root and hands control over to the user that logs in), my keyboard runs perfectly. If I startx myself, taking *dm out of the equation, ctrl+alt+<arrowkey> doesn't work at all. Reproducible: Always Steps to Reproduce: 1. boot computer (using evdev + HAL with xorg) 2. log in using terminal just after boot. 3. run the command `startx`. Attempt to use ctrl+alt+<arrowkey> Actual Results: The key combination described does nothing. If I have a terminal application open, the letters A, B, C & D are printed when attempting to press the key combo with up arrow, down arrow, right arrow and left arrow, respectively. Expected Results: I should be able to move between virual desktops in my desktop environment (xfce). As stated above, this only happens if XDM or another similar application is taken out of the picture and I run `startx` directly from the console, as my normal, non-root user.
Created attachment 165428 [details] output of emerge --info
I too can replicate this bug if I start X directly. # emerge --info Portage 2.1.4.4 (default/linux/amd64/2008.0/desktop, gcc-4.1.2, glibc-2.6.1-r0, 2.6.26-gentoo-r1 x86_64) ================================================================= System uname: 2.6.26-gentoo-r1 x86_64 AMD Athlon(tm) 64 Processor 3500+ Timestamp of tree: Sun, 14 Sep 2008 14:36:01 +0000 ccache version 2.4 [enabled] app-shells/bash: 3.2_p33 dev-java/java-config: 1.3.7, 2.1.6 dev-lang/python: 2.4.4-r13, 2.5.2-r7 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r7 sys-apps/baselayout: 2.0.0 sys-apps/openrc: 0.2.5 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r2 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=athlon64 -O3 -ftracer -pipe -funroll-loops -fpeel-loops" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-march=athlon64 -O3 -ftracer -pipe -funroll-loops -fpeel-loops" DISTDIR="/usr/portage/distfiles" FEATURES="candy ccache distlocks fixpackages metadata-transfer sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="en_GB.UTF-8" LC_ALL="en_GB.UTF-8" LDFLAGS="-Wl,-O1" LINGUAS="en_GB" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow 3dnowex X a52 aac accessibility acl acpi aiglx alsa amd64 amr berkdb bluetooth branding bzip2 cairo cddb cdr cli cracklib crypt cups dbus divx4linux dri dts dvd dvdr dvdread emboss emerald emul-linux-x86 encode evo exif exo fam fbcondecor ffmpeg firefox foomaticdb fortran freetype gdbm gif gimpprint glitz gpm gstreamer gtk gtk2 hal iconv imlib ipv6 isdnlog java jpeg ldap libnotify mad matroska midi mikmod mmx mmx2 mng mp3 mpeg mudflap multilib ncurses nls nptl nptlonly nsplugin nvidia ogg opengl openmp pam pcre pdf png ppds pppd python qt qt3support qt4 quicktime readline reflection sdl session skins spell spl sse sse2 ssl startup-notification svg sysfs tcpd theora tiff truetype unicode usb v264 v4l vorbis wxwindows xcomposite xml xorg xorg-x11 xscreensaver xv xvid zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CAMERAS="canon" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en_GB" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
I'll be unhelpful and say it works for me. I suspect it's a configuration problem, so forum, not bugzilla.
(In reply to comment #3) > I'll be unhelpful and say it works for me. > I suspect it's a configuration problem, > so forum, not bugzilla. > Did you attempt to replicate the bug exactly following the steps above? I have already been through the forums, to which I've found no solution. There's not really much you can get wrong in terms of configuration. The new xorg file is literally a few lines long, the configuration is now held in fdi files, not much you get wrong there either. Also note that it works fine when using a desktop manager like xdm or gdm. It doesn't sound like a config error, it feels more like some kind of permissions issue. Can anybody else replicate this please? Remember, kill x. stop xdm / gdm / kdm. Run startx as a normal, non-root user.
(In reply to comment #4) > Can anybody else replicate this please? Remember, kill x. stop xdm / gdm / kdm. > Run startx as a normal, non-root user. > Definitely. - non-root user - just `startx` Works just fine. Is both xorg-server and xinit with hal useflags ? Are hald/consolekit services running as you `startx` ? What's the output of `hal-device` for your keyboard ?
Sounds like your XKB may not be working. What's the output of `setxkbmap -print`? It would be useful to compare this output between the working and broken setups.
(In reply to comment #6) > Sounds like your XKB may not be working. What's the output of `setxkbmap > -print`? It would be useful to compare this output between the working and > broken setups. > 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)" }; }; (In reply to comment #5) > Definitely. > - non-root user > - just `startx` > Works just fine. > > Is both xorg-server and xinit with hal useflags ? > Are hald/consolekit services running as you `startx` ? > What's the output of `hal-device` for your keyboard ? > Both are compiled with the hal useflag and hald is started in the default runlevel: rc-update show default: hald | default. If this were a matter of xkb or configuration errors, why would it work when logging in through a *DM, such as xdm? Anything else I can check? I can replicate this on my work machine, though I suppose that's not worth much as it's a stage4 backup of my current home machine. In the forums, another user says he has a similar problem and Michael (comment 2) can also replicate this problem. Any other ideas?
> Both are compiled with the hal useflag and hald is started in the default > runlevel: rc-update show default: hald | default. > > If this were a matter of xkb or configuration errors, why would it work when > logging in through a *DM, such as xdm? Anything else I can check? I can > replicate this on my work machine, though I suppose that's not worth much as > it's a stage4 backup of my current home machine. > > In the forums, another user says he has a similar problem and Michael (comment > 2) can also replicate this problem. Any other ideas? > I get this also when starting from xinit, gdm works correctly. My USE flags are sane, the runlevels are too.
I could confirm this bug - in dm started xserver the keyboard is working properly, in normally started xserver (through xstart) some keys does not work.
If xorg-server-1.5 is compiled with "hal" use flag, it uses hal-defined layout. It breaks your current xorg.conf settings (but enables e.g. mouse autodetection which is nice). You may wish to alter /etc/hal/fdi/policy/10-x11-input.fdi according to this page: http://cgit.freedesktop.org/xorg/xserver/tree/config/x11-input.fdi (example provided). Restart hal and X afterwards and you should be just fine. Layouts might also get broken by your DE's tools for keyboard configuration. If the above method doesn't help, disable these tools or try starting to "clean" X and see if it works.
(In reply to comment #10) > If xorg-server-1.5 is compiled with "hal" use flag, it uses hal-defined > layout. It breaks your current xorg.conf settings (but enables e.g. mouse > autodetection which is nice). > You may wish to alter /etc/hal/fdi/policy/10-x11-input.fdi according to this > page: http://cgit.freedesktop.org/xorg/xserver/tree/config/x11-input.fdi > (example provided). Restart hal and X afterwards and you should be just fine. > > Layouts might also get broken by your DE's tools for keyboard configuration. If > the above method doesn't help, disable these tools or try starting to "clean" X > and see if it works. > This is not the problem. I have fdi files for both my mouse and keyboard, however, as stated, this bug only occurs when starting X directly with no *DM. I've since installed GDM to get around this problem, though it's quite annoying. I've replicated the bug on a few configurations now and as you can see, others are experiencing the same bug. Try killing your *DM, kill X, then run startx directly.
Could you attach /var/log/Xorg.0.log in both cases? /me vaguely remembers about such a bug... argh, my memory sucks... Thanks
I had this issue too. In my case: - Set gdm to autologin -> keyboard wrong - Log manually from gdm -> keyboard good Found this: https://bugs.freedesktop.org/show_bug.cgi?id=16364 I confirm that the fedora patch (comment 12) fixes the issue for me.
Let's get this patch in. Sucks that it's not upstream, but the upstream input guy is the one who posted it as a temporary solution.
http://github.com/steev/steev-overlay/tree/master/x11-base/xorg-server/files/xserver-1.5.0-force-SwitchCoreKeyboard-for-evdev.patch I have it there - I had talked with remi` about this on IRC and he said I could commit it to the x11 overlay for testing there, however, I don't have access to the overlay as far as I know...
Hmm, I thought I'd get this done with 1.5.3 but I'm currently holding it back for a little while. Steev, feel free to add your patch to portage's 1.5.2 ebuild directly. Thanks
I've seen this same problem with earlier versions of xorg-server (~ 1.4) and I've found that simply restarting metacity with: metacity --replace solves the problem for that session.
Created attachment 174926 [details, diff] xorg-server-1.5.2-r1.ebuild.diff patch for xorg-server-1.5.2.ebuild to apply the xserver-1.5.2-force-SwitchCoreKeyboard-for-evdev.patch
Created attachment 174928 [details, diff] xserver-1.5.2-force-SwitchCoreKeyboard-for-evdev.patch dunno what is holding this up, but this bug has been making life miserable for me. startx from console has been yielding unsatisfactory keyboard layout. patch fixes the problem as previous poster mentions.
I should add that I removed the Section "InputDevice" for both my mouse and keyboard and added: Section "ServerFlags" Option "AllowEmptyInput" "True" EndSection to /etc/X11/xorg.conf so that my input devices are "pure" HAL.
Philip, could you try xorg-server 1.5.3 which is in the x11 overlay? It already has this patch. /me swears to push 1.5.3 to portage before the weekend... Thanks
I don't use the x11 overlay, but i'll be happy to test for this fix if you move it into main portage. Philip
Thanks for pushing 1.5.3 into main portage. The SwitchCoreKeyboard patch discussed and posted in this bug is indeed included in the xorg-server-1.5.3-gentoo-patches-01.tar.bz2 patchset. I can report that it is working here on ~x86, so I think 1.5.3 closes this issue for me. Thanks again. Phil
Thanks for the quick follow up :) Closing FIXED. Please don't hesitate to open a new bug for any issues you might have with 1.5.3. Thanks
