Bug 303578 (ThomasFM) - 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.
Summary: The closing of the laptop lid and subsequent changing of the keyboard layouts...
Status: RESOLVED FIXED
Alias: ThomasFM
Product: kxkb
Classification: Unmaintained
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR minor
Target Milestone: ---
Assignee: Andriy Rysin
URL:
Keywords: usability
Depends on:
Blocks:
 
Reported: 2012-07-15 19:01 UTC by Thomas
Modified: 2013-03-05 10:00 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
.xsession-errors from a clean login documenting the bug. (49.75 KB, text/plain)
2012-07-17 06:53 UTC, Thomas
Details
.xsession-errors file documenting the bug, using a new .kde directory (64.76 KB, application/octet-stream)
2012-07-17 08:07 UTC, Thomas
Details
.xsession-errors with debug output from kded plus a few others (586.89 KB, text/plain)
2012-07-18 10:49 UTC, Thomas
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas 2012-07-15 19:01:25 UTC
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
Comment 1 Andriy Rysin 2012-07-15 19:20:37 UTC
Please update to latest 4.8 KDE version, there were some fixes for this.
Comment 2 Thomas 2012-07-16 09:24:10 UTC
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.
Comment 3 Andriy Rysin 2012-07-17 05:40:08 UTC
it seems something is resetting your layouts
could you please clear your xsession-errors, relogin, reproduce the problem and attach full xsession-errors file?
Comment 4 Thomas 2012-07-17 06:53:27 UTC
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.
Comment 5 Thomas 2012-07-17 08:07:15 UTC
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.
Comment 6 Andriy Rysin 2012-07-17 11:03:00 UTC
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!
Comment 7 Thomas 2012-07-18 10:49:26 UTC
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.
Comment 8 Andriy Rysin 2012-07-18 20:34:59 UTC
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
Comment 9 Andriy Rysin 2013-02-28 03:53:50 UTC
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.
Comment 10 Thomas 2013-03-05 10:00:48 UTC
Thank you very much.  I hope to test it once my distro transitions to KDE 4.10.1.