[arch-dev-public] [signoff] kbd-1.15.1

[Roman Kyrylych]

On Wed, Oct 14, 2009 at 12:10, Roman Kyrylych <roman.kyrylych at gmail.com> wrote:
> On Wed, Oct 14, 2009 at 12:20, Allan McRae <allan at archlinux.org> wrote:
>> Roman Kyrylych wrote:
>>> On Wed, Oct 14, 2009 at 12:05, Roman Kyrylych <roman.kyrylych at gmail.com>
>>> wrote:
>>>> On Wed, Oct 14, 2009 at 06:29, Allan McRae <allan at archlinux.org> wrote:
>>>>> sudo /bin/loadkeys -q -u us
>>>>> Password:
>>>>> KDSKBENT: Invalid argument
>>>>> failed to bind key 6 to value 61604
>>>>> KDSKBENT: Invalid argument
>>>>> failed to bind key 46 to value 61602
>>>>> KDSKBDIACRUC: Invalid argument
>>>>>
>>>>> The 1.15 version of kbd works fine.
>>>>>
>>>> I'll investigate this.
>>>> Did anyone experience a similar issue?
>>>>
>>> The keymap was not changed, but there were numerous changes in the parser.
>>> Do you use UTF-8 locale?
>>
>> /etc/rc.conf:
>> LOCALE="en_AU.UTF-8"
>> KEYMAP="us"
>
> I cannot reproduce the problem. :-/

Okay, found the reason.
>From http://bugs.gentoo.org/289265 :
"kbd 1.15 used to temporarily set the kbd_mode to unicode with loadkeys -u. kbd
1.15.1 doesn't. Changing the init script to run kbd_mode before loadkeys gets
rid of the errors."

But in our rc.sysinit there is this code:
if echo "$LOCALE" | /bin/grep -qi utf ; then
        stat_busy "Setting Consoles to UTF-8 mode"
        # UTF-8 consoles are default since 2.6.24 kernel
        # this code is needed not only for older kernels,
        # but also when user has set vt.default_utf8=0 but LOCALE is *.UTF-8.
        for i in /dev/tty[0-9]*; do
                /usr/bin/kbd_mode -u < ${i}
                printf "\033%%G" > ${i}
        done
        # the $CONSOLE check helps us avoid this when running scripts from cron
        echo 'if [ "$CONSOLE" = "" -a "$TERM" = "linux" -a -t 1 ];
then printf "\033%%G"; fi' >>/etc/profile.d/locale.sh
        stat_done
        [ -n "$KEYMAP" ] && status "Loading Keyboard Map: $KEYMAP"
/bin/loadkeys -q -u $KEYMAP
else
        stat_busy "Setting Consoles to legacy mode"
        # make non-UTF-8 consoles work on 2.6.24 and newer kernels
        for i in /dev/tty[0-9]*; do
                /usr/bin/kbd_mode -a < ${i}
                printf "\033%%@" > ${i}
        done
        # the $CONSOLE check helps us avoid this when running scripts from cron
        echo 'if [ "$CONSOLE" = "" -a "$TERM" = "linux" -a -t 1 ];
then printf "\033%%@"; fi' >>/etc/profile.d/locale.sh
        stat_done
        [ -n "$KEYMAP" ] && status "Loading Keyboard Map: $KEYMAP"
/bin/loadkeys -q $KEYMAP
fi

So it looks like the problem should not happen on Arch
when you have 'utf' (case insensitive) in your LOCALE.

To Allan and everyone who have the "KDSKBENT: Invalid argument" issue:
* does your system says 'Setting Consoles to UTF-8 mode' during boot?
* what does the output of `kbd_mode` runned from a tty says?

The patch that makes sure loadkeys -u first sets console in UTF-8 mode
has been submitted upstream,
but I am not sure if there is a need to apply it to our package immediately,
because there is no reason why correct Arch config should have this problem.

P.S.: Note that /usr/bin/kbd_mode -u < ${i} may look weird,
but from man kbd_mode :
"kbd_mode operates on the console specified by the "-C" option;
if there is none, the console associated with stdin is used."
And according to my checks < ${i} works, however it may be better to use -C.

-- 
Roman Kyrylych (Роман Кирилич)