Description of problem: After logging in KDE, pressing Ctrl+C causes X server restarted and back to login interface, just like Ctrl+Alt+Backspace. After log in for a second time, Ctrl+C will not cause X restart, but key "2" will cause the same result. All other number keys are normal. Version-Release number of selected component (if applicable): kdebase-workspace-4.1.2-6.fc10.i386 How reproducible: Always Steps to Reproduce: 1. boot the computer 2. log in KDE 3. press Ctrl+C 4. X restarted 5. log in KDE again 6. press number "2" key 7. X restarted Actual results: X restarted unexpectedly Expected results: Keys work normally. Additional info: The related output in /var/log/messages are: Oct 19 12:22:33 fedora pulseaudio[2651]: main.c: Called SUID root and real-time/high-priority scheduling was requested in the configuration. However, we lack the necessary priviliges: Oct 19 12:22:33 fedora pulseaudio[2651]: main.c: We are not in group 'pulse-rt' and PolicyKit refuse to grant us priviliges. Dropping SUID again. Oct 19 12:22:33 fedora pulseaudio[2651]: main.c: For enabling real-time scheduling please acquire the appropriate PolicyKit priviliges, or become a member of 'pulse-rt', or increase the RLIMIT_NICE/RLIMIT_RTPRIO resource limits for this user. Oct 19 12:22:33 fedora pulseaudio[2651]: main.c: High-priority scheduling enabled in configuration but not allowed by policy. Oct 19 12:22:33 fedora pulseaudio[2651]: core-util.c: setpriority(): Permission denied Oct 19 12:22:34 fedora pulseaudio[2654]: alsa-util.c: Cannot find fallback mixer control "Mic". Oct 19 12:22:35 fedora pulseaudio[2695]: pid.c: Daemon already running. Oct 19 12:22:55 fedora kdm[2167]: X server for display :0 terminated unexpectedly Oct 19 12:22:55 fedora acpid: client connected from 2767[0:0] Oct 19 12:23:03 fedora kernel: hda-intel: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj. Oct 19 12:23:04 fedora pulseaudio[2654]: module-alsa-source.c: Increasing wakeup watermark to 40.00 ms Oct 19 12:23:04 fedora pulseaudio[2654]: module-alsa-sink.c: Increasing wakeup watermark to 40.00 ms Oct 19 12:23:05 fedora pulseaudio[2654]: module-alsa-source.c: Increasing wakeup watermark to 80.00 ms Oct 19 12:23:05 fedora pulseaudio[2654]: module-alsa-sink.c: Increasing wakeup watermark to 80.00 ms Oct 19 12:23:05 fedora pulseaudio[2654]: module-alsa-source.c: Increasing wakeup watermark to 160.00 ms Oct 19 12:23:05 fedora pulseaudio[2654]: module-alsa-sink.c: Increasing wakeup watermark to 160.00 ms Oct 19 12:23:06 fedora pulseaudio[2654]: module-alsa-sink.c: Increasing wakeup watermark to 320.00 ms Oct 19 12:23:10 fedora pulseaudio[3220]: pid.c: Daemon already running. Oct 19 12:23:25 fedora kdm[2167]: X server for display :0 terminated unexpectedly Oct 19 12:23:25 fedora acpid: client connected from 3303[0:0] Oct 19 12:23:40 fedora pulseaudio[3764]: pid.c: Daemon already running.
This sounds like an X11 input bug to me, not a KDE bug.
Can fully reproduce with xorg-x11-server-Xorg-1.5.2-5.fc10.i386 and xorg-x11-drv-evdev-2.0.7-1.fc10.i386. Somehow it looks like some key combination "go through" X and are not captured -- i.e., Ctrl-C apparently kills something somewhere like it was producing SIGINT instead of copying text. Most likely relates to couple of similar bugs, which I will close as duplicates against this one.
Created attachment 320825 [details] /var/log/Xorg.0.log
The previous attachment is from the running Xorg, so I am not sure how accurate it is (except there are plenty of (WW) and (EE) there). Unfortuantely /var/log/Xorg.0.log.old is zero-byte-long (which is remarkable in itself).
Created attachment 320826 [details] /var/log/dmesg
possible duplicates -- bug 467539, and bug 467479?
*** Bug 467539 has been marked as a duplicate of this bug. ***
*** Bug 467573 has been marked as a duplicate of this bug. ***
Bit me, too. I would go as far as to say it's a release blocker.
*** Bug 467646 has been marked as a duplicate of this bug. ***
@Rathann (comment #9): +1
Fixed with xorg-x11-server-1.5.2-6. The changes in 1.5.2-5 didn't trigger correctly if no xorg.conf was present, so a one-line fix was needed. See last hunk of http://cvs.fedoraproject.org/viewvc/rpms/xorg-x11-server/devel/xserver-1.5.2-disable-kbd-mouse.patch?revision=1.2&view=markup
Confirmed fixed, thanks.
Hi there. Can confirm it's fixed on xorg-x11-server-Xorg-1.5.2-7. Thank you all!
The bug seems to be back again. My installation is a combination of randomly updated packages, but no dependencies are broken. rpm -qa xorg*|sort: xorg-x11-apps-7.3-5.fc10.i386 xorg-x11-drv-evdev-2.1.0-3.fc11.i386 xorg-x11-drv-fbdev-0.4.0-3.fc11.i386 xorg-x11-drv-vesa-2.1.0-1.fc11.i386 xorg-x11-drv-void-1.1.1-9.fc9.i386 xorg-x11-filesystem-7.3-2.fc10.noarch xorg-x11-font-utils-7.2-6.fc10.i386 xorg-x11-fonts-100dpi-7.2-6.fc9.noarch xorg-x11-fonts-75dpi-7.2-6.fc9.noarch xorg-x11-fonts-ISO8859-1-100dpi-7.2-6.fc9.noarch xorg-x11-fonts-ISO8859-1-75dpi-7.2-6.fc9.noarch xorg-x11-fonts-Type1-7.2-6.fc9.noarch xorg-x11-fonts-misc-7.2-6.fc9.noarch xorg-x11-fonts-truetype-7.2-3.fc8.noarch xorg-x11-proto-devel-7.4-12.fc11.noarch xorg-x11-server-Xorg-1.5.99.3-5.fc11.i386 xorg-x11-server-Xvfb-1.5.99.3-5.fc11.i386 xorg-x11-server-common-1.5.99.3-5.fc11.i386 xorg-x11-server-utils-7.4-3.fc10.i386 xorg-x11-twm-1.0.3-3.fc10.i386 xorg-x11-util-macros-1.2.1-1.fc11.noarch xorg-x11-utils-7.4-3.fc10.i386 xorg-x11-xauth-1.0.2-5.fc10.i386 xorg-x11-xinit-1.0.9-4.fc10.i386 xorg-x11-xkb-utils-7.2-7.fc10.i386 xorg-x11-xtrans-devel-1.2.2-1.fc11.noarch (I have also observed that with xorg-x11-server-*-1.5.99.3-1.fc11.i386, before my "yum update xorg*".) I'm attaching my xorg.conf and current Xorg.0.log.
Created attachment 328188 [details] Xorg.0.log - kasal
Created attachment 328189 [details] xorg.conf - kasal
Cannot reproduce with fully upgraded Rawhide, but I still think it is worthy to check whether we haven't dropped the patch for this somewhere on the way.
Remove the option AllowEmptyInput "false". With this setting, you're telling the X server to force the presence of mouse/kbd devices. You don't have either driver installed though, so your input devices are provided by evdev. However, because of AEI "false", the console raw mode is not set and evdev can thus cancel the server. Simply removing the option gives you the same input devices as now anyway. Closing as CURRENTRELEASE, this bug is now fixed in F10 and rawhide.
*** Bug 483820 has been marked as a duplicate of this bug. ***
I recently filed a bug 483820 reporting that with AEI set to "no" every keystroke shows up three times. It was closed as a duplicate of this bug and here it says that this is a misconfiguration. If this is really the case then I have the following questions: - If AEI set to "no" is a misconfiguration then why this flag exists at all? - As 'kbd', 'mouse' or 'vmmouse' drivers are disabled when AEI is "yes" then why these drivers do exist? - What are you supposed to do if you really need, say, 'vmmouse'? - Recently I had a situation when I had to set AEI to "no" or I had no input at all and that is why I had this flag set when after updates whenI was hit by this "triplicates" issue; am I supposed to play guessing games which will be a "misconfiguration" today?
OK, taking back, passing to developers.
(In reply to comment #21) > I recently filed a bug 483820 reporting that with AEI set to "no" every > keystroke shows up three times. It was closed as a duplicate of this bug and > here it says that this is a misconfiguration. If this is really the case then > I have the following questions: > - If AEI set to "no" is a misconfiguration then why this flag exists at all? > - As 'kbd', 'mouse' or 'vmmouse' drivers are disabled when AEI is "yes" then > why these drivers do exist? > - What are you supposed to do if you really need, say, 'vmmouse'? > - Recently I had a situation when I had to set AEI to "no" or I had no input > at all and that is why I had this flag set when after updates whenI was hit by > this "triplicates" issue; am I supposed to play guessing games which will be a > "misconfiguration" today? From the xorg.conf man page: Option "AllowEmptyInput" "boolean" If enabled, don’t add the standard keyboard and mouse drivers, if there are no input devices in the config file. Enabled by default if AutoAddDevices and AutoEnableDevices is enabled, otherwise disabled. If AllowEmptyInput is on, devices using the kbd or mouse driver are ignored. Option "AutoAddDevices" "boolean" If this option is disabled, then no devices will be added from HAL events. Enabled by default. Triplicate keystrokes are a sign that you add evdev and kbd devices, so you have AutoAddDevices on, and AEI on at the same time. vmmouse in rawhide doesn't need any special configuration anymore, the matching bits should be added automatically. check the output of lshal in the VM, it should list input.x11_driver.vmmouse. Is this the case? If you want to force vmmouse etc. through the configuration, disabling AutoAddDevices is the right approach.
> From the xorg.conf man page: Yes, I know what manpage says. AutoEnableDevices was not explicitely set. In any case xorg.conf in use is attached as https://bugzilla.redhat.com/attachment.cgi?id=330765 to a bug 483820. That configuration file was required for a while as I needed some input devices working. After recent rawhide updates I got that "tripple stutter" and had to do configuration change to restore sanity. > vmmouse in rawhide doesn't need any special configuration anymore This is what I see in logs with AEI on: "(WW) AllowEmptyInput is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled." Do you mean that vmmouse is supported now through evdev as well?
(In reply to comment #24) > > vmmouse in rawhide doesn't need any special configuration anymore > > This is what I see in logs with AEI on: "(WW) AllowEmptyInput is on, devices > using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled." Do you mean that > vmmouse is supported now through evdev as well? hmm, that's a bit ambiguous, you're right. What it is supposed to mean is that such devices from the xorg.conf file are ignored. vmmouse is now added through the HAL mechanism, just like the other devices.
Closing the bug again, as stated in Comment #24, the configuration change fixed the problem.