Hi all I am using KDE4.3.2 (~x86) and have recently upgraded xorg-server to 1.7.1. Now, certain keystrokes produce multiple simultaneous key events that are then all received in KDE and other applications. I have verified this behaviour using xev, which indeed shows multiple events were generated. The following example is from pressing the "delete" key: KeymapNotify event, serial 31, synthetic NO, window 0x0, keys: 16 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 KeyPress event, serial 31, synthetic NO, window 0x1200001, root 0x110, subw 0x1200002, time 14287752, (44,40), root:(1345,65), state 0x10, keycode 119 (keysym 0xffff, Delete), same_screen YES, XLookupString gives 1 bytes: (7f) "" XmbLookupString gives 1 bytes: (7f) "" XFilterEvent returns: False FocusOut event, serial 31, synthetic NO, window 0x1200001, mode NotifyGrab, detail NotifyAncestor FocusIn event, serial 34, synthetic NO, window 0x1200001, mode NotifyUngrab, detail NotifyAncestor KeymapNotify event, serial 34, synthetic NO, window 0x0, keys: 16 0 0 0 0 0 0 0 0 0 0 0 0 8 4294967168 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 MappingNotify event, serial 34, synthetic NO, window 0x0, request MappingKeyboard, first_keycode 8, count 248 KeyRelease event, serial 34, synthetic NO, window 0x1200001, root 0x110, subw 0x1200002, time 14287824, (44,40), root:(1345,65), state 0x10, keycode 119 (keysym 0xffff, Delete), same_screen YES, XLookupString gives 1 bytes: (7f) "" XFilterEvent returns: False MappingNotify event, serial 34, synthetic NO, window 0x0, request MappingKeyboard, first_keycode 8, count 248 KeyRelease event, serial 34, synthetic NO, window 0x1200001, root 0x110, subw 0x1200002, time 14287824, (44,40), root:(1345,65), state 0x10, keycode 107 (keysym 0xff61, Print), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False As you can see, an additional KeyRelease event was received for keycode 107, which was never pressed. Other keys show similar behaviour, eg. the "insert" key, which also generates a "KP_Separator" event, the "AltGr" key, which also generates a "left" event, and some others. Here's another example of what happens when pressing the AltGr key: KeymapNotify event, serial 31, synthetic NO, window 0x0, keys: 16 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 KeyPress event, serial 31, synthetic NO, window 0x1200001, root 0x110, subw 0x1200002, time 15027551, (32,49), root:(1333,74), state 0x10, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, XKeysymToKeycode returns keycode: 92 XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 31, synthetic NO, window 0x1200001, root 0x110, subw 0x1200002, time 15027551, (32,49), root:(1333,74), state 0x90, keycode 113 (keysym 0xff51, Left), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False MappingNotify event, serial 34, synthetic NO, window 0x0, request MappingKeyboard, first_keycode 8, count 248 KeyRelease event, serial 34, synthetic NO, window 0x1200001, root 0x110, subw 0x1200002, time 15027671, (32,49), root:(1333,74), state 0x90, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, XKeysymToKeycode returns keycode: 92 XLookupString gives 0 bytes: XFilterEvent returns: False MappingNotify event, serial 34, synthetic NO, window 0x0, request MappingKeyboard, first_keycode 8, count 248 KeyRelease event, serial 34, synthetic NO, window 0x1200001, root 0x110, subw 0x1200002, time 15027671, (32,49), root:(1333,74), state 0x10, keycode 113 (keysym 0xff51, Left), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False Additionally, the 4 arrow keys have stopped to repeat when being kept pressed. All in all, this leaves the keyboard under X hardly usable. Does anybody have an idea of what is happening? Please see the attachment for output of xmodmap -pk thx /markus
# emerge --info Portage 2.1.7.3 (default/linux/x86/10.0/desktop, gcc-4.4.2, glibc-2.10.1-r0, 2.6.31 i686) ================================================================= System uname: Linux-2.6.31-i686-Intel-R-_Core-TM-2_Duo_CPU_P8400_@_2.26GHz-with-gentoo-2.0.1 Timestamp of tree: Sun, 01 Nov 2009 21:20:01 +0000 app-shells/bash: 4.0_p35 dev-java/java-config: 1.3.7-r1, 2.1.9-r1 dev-lang/python: 2.4.4-r13, 2.5.4-r2, 2.6.4, 3.1.1-r1 dev-python/pycrypto: 2.0.1-r8 dev-util/cmake: 2.6.4-r3 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.5.2-r1 sys-apps/sandbox: 2.2 sys-devel/autoconf: 2.13, 2.63-r1 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.2, 1.11 sys-devel/binutils: 2.20 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6a virtual/os-headers: 2.6.30-r1 ACCEPT_KEYWORDS="x86 ~x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium-m -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/4.2/env /usr/kde/4.2/share/config /usr/kde/4.2/shutdown /usr/kde/4.3/env /usr/kde/4.3/share/config /usr/kde/4.3/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O2 -march=pentium-m -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests buildpkg distlocks fixpackages news parallel-fetch protect-owned sfperms strict unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="http://sunsite.cnlab-switch.ch/ftp/mirror/gentoo/ ftp://sunsite.cnlab-switch.ch/mirror/gentoo/ ftp://ftp.solnet.ch/mirror/Gentoo" LDFLAGS="-Wl,-O1" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" 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" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="3dfx X a52 aac acl acpi alsa arts avahi bash-completion berkdb bluetooth branding bzip2 cairo caps cdda cddax cddb cdparanoia cdr cli consolekit cracklib crypt css cups dbus dns dri dts dv dvd dvdr dvdread eds emboss encode esd evo exif fam ffmpeg firefox flac fortran ftp gdbm ggi gif gimp gmp gnome gnutls gphoto2 gpm gstreamer gtk gtkhtml gzip h323 hal hdmi iconv imagemagick imap imlib ipv6 java jce jpeg jpeg2k kde kdeprefix kdrive kontact lame laptop lcms ldap libnotify lirc mad matroska mdnsresponder-compat mikmod mime mmap mmx mng modplug modules mozilla mp3 mp4 mpeg mplayer mudflap mysql ncurses nls nptl nptlonly nsplugin ogg openct opengl openmp oss pam pcmcia pcre pcsc pcsc-lite pda pdf perl php pipechan plasma png ppds pppd python qt3 qt3support qt4 quicktime raw rdesktop readline reflection rss scanner sdl session sip smartcard smp sockets spell spl sql sse sse2 ssl startup-notification svg sysfs tcpd theora threads thunar tiff timidity truetype unicode usb v4l vcd vnc vorbis wav wavpack webkit wifi win32codecs wmf x264 x86 xattr xcomposite xine xinerama xml xorg xpm xscreensaver xulrunner xv xvid zeroconf zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 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="all" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev synaptics vmmouse void alps" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIRC_DEVICES="mceusb" USERLAND="GNU" VIDEO_CARDS="intel vesa vga fbdev vmware nv v4l" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
Created attachment 209026 [details] Output of xmodmap -pk
Update: I recompiled the kernel with INPUT_EVDEV disabled, which makes the symptom go away. But this also makes my synaptics touchpad go away, which I have not been able to configure without evdev (bo errors appear in Xorg.0.log, though; the touchpad is reported as being loaded normally)
Probably you've initially misconfigured your input devices. Attach xorg log, paste your input settings.
Created attachment 209059 [details] Xorg Logfile with INPUT_EVDEV enabled in kernel
Created attachment 209060 [details] xorg.conf This still contains the input options for the synaptics driver, which are not used, though, because Xorg uses HAL.
Created attachment 209062 [details] FDI for synaptics HAL input
Created attachment 209063 [details] Xorg Logfile with INPUT_EVDEV disabled in kernel
First remove this: Option "AllowEmptyInput" "false" just make sure hal is running when server is launched. A minor note: input.x11_options.SHMConfig is no longer required for >=xorg-server-1.6. Disabling INPUT_EVDEV in kernel is, of course, a non-solution.
(In reply to comment #9) > First remove this: > Option "AllowEmptyInput" "false" If I do this, I have no input devices at all after X restart and the following in Xorg.log: (WW) AllowEmptyInput is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled. (WW) Disabling Mouse0 (WW) Disabling Keyboard0 Which leaves me with the power button to interact with the system :-) > just make sure hal is running when server is launched. Yep, hal is running. > A minor note: > input.x11_options.SHMConfig is no longer required for >=xorg-server-1.6. Ok > Disabling INPUT_EVDEV in kernel is, of course, a non-solution. Well, at the moment the only workaround.
Either you're not reading whole log or hal is not running when server starts. It should disable devices mentioned in xorg.conf, but those found by hal should take over. So, post the full log of that case (make sure hal is running, so it won't freeze). How do you launch it any way ? I don't use KDE, so I'm simply launching it in default bootlevel and doing startx afterwards.
Created attachment 209122 [details] Xorg.log with AllowEmptyInput True Also, evdev disabled
(In reply to comment #11) > Either you're not reading whole log or hal is not running > when server starts. > It should disable devices mentioned in xorg.conf, > but those found by hal should take over. Well, it seems to enable the devices automatically before it disables them again. This log was generated like this: Boot & startkde && startx, then modify xorg.conf (comment out AllowEmptyInput), then start second X server (second KDE session) on other pty. First checked if hald was running with ps. > So, post the full log of that case > (make sure hal is running, so it won't freeze). > > How do you launch it any way ? Usually at boot time. Afaik the command chain is /etc/init.d/xdm -> /usr/kde/4.3/bin/startkde -> /usr/bin/startx It has done this for many years, and the problems just appeared with xorg-server-1.7.1. No kernel or KDE upgrade was done at the same time.
Wait a moment, either I'm missing something, or in comment 12 you've tested something that couldn't have worked. xf86-input-evdev was created for /dev/input/event* devices, which are created by INPUT_EVDEV (well, simplifying it a bit).
(In reply to comment #14) > Wait a moment, either I'm missing something, > or in comment 12 you've tested something that couldn't have worked. Correct, the result was an unusable X. kbd and mouse were disabled because of AllowEmptyInput synaptics was disabled because of missing /dev/input/event* It was the log file you had requested in comment #11 displaying that X disabled all input devices if AllowEmptyInput was true.
Just a by-note: I have upgraded to kernel-2.6.32-rc5 -> same result I have switched to using the system's secondary graphic card (nvidia) -> same result krgds /markus
Good news (or kind of): I've rebuilt xorg-server-1.7.1 with the hal USE flag disabled (USE = -hal), and everything seems to be back in working order. So the problem seems to be hal (as usual, in my experience). Do I also need FDIs for HAL and kbd?
You've missed my point - if INPUT_EVDEV was disabled, no /dev/input/event* devices were created, so xf86-input-evdev simply couldn't have worked. (Nearly) nobody mentions the need for INPUT_EVDEV, as by now no sane desktop kernel disables it. I was asking for a log of a case that should work - among other, that means INPUT_EVDEV is enabled.
And hal is necessary i.e. if you have usb keybord/mouse and want things to work if you plug unplug it. I suspect xorg will eventually move to libudev, once that gets more widespread.
(In reply to comment #18) > You've missed my point - if INPUT_EVDEV was disabled, > no /dev/input/event* devices were created, so > xf86-input-evdev simply couldn't have worked. Yes, I know. But evdev is only used for synaptics, and my problem is with the keyboard, not synaptics. kbd works with INPUT_EVDEV enabled or disabled, so I thought I could rule this out in troubleshooting the kbd issue. Maybe my assumption was wrong? > > I was asking for a log of a case that should work > - among other, that means INPUT_EVDEV is enabled. evdev was enabled when the log in comment #5 was generated. kbd and synaptics were working, but kbd produced the duplicate key events that are the reason for this bug report. As said before, as soon as Option AllowEmptyInput False is commented out in xorg.conf, all input devices go away, so - regardless of evdev - I cannot produce a log or a working configuration that has this option commented out.
(In reply to comment #19) > And hal is necessary i.e. if you have usb keybord/mouse > and want things to work if you plug unplug it. I agree. But at the moment, the only combination that works for me is: evdev enabled kernel xorg-server without hal synaptics using evdev and the configuration from xorg.conf I'll have to hardcode additional usb deviced in xorg.conf if I need them.
(In reply to comment #20) > kbd works with INPUT_EVDEV enabled or disabled, To be precise: kbd works well under this conditions: 1) evdev disabled, xorg with or without hal 2) evdev enabled, xorg without hal kbd works flaky (duplicate key events) under this condition: 3) evdev enabled, xorg with hal kbd does not work at all under this condition: 4) evdev enabled or disabled, xorg with or without hal, AllowEmptyIntput True
> kbd does not work at all under this condition: > 4) evdev enabled or disabled, xorg with or without hal, AllowEmptyIntput True and it should not. When hal is working, xf86-input-evdev should take over both mouse and keyboard and case 3) is most probably invalid due to 'Option "AllowEmptyInput" "false"', as that was meant for a different purpose than the one you're using it for. Just 'startx' has worked for me (and most of other people), as long as hal was started before it, in xorg-server 1.6 and continues to do so in 1.7. kbd and mouse are getting disabled with 'AllowEmptyIntput True' to avoid duplicate events. Disabled key repeat on the arrows (though most commonly only on 2 of them - left and the other, that I don't recall right now) happens mostly if something (part of your desktop env or you yourself) is setting XkbRules to 'base', instead of 'evdev'. The recent versions of xf86-input-evdev have been hardcoding it to 'evdev' for quite awhile, so it's either xf86-input-keyboard, part of KDE, or you yourself that's setting it to the incorrect value. As I don't use KDE, I can only recall from forum posts, that there was some "Evdev managed keyboard" setting somewhere in KDE.
(In reply to comment #22) > > To be precise: kbd works well under this conditions: > 1) evdev disabled, xorg with or without hal > 2) evdev enabled, xorg without hal > I can confirm I have this problem to. I have an EVDEV enabled kernel and can't even log in as GDM won't accept my keypresses. Rebuilding xorg-server-1.7.1 with -hal and everything works again. hal is running on my system: 2929 ? Ss 0:00 /usr/sbin/hald --use-syslog --verbose=no 2930 ? S 0:00 hald-runner 2959 ? S 0:00 hald-addon-input: Listening on /dev/input/event2 /dev/input/event1 /dev/input/event0 2963 ? S 0:01 hald-addon-storage: polling /dev/hda (every 2 sec) 2968 ? S 0:00 /usr/libexec/hald-addon-cpufreq 2969 ? S 0:00 hald-addon-acpi: listening on acpid socket /var/run/acpid.socket 26864 ? Sl 0:00 /usr/libexec/gvfs-hal-volume-monitor 27730 pts/1 R+ 0:00 /bin/grep hal
(In reply to comment #23) > > kbd does not work at all under this condition: > > 4) evdev enabled or disabled, xorg with or without hal, AllowEmptyIntput True > and it should not. When hal is working, xf86-input-evdev should take over > both mouse and keyboard To which I totally agree. But it does not. > > and case 3) is most probably invalid due to 'Option "AllowEmptyInput" "false"', > as that was meant for a different purpose than the one you're using it for. As it is the only way to get my keyboard working either in KDE or Gnome, I am quite grateful for this misuse, even if unintended. (I keep repeating myself: I didn't have to set this with xorg-server-1.6, in fact, I didn't change my xorg config at all until I started debugging this issue) > > Just 'startx' has worked for me (and most of other people), as long > as hal was started before it, in xorg-server 1.6 and continues to do so in 1.7. I do in no way doubt that it works for you. > > kbd and mouse are getting disabled with 'AllowEmptyIntput True' to avoid > duplicate events. If duplicate events were the problem, I would suppose that the events were identical? In my case it is different events that are getting generated. > Disabled key repeat on the arrows (though most commonly only on 2 of them > - left and the other, that I don't recall right now) Correct. Arrow up repeats normally, arrow down generates an additional "Return" event ... > happens mostly > if something (part of your desktop env or you yourself) is > setting XkbRules to 'base', instead of 'evdev'. Well, I have not set anything of the like. > The recent versions of xf86-input-evdev have been hardcoding it to > 'evdev' for quite awhile, so it's either xf86-input-keyboard, part of KDE, > or you yourself that's setting it to the incorrect value. > As I don't use KDE, I can only recall from forum posts, > that there was some "Evdev managed keyboard" setting somewhere in KDE. Yes, there is, and I am not using it. I have tried it though, during troubleshooting this, and it did not change the flaky behaviour of kbd. On the other hand, KDE sets this property on a per-user basis, so only after login. But the flaky kbd behaviour (or it not working at all if AllowEmptyInput is set) is already present at the KDE login prompt, so before any user-specific keyboard rules are set. Given the fact that X is behaving nicely in all respects as long as it does not use hal, and given the history of this case, is it frivolous to assume that hal is misbehaving in regard to the keyboard? >
(In reply to comment #24) > I can confirm I have this problem to. I have an EVDEV enabled kernel and can't > even log in as GDM won't accept my keypresses. Rebuilding xorg-server-1.7.1 > with -hal and everything works again. Does this behaviour change if you add this line to the ServerLayout section of your xorg.conf: Option "AllowEmptyInput" "False"?
Two important points: 1. KDE !=Gnome so it may seem alike, but it's most probably not 2. PEBCAK != bug - bugzilla is NOT a support forum And after letting out some steam, let me ask a simple question: did you try ALL possible combinations of the options, more exactly, are you SURE one of them was: 0. INPUT_EVDEV selected 1. AllowEmptyInput true 2. xf86-input-evdev emerged (and reemerged after 1.6 to 1.7 server upgrade) 3. hal running (restarted before restarting xorg-server) 4. "Evdev managed Keyboard" selected Also, do read "man xorg.conf" and the hal/evdev sticky on the forum.
(In reply to comment #26) > (In reply to comment #24) > > > I can confirm I have this problem to. I have an EVDEV enabled kernel and can't > > even log in as GDM won't accept my keypresses. Rebuilding xorg-server-1.7.1 > > with -hal and everything works again. > > Does this behaviour change if you add this line to the ServerLayout section of > your xorg.conf: > Option "AllowEmptyInput" "False"? Yes. Rebuilding with hal and the AllowEmptyInput explicitly set allows me to log in. However once in my session I'm seeing the same multiple keypress issue originally reported. In my case it seems to mainly be affecting the arrow keys, often generating an additional CR. The original xorg.conf I used was the autogenerated one from Xorg --configure. I suspect this will be confusing to new users if the default config fails to work with keys. As far as the multiple keypresses are concerned a single key press of the arrow key generates: MappingNotify event, serial 79, synthetic NO, window 0x0, request MappingKeyboard, first_keycode 8, count 248 MappingNotify event, serial 79, synthetic NO, window 0x0, request MappingKeyboard, first_keycode 8, count 248 ^[[A MappingNotify event, serial 81, synthetic NO, window 0x0, request MappingKeyboard, first_keycode 8, count 248 MappingNotify event, serial 81, synthetic NO, window 0x0, request MappingKeyboard, first_keycode 8, count 248
OK I think I have solved the problem. I think it was a combination of two factors: 1. Old FDI files for HAL 2. Gnome Keyboard Settings My FDI files where quite old so I updated them as suggested in the xorg-1.5 upgrade guide. However I also found reference from ArchLinux: http://wiki.archlinux.org/index.php/Xorg_input_hotplugging#Using_the_evdev_driver_kills_my_arrow_keys.2C_printscreen_is_triggered_instead And realised my Gnome Keyboard Settings where set to my fancy keyboard. I set it to Generic/Evdev managed keyboard. Finally I had to comment out the Option "AllowEmptyInput" "False" that had allowed me to log in before. I think this was responsible for the multiple key-presses under HAL (or at least according to ArchLinux). This is probably something that needs to be covered in the xorg-1.7 upgrade guide.
(In reply to comment 29) For ***** sake, this was dealt with during 1.6 upgrade. Perhaps now either server itself or one of its components (i.e. xkeyboard-config) is more strict about what it accepts, but the bottom line is that most probably your config was already broken, you just didn't know it till now. I really don't know, as my fdi file didn't need any changes for 1.6, except that 'terminate:ctrl_alt_bksp' bit - I had it in new option style shortly after I learned about it and was setting both Rules and Model to 'evdev' right from the start - back then evdev driver wasn't hardcoding it yet, so it was needed. And while dolphin looks like a fish, it's not one - Gnome issues and KDE issues in most cases have very little in common. On related note: "tripled keypress" problem is a well know side effect of 'AllowEmptyInput "false"'.
(In reply to comment #30) > For ***** sake, this was dealt with > during 1.6 upgrade. Hello Rafał No need for shouting. We all very much appreciate your help, nobody is trying to blame our problems on you. > > Perhaps now either server itself or one of its components > (i.e. xkeyboard-config) is more strict about what it accepts, > but the bottom line is that most probably your config was already broken, > you just didn't know it till now. This is very much possible, as I have been migrating my xorg.conf from version to version, and I am almost sure that I have not read every release note that came with a new release. The reason I opened this bug report was that maybe somebody would discover where either my config was wrong or that (as I assume) some basic problem in the whole Xorg-Hal-UDev-DBus-KDE/Gnome entanglement could be found and eliminated. > > I really don't know, as my fdi file didn't need any changes > for 1.6, except that 'terminate:ctrl_alt_bksp' bit - From this I assume that you have a separate FDI file for your keyboard input device. Would you mind sharing it, as I have no such file? > I had it in new option style shortly after I learned about it > and was setting both Rules and Model to 'evdev' right from the start Could you please tell me where you set this? xorg.conf? > > On related note: "tripled keypress" problem is a well know > side effect of 'AllowEmptyInput "false"'. Yes, I've seen the reports, and they do not match my problem at all, which is why I decided that I'd open a new bug report. krgds /markus
Created attachment 209295 [details] my fdi file This is how the file looks for me. Perhaps both Rules and Model are no longer needed, but I don't really care. Names of the keys make it quite obvious, what are they for. I keep it in /etc/hal/fdi/policy/.
I'm checking for input.keys, instead of input.keybord, so the values for power button are overridden too (yes, I should be removing the driver key for it instead, but, once again, I don't really care).
(==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "X.org Configured" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "Internal" (**) | |-->Device "Card0" (**) |-->Screen "Screen1" (1) (**) | |-->Monitor "HDMI-1" (==) No device specified for screen "Screen1". Using the first device section listed. (**) | |-->Device "Card0" (**) |-->Input Device "Mouse0" (**) |-->Input Device "Keyboard0" (**) |-->Input Device "Synaptics Touchpad" (**) Option "AllowEmptyInput" "false" (==) Automatically adding devices (==) Automatically enabling devices Basically, it's all there. You have both xorg.conf-configured input sections _and_ HAL-configured devices. Pick one. If you want HAL, just comment out your InputDevice sections. If you want static devices, use Option "AutoAddDevices" "false" instead of "AllowEmptyInput" (it's a debugging option). In any case, please read http://www.gentoo.org/proj/en/desktop/x/x11/xorg-server-1.5-upgrade-guide.xml Thanks
(In reply to comment #34) > (**) |-->Input Device "Mouse0" > (**) |-->Input Device "Keyboard0" > (**) |-->Input Device "Synaptics Touchpad" > Basically, it's all there. You have both xorg.conf-configured input sections > _and_ HAL-configured devices. Pick one. Oh god. So simple, so obvious. After commenting out all InputDevice entries and adding an FDI file for kbd (thanks, Rafał) xorg with hal is working just as it should. You just have to learn to trust hal ;-) Thanks to everyone. /markus
