Bug 1134406
| Summary: | xine generates Shift_L and Control_L key events from time to time | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Mike FABIAN <mfabian> | ||||
| Component: | xine-ui | Assignee: | Michael J Gruber <mjg> | ||||
| Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 20 | CC: | mfabian, mjg, stsp2 | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2015-06-29 22:17:00 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
Created attachment 931462 [details]
xine-generates-shift-l-and-control-l-key-events.ogv
Video showing the problem.
xine is doing this on purpose to prevent the screensaver from starting while watching a video. See: https://lists.debian.org/debian-release/2009/01/msg00035.html https://bugs.archlinux.org/task/17400 I think this is not a good idea and xine should stop doing that. Maybe this can be disabled in the config file: mfabian@ari:~ $ grep -C 1 screensaver ~/.xine/config # numeric, default: 10 #gui.screensaver_timeout:10 mfabian@ari:~ $ Thanks Mike for your analysis! Just a few questions: - Is there really no API to prevent the screen-saver from starting? I can't believe that, there should be one around. - It is said that xine generates Scroll Lock, not LShift. Well, knowing its a xine bug, I can just fix it by rpm -e xine Much simpler than to "fix" an ibus problems. :) (In reply to Stas Sergeev from comment #6) > Thanks Mike for your analysis! > Just a few questions: > - Is there really no API to prevent the screen-saver from starting? I think there is for the Gnome screensaver. Because https://lists.debian.org/debian-release/2009/01/msg00035.html says: msg00035> It also suppresses gnome-screensaver cleanly, so we could disable the msg00035> key injection code without affecting GNOME users. However, this would msg00035> be a regression for users of the X server screensaver, xscreensaver or msg00035> the KDE screensaver. > I can't believe that, there should be one around. > - It is said that xine generates Scroll Lock, not LShift. Wikipedia said that, yes. Maybe it is out of date. I observed that xine generates left shift and left control key events. > Well, knowing its a xine bug, I can just fix it by > rpm -e xine > Much simpler than to "fix" an ibus problems. :) This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |
Description of problem: xine sometimes generates Shift_L and Control_L key events even when the keyboard is not touched at all! Version-Release number of selected component (if applicable): xine-ui-0.99.8-2.fc20.x86_64 How reproducible: Always. Steps to Reproduce: 1. Run “xine somevideo.mp4” from a terminal 2. In another terminal, run “xev” 3. Click the “xev” window with the mouse and leave the mouse there 4. Do not touch the keyboard and the mouse anymore, just watch the standardoutput of xev in the terminal Actual results: From time to time (about every 10 seconds), Shift_L and Control_L key events are seen: KeyPress event, serial 267, synthetic NO, window 0x4800001, root 0xb5, subw 0x0, time 33735198, (86,102), root:(2806,591), state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 267, synthetic NO, window 0x4800001, root 0xb5, subw 0x0, time 33735198, (86,102), root:(2806,591), state 0x1, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 268, synthetic NO, window 0x4800001, root 0xb5, subw 0x0, time 33745665, (86,102), root:(2806,591), state 0x0, keycode 66 (keysym 0xffe3, Control_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 268, synthetic NO, window 0x4800001, root 0xb5, subw 0x0, time 33745665, (86,102), root:(2806,591), state 0x4, keycode 66 (keysym 0xffe3, Control_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False I.e. xine seems to generate these key events although nobody is actually typing Shift and Control. Expected results: No such key events should be generated. Additional info: These key events cause problems when ibus is running, for example when using ibus-table. Because the left shift key in ibus table is a shortcut key to switch between table mode (Chinese, Russian, ...) and direct input mode (direct keyboard input). Therefore, when a use types stuff using ibus-table while xine is running, ibus-table surprisingly switches the input mode although the user has not typed shift. (To exclude that ibus has something to do with this problem, I stopped ibus with “ibus exit” before doing the above test).