1:18 p.m.
Hi,
I'm seeing a weird problem on my ARM laptop - keymap settings aren't
surviving a reboot. Once I fire up system-config-keyboard (GUI version)
and set it (it seems to remember the correct map, just have to hit OK),
the mappings are correct. After a reboot, it's defaulted to the US map
again (I have UK keyboard).
I have tried symlinking defkeymap.map.gz -> uk.map.gz in
/lib/kbd/keymaps/i386/qwerty, and that didn't help. My
/etc/sysconfig/keyboard seems to be correct:
KEYTABLE="uk"
MODEL="pc105"
LAYOUT="gb"
KEYBOARDTYPE="pc"
Where else should I be looking?
Gordan
2:17 p.m.
On Sun, Aug 07, 2011 at 07:18:26PM +0100, Gordan Bobic wrote:
Hi,
I'm seeing a weird problem on my ARM laptop - keymap settings aren't
surviving a reboot. Once I fire up system-config-keyboard (GUI version)
and set it (it seems to remember the correct map, just have to hit OK),
the mappings are correct. After a reboot, it's defaulted to the US map
again (I have UK keyboard).
I have tried symlinking defkeymap.map.gz -> uk.map.gz in
/lib/kbd/keymaps/i386/qwerty, and that didn't help. My
/etc/sysconfig/keyboard seems to be correct:
KEYTABLE="uk"
MODEL="pc105"
LAYOUT="gb"
KEYBOARDTYPE="pc"
Where else should I be looking?
Under XFCE I seem to have a file that contains my layout:
~/.config/xfce4/xfconf/xfce-perchannel-xml/keyboard-layout.xml
I am quite certain that this file was created by
xfce4-keyboard-settings. There seems to be a
/etc/xdg/xfce4/xfconf/xfce-perchannel-xml/ as well, dropping a default
configuration there will likely work system-wide.
/etc/sysconfig/keyboard is used for the non-graphical console, I'm
unsure if GDM/XFCE knows about/uses that file.
HTH,
Niels
2:21 p.m.
On Sun, 7 Aug 2011 20:17:56 +0100, Niels de Vos
<devos(a)fedoraproject.org> wrote:
On Sun, Aug 07, 2011 at 07:18:26PM +0100, Gordan Bobic wrote:
> Hi,
>
> I'm seeing a weird problem on my ARM laptop - keymap settings aren't
> surviving a reboot. Once I fire up system-config-keyboard (GUI
> version)
> and set it (it seems to remember the correct map, just have to hit
> OK),
> the mappings are correct. After a reboot, it's defaulted to the US
> map
> again (I have UK keyboard).
>
> I have tried symlinking defkeymap.map.gz -> uk.map.gz in
> /lib/kbd/keymaps/i386/qwerty, and that didn't help. My
> /etc/sysconfig/keyboard seems to be correct:
> KEYTABLE="uk"
> MODEL="pc105"
> LAYOUT="gb"
> KEYBOARDTYPE="pc"
>
> Where else should I be looking?
Under XFCE I seem to have a file that contains my layout:
~/.config/xfce4/xfconf/xfce-perchannel-xml/keyboard-layout.xml
I am quite certain that this file was created by
xfce4-keyboard-settings. There seems to be a
/etc/xdg/xfce4/xfconf/xfce-perchannel-xml/ as well, dropping a
default
configuration there will likely work system-wide.
/etc/sysconfig/keyboard is used for the non-graphical console, I'm
unsure if GDM/XFCE knows about/uses that file.
I'm using KDE (at the moment, going to try to get XFCE working soon),
and whatever system-config-keyboard does fixes it, but also whatever it
does isn't surviving a reboot. :-/
Gordan
3:30 p.m.
On 08/07/2011 12:21:30 PM, Gordan Bobic wrote:
I'm using KDE (at the moment, going to try to get XFCE working
soon),
and whatever system-config-keyboard does fixes it, but also whatever
it
does isn't surviving a reboot. :-/
sometimes strace and grep open is a quicker way to find things like this
than using the source
hth
8:18 a.m.
On Sun, 07 Aug 2011 13:30:37 -0700, Andrew Burgess <aab(a)cichlid.com>
wrote:
On 08/07/2011 12:21:30 PM, Gordan Bobic wrote:
> I'm using KDE (at the moment, going to try to get XFCE working
> soon),
> and whatever system-config-keyboard does fixes it, but also
> whatever
> it
> does isn't surviving a reboot. :-/
sometimes strace and grep open is a quicker way to find things like
this
than using the source
Indeed they do, I figured it out.
The problem is that system-config-keyboard edits xorg.conf, and does so
extremely poorly and brokenly. It actually breaks a valid xorg.conf, in
fact, by creating a ServerLayout section without an Identifier entry.
But the real problem is that it creates a broken keyboard entry that
doesn't do anything. Because it loads the keymap at run time, the
settings go live in the current session, but after re-starting xorg,
they don't get re-applied because the InputDevice section that
system-config-keyboard created is broken. Xorg.0.log eventually got me
looking in the right direction. the main thing that the InputDevice
section was missing was the
Option "Device" "/dev/input/event0"
line. Without it the keyboard entry failed, and on Tegra at least, NVEC
keyboard would get detected on that device node and started, which would
default to the US layout every time.
The solution was to fix the InputDevice entry manually, and use the
evdev driver. After that NVEC (found via udev it seems) driver gets
loaded, but it sees that the device is already claimed, so it goes away.
The net result is the keyboard working with the correct map.
I'm not entirely sure what against to file this bug report, or even
where. I'm guessing against system-config-keyboard, but we're not up to
the point where we can build/test rawhide on Fedora on ARM, are we? My
experience is that in genereal, the life cycle of fedora is too short
for the fixes to ever arrive for anything except Rawhide...
Gordan
8:54 a.m.
On Monday, August 08, 2011 08:18:33 AM Gordan Bobic wrote:
On Sun, 07 Aug 2011 13:30:37 -0700, Andrew Burgess
<aab(a)cichlid.com>
wrote:
> On 08/07/2011 12:21:30 PM, Gordan Bobic wrote:
>> I'm using KDE (at the moment, going to try to get XFCE working
>>
>> soon),
>>
>> and whatever system-config-keyboard does fixes it, but also
>>
>> whatever
>> it
>>
>> does isn't surviving a reboot. :-/
>
> sometimes strace and grep open is a quicker way to find things like
> this
> than using the source
Indeed they do, I figured it out.
The problem is that system-config-keyboard edits xorg.conf, and does so
extremely poorly and brokenly. It actually breaks a valid xorg.conf, in
fact, by creating a ServerLayout section without an Identifier entry.
But the real problem is that it creates a broken keyboard entry that
doesn't do anything. Because it loads the keymap at run time, the
settings go live in the current session, but after re-starting xorg,
they don't get re-applied because the InputDevice section that
system-config-keyboard created is broken. Xorg.0.log eventually got me
looking in the right direction. the main thing that the InputDevice
section was missing was the
Option "Device" "/dev/input/event0"
line. Without it the keyboard entry failed, and on Tegra at least, NVEC
keyboard would get detected on that device node and started, which would
default to the US layout every time.
The solution was to fix the InputDevice entry manually, and use the
evdev driver. After that NVEC (found via udev it seems) driver gets
loaded, but it sees that the device is already claimed, so it goes away.
The net result is the keyboard working with the correct map.
I'm not entirely sure what against to file this bug report, or even
where. I'm guessing against system-config-keyboard, but we're not up to
the point where we can build/test rawhide on Fedora on ARM, are we? My
experience is that in genereal, the life cycle of fedora is too short
for the fixes to ever arrive for anything except Rawhide...
I suspect that this is entirely an issue that effects only tegra based devices.
I have a spanish keyboard in my smartbook and ithas all just worked as
expected.
Dennis
9:01 a.m.
On Mon, 8 Aug 2011 08:54:30 -0500, Dennis Gilmore <dennis(a)ausil.us>
wrote:
> >> I'm using KDE (at the moment, going to try to get
XFCE working
> >>
> >> soon),
> >>
> >> and whatever system-config-keyboard does fixes it, but also
> >>
> >> whatever
> >> it
> >>
> >> does isn't surviving a reboot. :-/
> >
> > sometimes strace and grep open is a quicker way to find things
> like
> > this
> > than using the source
>
> Indeed they do, I figured it out.
>
> The problem is that system-config-keyboard edits xorg.conf, and
> does so
> extremely poorly and brokenly. It actually breaks a valid
> xorg.conf, in
> fact, by creating a ServerLayout section without an Identifier
> entry.
> But the real problem is that it creates a broken keyboard entry
> that
> doesn't do anything. Because it loads the keymap at run time, the
> settings go live in the current session, but after re-starting
> xorg,
> they don't get re-applied because the InputDevice section that
> system-config-keyboard created is broken. Xorg.0.log eventually got
> me
> looking in the right direction. the main thing that the InputDevice
> section was missing was the
>
> Option "Device" "/dev/input/event0"
>
> line. Without it the keyboard entry failed, and on Tegra at least,
> NVEC
> keyboard would get detected on that device node and started, which
> would
> default to the US layout every time.
>
> The solution was to fix the InputDevice entry manually, and use the
> evdev driver. After that NVEC (found via udev it seems) driver gets
> loaded, but it sees that the device is already claimed, so it goes
> away.
>
> The net result is the keyboard working with the correct map.
>
> I'm not entirely sure what against to file this bug report, or even
> where. I'm guessing against system-config-keyboard, but we're not
> up to
> the point where we can build/test rawhide on Fedora on ARM, are we?
> My
> experience is that in genereal, the life cycle of fedora is too
> short
> for the fixes to ever arrive for anything except Rawhide...
I suspect that this is entirely an issue that effects only tegra
based devices.
I have a spanish keyboard in my smartbook and ithas all just worked
as
expected.
Did you have a xorg.conf or were you running without it?
I don't see how some parts of this could be Tegra specific,
specifically the fact that it creates a ServerLayout section if there
isn't one there and doesn't create an Identifier entry in it. That along
will make Xorg fail to start. Can you check whetiher it does that on
your system?
Gordan
9:34 a.m.
On Monday, August 08, 2011 09:01:22 AM Gordan Bobic wrote:
On Mon, 8 Aug 2011 08:54:30 -0500, Dennis Gilmore
<dennis(a)ausil.us>
wrote:
>> >> I'm using KDE (at the moment, going to try to get XFCE working
>> >>
>> >> soon),
>> >>
>> >> and whatever system-config-keyboard does fixes it, but also
>> >>
>> >> whatever
>> >> it
>> >>
>> >> does isn't surviving a reboot. :-/
>> >
>> > sometimes strace and grep open is a quicker way to find things
>>
>> like
>>
>> > this
>> > than using the source
>>
>> Indeed they do, I figured it out.
>>
>> The problem is that system-config-keyboard edits xorg.conf, and
>>
>> does so
>>
>> extremely poorly and brokenly. It actually breaks a valid
>>
>> xorg.conf, in
>>
>> fact, by creating a ServerLayout section without an Identifier
>>
>> entry.
>>
>> But the real problem is that it creates a broken keyboard entry
>>
>> that
>>
>> doesn't do anything. Because it loads the keymap at run time, the
>> settings go live in the current session, but after re-starting
>>
>> xorg,
>>
>> they don't get re-applied because the InputDevice section that
>> system-config-keyboard created is broken. Xorg.0.log eventually got
>>
>> me
>>
>> looking in the right direction. the main thing that the InputDevice
>> section was missing was the
>>
>> Option "Device" "/dev/input/event0"
>>
>> line. Without it the keyboard entry failed, and on Tegra at least,
>>
>> NVEC
>>
>> keyboard would get detected on that device node and started, which
>>
>> would
>>
>> default to the US layout every time.
>>
>> The solution was to fix the InputDevice entry manually, and use the
>> evdev driver. After that NVEC (found via udev it seems) driver gets
>> loaded, but it sees that the device is already claimed, so it goes
>>
>> away.
>>
>> The net result is the keyboard working with the correct map.
>>
>> I'm not entirely sure what against to file this bug report, or even
>> where. I'm guessing against system-config-keyboard, but we're not
>>
>> up to
>>
>> the point where we can build/test rawhide on Fedora on ARM, are we?
>>
>> My
>>
>> experience is that in genereal, the life cycle of fedora is too
>>
>> short
>>
>> for the fixes to ever arrive for anything except Rawhide...
>
> I suspect that this is entirely an issue that effects only tegra
> based devices.
> I have a spanish keyboard in my smartbook and ithas all just worked
> as
> expected.
Did you have a xorg.conf or were you running without it?
I don't see how some parts of this could be Tegra specific,
specifically the fact that it creates a ServerLayout section if there
isn't one there and doesn't create an Identifier entry in it. That along
will make Xorg fail to start. Can you check whetiher it does that on
your system?
# Xorg configuration created by system-config-display
Section "ServerLayout"
Identifier "single head configuration"
Screen 0 "Screen0" 0 0
InputDevice "Keyboard0" "CoreKeyboard"
EndSection
Section "InputDevice"
# keyboard added by system-config-display
Identifier "Keyboard0"
Driver "kbd"
Option "XkbModel" "pc105"
Option "XkbLayout" "es"
EndSection
Section "Device"
Identifier "Videocard0"
#Driver "fbdev"
Driver "imx"
EndSection
Section "Screen"
Identifier "Screen0"
Device "Videocard0"
DefaultDepth 24
SubSection "Display"
Viewport 0 0
Depth 24
EndSubSection
EndSection
thats my xorg.conf file. its been awhile since i set it all up so i dont
remeber if it was there before i switched the keyboard from english to spanish
Dennis
9:39 a.m.
On Mon, 8 Aug 2011 09:34:51 -0500, Dennis Gilmore <dennis(a)ausil.us>
wrote:
On Monday, August 08, 2011 09:01:22 AM Gordan Bobic wrote:
> On Mon, 8 Aug 2011 08:54:30 -0500, Dennis Gilmore <dennis(a)ausil.us>
>
> wrote:
> >> >> I'm using KDE (at the moment, going to try to get XFCE
> working
> >> >>
> >> >> soon),
> >> >>
> >> >> and whatever system-config-keyboard does fixes it, but also
> >> >>
> >> >> whatever
> >> >> it
> >> >>
> >> >> does isn't surviving a reboot. :-/
> >> >
> >> > sometimes strace and grep open is a quicker way to find things
> >>
> >> like
> >>
> >> > this
> >> > than using the source
> >>
> >> Indeed they do, I figured it out.
> >>
> >> The problem is that system-config-keyboard edits xorg.conf, and
> >>
> >> does so
> >>
> >> extremely poorly and brokenly. It actually breaks a valid
> >>
> >> xorg.conf, in
> >>
> >> fact, by creating a ServerLayout section without an Identifier
> >>
> >> entry.
> >>
> >> But the real problem is that it creates a broken keyboard entry
> >>
> >> that
> >>
> >> doesn't do anything. Because it loads the keymap at run time,
> the
> >> settings go live in the current session, but after re-starting
> >>
> >> xorg,
> >>
> >> they don't get re-applied because the InputDevice section that
> >> system-config-keyboard created is broken. Xorg.0.log eventually
> got
> >>
> >> me
> >>
> >> looking in the right direction. the main thing that the
> InputDevice
> >> section was missing was the
> >>
> >> Option "Device" "/dev/input/event0"
> >>
> >> line. Without it the keyboard entry failed, and on Tegra at
> least,
> >>
> >> NVEC
> >>
> >> keyboard would get detected on that device node and started,
> which
> >>
> >> would
> >>
> >> default to the US layout every time.
> >>
> >> The solution was to fix the InputDevice entry manually, and use
> the
> >> evdev driver. After that NVEC (found via udev it seems) driver
> gets
> >> loaded, but it sees that the device is already claimed, so it
> goes
> >>
> >> away.
> >>
> >> The net result is the keyboard working with the correct map.
> >>
> >> I'm not entirely sure what against to file this bug report, or
> even
> >> where. I'm guessing against system-config-keyboard, but we're
> not
> >>
> >> up to
> >>
> >> the point where we can build/test rawhide on Fedora on ARM, are
> we?
> >>
> >> My
> >>
> >> experience is that in genereal, the life cycle of fedora is too
> >>
> >> short
> >>
> >> for the fixes to ever arrive for anything except Rawhide...
> >
> > I suspect that this is entirely an issue that effects only tegra
> > based devices.
> > I have a spanish keyboard in my smartbook and ithas all just
> worked
> > as
> > expected.
>
> Did you have a xorg.conf or were you running without it?
>
> I don't see how some parts of this could be Tegra specific,
> specifically the fact that it creates a ServerLayout section if
> there
> isn't one there and doesn't create an Identifier entry in it. That
> along
> will make Xorg fail to start. Can you check whetiher it does that
> on
> your system?
>
# Xorg configuration created by system-config-display
Section "ServerLayout"
Identifier "single head configuration"
Screen 0 "Screen0" 0 0
InputDevice "Keyboard0" "CoreKeyboard"
EndSection
Section "InputDevice"
# keyboard added by system-config-display
Identifier "Keyboard0"
Driver "kbd"
Option "XkbModel" "pc105"
Option "XkbLayout" "es"
EndSection
Section "Device"
Identifier "Videocard0"
#Driver "fbdev"
Driver "imx"
EndSection
Section "Screen"
Identifier "Screen0"
Device "Videocard0"
DefaultDepth 24
SubSection "Display"
Viewport 0 0
Depth 24
EndSubSection
EndSection
thats my xorg.conf file. its been awhile since i set it all up so i
dont
remeber if it was there before i switched the keyboard from english
to spanish
Right, that's why it works for you. Back up your xorg.conf while X is
running, and remove the ServerLayout section. Then try
system-config-keyboard and see what it does. If I'm right, it'll create
a ServerLayout section without the Identifier entry.
Gordan
4643
days inactive
4644
days old
8 comments
4 participants
participants (4)
-
Andrew Burgess -
Dennis Gilmore -
Gordan Bobic -
Niels de Vos