Bug 816554 - Keyboard layout does not correspond with default layout selected during installation (F17 TC1)
Summary: Keyboard layout does not correspond with default layout selected during insta...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gdm
Version: 18
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker, AcceptedNTH https://...
Depends On:
Blocks: F17-accepted, F17FinalFreezeExcept
TreeView+ depends on / blocked
 
Reported: 2012-04-26 11:54 UTC by Josef Skladanka
Modified: 2013-01-23 02:06 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-01-23 02:06:46 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
gdm with french keyboard layout (501.76 KB, image/png)
2012-05-18 18:57 UTC, Kamil Páral
no flags Details
gdm with czech keyboard layout (397.28 KB, image/png)
2012-05-18 19:24 UTC, Kamil Páral
no flags Details

Description Josef Skladanka 2012-04-26 11:54:54 UTC
Description of problem:

During installation, I selected czech keyboard layout, during firstboot, I created a user account. In firstboot, the default layout is still OK, but login screen has English layout as default.

How reproducible:

Always


Steps to Reproduce:
1. Install F17, select czech keyboard as default
2. Proceed with firstboot
3. Observe default keyboard layout in gdm
  
Actual results:

English layout is default


Expected results:

Czech layout is default

Comment 1 Petr Schindler 2012-05-16 13:37:18 UTC
English is set as default also in desktop. So I can't log in after screen lock (because of bug 741446).

If I understand to it clearly it is because of bug 603958. But as most of users are listed in gdm and passwords could be in non-US layout (and it is mostly so, because in firstboot is password set in non-US layout) this solution doesn't make sense. I think that default layout should be the one I set in anaconda (it is used for decrypting disks too).

Same bug is in rhel bug 760904

I understand to why is US layout added, but why it is set as default?

I propose this as NTH. This is really annoying and inconsistent.

Comment 2 Kamil Páral 2012-05-18 13:23:47 UTC
+1 NTH

Comment 3 Ray Strode [halfline] 2012-05-18 18:34:16 UTC
Probably related to 

http://git.gnome.org/browse/gdm/commit/?id=7c210e29cc4fd2f2a63900d825e451f63a0d9d0d

though that change was made before F16 was released, so it's pretty old.

Comment 4 Ray Strode [halfline] 2012-05-18 18:35:54 UTC
we can drop that code, but I'd want to make sure we got some testing first. I don't want to rush this in right before release.

Comment 5 Kamil Páral 2012-05-18 18:57:21 UTC
Created attachment 585469 [details]
gdm with french keyboard layout

I have tried to reproduce with F17 RC2 Live i686. I have selected French layout, using "azerty" for my password ("qwerty" on US keyboard). Firstboot has correct French layout and gdm as well. I was able to log in without problems. Locking and unlocking the screen also works OK. Furthermore I haven't seen any option to change keyboard layout in gdm (see screenshot).

Comment 6 Kamil Páral 2012-05-18 19:24:10 UTC
Created attachment 585471 [details]
gdm with czech keyboard layout

I can reproduce with "Czech" layout (that is cz-us-qwertz layout). A keyboard switcher is added to gdm and always defaults to english, so you have to switch it every time if you want to log in.

Comment 7 Adam Williamson 2012-05-18 19:34:13 UTC
So, we've got quite a bit further with this.

GDM has code to always switch to the US layout if it's available (on the grounds that passwords are always ASCII). We maintain this is bogus as there's lots of layouts where you type ASCII different from in the US layout. firstboot - where you create your password - doesn't do this, and we don't think any other DMs do, so the only way to maintain consistency between firstboot and all DMs is for GDM not to do this any more.

Ray is OK with changing the code, but not for F17 release, as it's fragile code and he doesn't think it should be changed so quickly.

The other key thing we figured out is that you only hit this if a US layout is actually available. In most cases, when you pick a different layout, you don't also get a US layout. You can see in the file /usr/share/systemd/kbd-model-map which layouts are 'twinned' with a US layout. The list is:

mk-utf
guj
gur
tml-inscript
ben-probhat
tml-uni
ua-utf
bg_pho-utf8
cz-us-qwertz
ar-digits
ar-qwerty
ar-azerty-digits
ben
bg_bds-utf8
ru
ar-azerty
ar-qwerty-digits
dev
gr

All those layouts will hit this issue (and also https://bugzilla.redhat.com/show_bug.cgi?id=741446 ).

The issue can be 'worked around' - there's a keyboard layout switcher in GDM, it only defaults to US. You just have to figure out that you have to change it to the native layout.

We could ship an update to change this behaviour, after release. Ray says we will try that.

We believe Fedora 16 shipped with the same issue.

Given all the above, I'm -1 blocker on this, regretfully, since the maintainer is pretty clear we can't plausibly fix it in the timeframe and we shipped F16 with the problem and it can be worked around. In theory I'd be +1 NTH but there's no point in that if there won't be a fix in time.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 8 Tim Flink 2012-05-18 21:24:55 UTC
Discussed in the 2012-05-18 blocker bug review meeting. Accepted as NTH because this is rather annoying and non-obvious for users with keyboards which have affected layouts. Rejected as a blocker for Fedora 17 final because there is no feasible fix in the time left before GA, Fedora 16 was released with the same bug and there is a reasonable workaround (select the correct keyboard layout from GDM at login time)

Comment 9 Adam Williamson 2013-01-23 02:06:46 UTC
So I'm pretty sure this was fixed in F18, we tested it. It was intentionally not fixed for F17. Marking as closed for F18.


Note You need to log in before you can comment on or make changes to this bug.