| Summary: | The closing of the laptop lid and subsequent changing of the keyboard layouts produces entries in .xsession-errors, along with preventing the keyboard layout applet in the system tray from updating. | ||
|---|---|---|---|
| Product: | [Unmaintained] kxkb | Reporter: | Thomas <mezeyftamas> |
| Component: | general | Assignee: | Andriy Rysin <arysin> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | mezeyftamas |
| Priority: | NOR | Keywords: | usability |
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: |
.xsession-errors from a clean login documenting the bug.
.xsession-errors file documenting the bug, using a new .kde directory .xsession-errors with debug output from kded plus a few others |
||
Please update to latest 4.8 KDE version, there were some fixes for this. I've updated KDE to version 4.8.4. The upgrade produced a marked improvement as the bug now shows up randomly as opposed to consistently. However, repeatedly closing the lid and opening it will eventually produce the again bug. Also, as before, when the bug manifested itself, the same entries appeared within .xsession-errors as above. it seems something is resetting your layouts could you please clear your xsession-errors, relogin, reproduce the problem and attach full xsession-errors file? Created attachment 72572 [details]
.xsession-errors from a clean login documenting the bug.
Here's the .xsession-errors file. I've appended a little note ("Start of lid closing/opening to reproduce bug") prior to lowering the lid. Lowering the lid produced the bug right on queue, so the file shouldn't be too long to peruse. Thank you for your help.
Created attachment 72573 [details]
.xsession-errors file documenting the bug, using a new .kde directory
To address an unrelated issue, I've created a new .kde directory. Upon adding my four keyboard layouts and having lowered, then raised the lid, the bug manifested again. It seems that there is a 100% chance of producing the bug the first time the lid is closed/opened, but this seems to improve to a somewhat more random pattern once enough such raising/lowering of the lid and subsequent corrections occur within the session.
thanks, could you please turn on debug output for keyboard daemon and then attach the xsession-errors? it should generate more output related to keyboard layouts, thank you! Created attachment 72606 [details]
.xsession-errors with debug output from kded plus a few others
As I couldn't find an explicit keyboard daemon in kdebugdialog, I've opted for the shotgun approach by enabling debug output from kded, kscreenlocker, plasma-desktop, kfile, klocale, kdeui and khotkeys. I sure hope that there is enough in this file to proceed on, otherwise we're back to square one.
Thanks, I don't see anything that would jump at me... I'm currently on vacation and will try to take a closer look when I'm back Sorry for the delay, I think I finally got to the root of the problem (see https://bugs.kde.org/show_bug.cgi?id=290571) and hopefully fixed it in 4.10.1. If you still see it in 4.10.1 please reopen and attach your /var/log/Xorg.0.log after layouts stop working. Thank you very much. I hope to test it once my distro transitions to KDE 4.10.1. |
KDE Version: 4.7.4 OS: Linux Mint Debian Edition (based off of Debian Testing) Kernel: 3.2.0-2-amd64 Installed from LMDE repository (Update Pack 4) The bug affects the keyboard layout system tray applet as well as the locked screen dialog if the system is so configured as to lock the screen upon the closing of the laptop lid. Furthermore, to address any concerns that this might be a bug with X, I would like to state that I could not reproduce this bug with Cinnamon which itself runs atop of Gnome 3.2. The issue involves the following. Upon closing and then subsequently opening the laptop lid (Dell XPS M1530), the keyboard layout indicator in the system tray fails to update. In addition, if I would need to log back in from a locked session induced by the closing of the lid, I would not be presented with a flag/label representation of the current layout. In either of these cases, I am still able to issue changes to the layout via a global shortcut (set to left win), or via the mouse for the case of the applet only. These changes, however, are not reflected by either the applet or the locked screen dialog. This issue with the system tray icon can be remedied temporarily via any committed change to the layout system. However, upon closing the lid again, the buggy behavior returns. Lastly, simply locking the screen in a session that never had the lid closed (or in a session where the issue was corrected as above) produces the expected results; namely that the keyboard layout is indicated (either as a label or as a flag). Furthermore, again in the same context, the keyboard layout applet works as expected. Reproducible: Always Steps to Reproduce: 1. Start a session 2. Close the laptop lid. 3. Open the lid after say 5 seconds. 4. If you need to unlock a session, note the absence of the layout indicator in the dialog. 5. Change the layout with your global shortcut. Test the actual change of layouts in a text editor to verify. 6. Commit any change to the layout system (say change from Flag to Label etc); and note that the problem has gone away (but only temporarily). 7. Repeat step 2 through 6 to verify. Actual Results: After the lid has been closed and subsequently opened, any changes to the layout issued via a global shortcut produces entries in .xsession-errors whenever the layout is not the first in the list. Thus for example, I have added the following layouts in the order listed: US, HU, GR and DE. The .xsession-errors had the following entries after I repeatedly switched between the keyboard layouts, after having closed the laptop lid: Switch to HU: kded(4943) X11Helper::getCurrentLayout: Current group number 1 is outside of current layout list ("us") kded(4943) X11Helper::getCurrentLayout: Current group number 1 is outside of current layout list ("us") Switch to GR: kded(4943) X11Helper::getCurrentLayout: Current group number 2 is outside of current layout list ("us") kded(4943) X11Helper::getCurrentLayout: Current group number 2 is outside of current layout list ("us") Switch to DE: kded(4943) X11Helper::getCurrentLayout: Current group number 3 is outside of current layout list ("us") kded(4943) X11Helper::getCurrentLayout: Current group number 3 is outside of current layout list ("us") Switch to US: No entires added to .xsession-errors Switch to HU: kded(4943) X11Helper::getCurrentLayout: Current group number 1 is outside of current layout list ("us") kded(4943) X11Helper::getCurrentLayout: Current group number 1 is outside of current layout list ("us") etc ..., where, these entries would repeat cyclically. Expected Results: The system tray keyboard layout applet should always indicate the current layout when it is switched. In addition, if the session gets locked via the closing of the laptop lid, the current layout should be indicated in the locked screen dialog. setxkbmap -print xkb_keymap { xkb_keycodes { include "evdev+aliases(qwerty)" }; xkb_types { include "complete" }; xkb_compat { include "complete" }; xkb_symbols { include "pc+us+hu:2+gr:3+de:4+inet(evdev)+group(lwin_toggle)+group(rwin_toggle)+terminate(ctrl_alt_bksp)" }; xkb_geometry { include "pc(pc101)" }; }; cat ~/.kde/share/config/kxkbrc [Layout] DisplayNames=,,, LayoutList=us,hu,gr,de LayoutLoopCount=-1 Model=pc101 Options=terminate:ctrl_alt_bksp,grp:lwin_toggle ResetOldOptions=true ShowFlag=false ShowLayoutIndicator=true ShowSingle=false SwitchMode=Global Use=true