Bug #121

Any keypboard but US-Enlish does not work

Added by Jörg Schilling almost 5 years ago. Updated over 4 years ago.

Status:ClosedStart date:2010-08-30
Priority:NormalDue date:
Assignee:-% Done:


Target version:-
Difficulty: Tags:


The reason is an incompatible change in the handling of kbd -i

Before /etc/default/kbd did not have a layout section by default and thus knd -i was layout agnostic.

Now /etc/default/kbs was migrated to SMF and there is a defaul lauout.

As a result any layout change in the scripts are later reset by a kbd -i call

Solution: edit /lib/svc/method/keymap and reverse order:

change /usr/bin/kbd -i before calling /usr/lib/set_keyboard_layout and

Related issues

Duplicates illumos gate - Bug #310: svc:/system/keymap ignores eeprom layout New 2010-10-06


#1 Updated by Rich Lowe almost 5 years ago

Wouldn't changing the order here cause the the prom/bootenvrc property to take precedence over the users configuration of the keymap service (which is the correct way to set the keyboard layout, replacing /etc/default/kbd.)

How would that interact with a keyboard which reported its layout in hardware? (as, I believe, the Sun keyboard do).

#2 Updated by Garrett D'Amore almost 5 years ago

So as richard says, there is this flag day:


I think the change proposed by the submitter is wrong, bootenvrc and prom settings should not override user preference.

The documentation (man page for kbd) is outdated and needs fixing.

But otherwise this bug could probably be closed/rejected.

#3 Updated by Jörg Schilling almost 5 years ago

My impression is that the people who implemented the change described in http://static.opensolaris.org/on/flagdays/pages/20100720182505.html have no idea how Solaris is working as they ignored important constraints. The changes have obviously been integrated without testing. This change recently made by Oracle makes a last resort emergency control the only way to control the keyboard layout settings. As a result we are pushed back to year 1985 - plug and play no longer works.

In Spring 1986, our Berthold 155 key typesetting keyboard was the first keyboard for SunOS that reported the layout information to the kernel.

In Spring 1988, Sun came out with the Sun-4 keyboard that also reported layout information to the kernel.

USB keyboards (available since the late 1990s) report layout information to the kernel.

Historic serial PC keyboards are the only exception that needs a manual setup. The documented way to do this is to call e.g. "eeprom keyboard-layout=German". This manual setup still results in a value readable from the kernel.

All "plug and play" keyboards will work correctly only if the keyboard layout it retrieved from the kernel. This is impossible after the recent change made by Oracle as all information from the kernel is currently ignored.

Life CDs and install CDs typically call "kbd -s" and the kbd(1) program presents a menue to manually select the layout. This does not work either after the recent change made by Oracle as the setup from "kbs -s" is overwritten with "US-English" later and before the layout is loaded into the kernel driver tables.

My change reverts the buggy behavior to the documented behavior and to what users expect.

There could be an alternate way to fix the bug introduced by Oracle:

If it is possible to set the smf layout property to an empty string and if kbd(1) either accepts this or is changed to accept the empty value and if kbd(1) does not modify the layout (if called kbd -i), then we had something similar to the implementation that was still in effect with build 130.

BTW: is there a documentation for the smf properties? I would guess "svccfg" but I cannot find the related information.

#4 Updated by Garrett D'Amore almost 5 years ago

The vast majority of USB keyboards I've worked with, including several from locales other than the US, do not report their country code setting properly. In fact, the only keyboards that I've seen do this correctly are the Sun type 6 and type 6 keyboards.

I agree that we should respect the defaults supplied by hardware if there is no user override supplied.

However, it would appear that the original fix proposed for this problem, would prevent any chance for users to configure something other than what the hardware reports. This is unacceptable.

So, please go back and figure out a solution which uses the hardware to provide sensible defaults, but still allows for software overrides.

#5 Updated by Garrett D'Amore over 4 years ago

  • Status changed from New to Closed

Closing this... 310 tracks the main issue here.

Also available in: Atom