Le lundi 25 février 2008 à 09:16 -0600, Clark Williams a écrit :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Nicolas Mailhot wrote:
> > Le Sam 23 février 2008 21:14, David Nielsen a écrit :
> >>
> >> For me the new xserver is some what less broken, everything seems to
> >> work
> >> except the keyboard is acting mighty funny. I press up arrow and the
> >> gnome-screenshot application starts up. Capslock seems to be on at all
> >> times regardless of the setting.
> >
> > Latest xorg server is linked to hal. That means hal-auto-input got
> > enabled, and your input devices were probably switched to evdev. (this
> > is good).
>
> For some definition of good (presently not mine) :)
That's Rawhide for you. Latest and greatest :) Thought enabling
auto-input earlier in the cycle would have been good.
Anyway evdev is good because many extented multimedia keys won't work
without it.
> > More accurately, in an hal-auto-input world, you need to either:
>
> I have no idea how to tell XFCE to use evdev, so...
Does not matter if it's GNOME or KDE or XFCE. if you have something
that sets the xkb parameters for your desktop, it needs to be set to
evdev as that's what xorg will use in auto-input (otherwise you inherit
xorg conf or gdm conf).
Anyway since I chose option 1 here is my (working) conf
1. In xorg.conf, to select hal input conf exclusively and avoid
conflicts
Section "ServerFlags"
Option "AllowEmptyInput" "True"
Option "AutoAddDevices" "True"
Option "AutoEnableDevices" "True"
EndSection
AllowEmptyInput is mandatory or xorg will set up its own input that will
compete with the hal setup (that will be honoured in parallel for the
same devices, nice isn't it?). The rest I'm not so sure of, in
particular the third one.
2. In custom-created /etc/hal/fdi/policy/10-x11-keyboard-layout.fdi, to
set the default layouts so I don't have to rely on the DE and stuff like
initial password input works
<?xml version="1.0"?>
<deviceinfo version="0.2">
<device>
<match key="input.xkb.rules" contains="base">
<merge key="input.xkb.layout" type="string">fr,ru</merge>
<merge key="input.xkb.variant" type="string">oss,winkeys</merge>
<merge key="input.xkb.options"
type="string">grp:lwin_toggle,grp_led:scroll,compose:rwin</merge>
</match>
</device>
</deviceinfo>
Here I have selected fr(oss) and ru(winkeys)
Due to hal making no provision for structured configurations had I
wanted fr + ru(winkeys) I'd have this
<?xml version="1.0"?>
<deviceinfo version="0.2">
<device>
<match key="input.xkb.rules" contains="base">
<merge key="input.xkb.layout" type="string">fr,ru</merge>
<merge key="input.xkb.variant" type="string">,winkeys</merge>
<merge key="input.xkb.options"
type="string">grp:lwin_toggle,grp_led:scroll,compose:rwin</merge>
</match>
</device>
</deviceinfo>
Yep, the ",winkeys" is such a totally f-up syntax I must weep.
Check with lshal before restarting X.
3. And finaly in
.gconf/desktop/gnome/peripherals/keyboard/kbd.sysbackup/%gconf.xml
<?xml version="1.0"?>
<gconf>
<entry name="model" mtime="1203882815" type="string">
<stringvalue>evdev</stringvalue>
</entry>
<entry name="layouts" mtime="1203882815" type="list"
ltype="string">
<li type="string">
<stringvalue>fr oss</stringvalue>
</li>
<li type="string">
<stringvalue>ru winkeys</stringvalue>
</li>
</entry>
</gconf>
Slightly less broken tokenization but still one wonders what's the point
of using XML everywhere if actual options are not broken up in XML
objects but stored with random separators in raw strings inside the
pointy tags (still evo was much worse last I saw it - it stored complete
XML documents within XML stings, with <> as entities so XML parsers
didn't recognize them)
Anyway what's going to kill 99% of GNOME users is the first model part
as it's highly unlikely they used evdev before auto input (I did but I'm
a rawhide nut)
Regards,
--
Nicolas Mailhot
>
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
