When xorg-server is built with USE=hal and user switches to non-US keyboard layout, keybard is totally hosed -- for example, the up arrow is re-mapped to PrintScreen. Steps to reproduce: 1) Stick the following to xorg.conf: Section "InputDevice" Identifier "Internal-Keyboard" Driver "kbd" Option "XkbRules" "xorg" Option "XkbModel" "pc105" Option "XkbLayout" "us,cz_qwerty" Option "XkbOptions" "grp:alt_shift_toggle,grp_led:scroll,caps:internal" EndSection 2) Build xorg-server in the following configuration: x11-base/xorg-server-1.5.0 USE="dri ipv6 nptl sdl xorg -3dfx -debug -dmx -hal -kdrive -minimal" INPUT_DEVICES="keyboard mouse synaptics" (all other INPUT_DEVICES, including evdev, are disabled) 3) Execute `setxkbmap -model pc105 -layout cz -variant qwerty` 4) Observe the breakage
XkbModel must be "evdev" for the evdev driver.
Note that xorg-server 1.5 will use evdev anyway, even if not specified in xorg.conf (check Xorg.0.log)
(In reply to comment #2) > Note that xorg-server 1.5 will use evdev anyway, even if not specified in > xorg.conf (check Xorg.0.log) I have never used the evdev driver, nor do I use it now (see comment #0, point 2), nor do I feel any need to do so. If building with USE=hal somehow magically requires it, then it should be indicated in the documentation. velbloud ~ # grep -c evdev /var/log/Xorg.0.log 0 Having to edit tons of poorly documented HAL XML files just to get a simple keyboard running is not the way to go :)
If you use HAL, then you should remove the input sections from your xorg.conf. Read this http://cgit.freedesktop.org/xorg/xserver/tree/config/x11-input.fdi for more information and steps on how to convert old xorg.conf lines into HAL configuration xml. If you just want to carry on without changing your xorg.conf, just stick this bit inside your ServerLayout section: Option "AutoAddDevices" "off" Thanks
Hi, I had a similar problem with my Ibook and the keyboard layout. I just noticed that the script in the HAL ebuild that creates a fdi file from your xorg.conf has a problem with XkbOptions. It defines this as "strlist" in the fdi file. Changing it to "string" helped here.
xorg-server-1.5.2 contains config/x11-input.fdi. it should be installed.
Created attachment 171064 [details, diff] xorg-server-1.5.2.ebuild-x11-input.patch
(In reply to comment #6) > xorg-server-1.5.2 contains config/x11-input.fdi. it should be installed. > I doubt that this is the best solution for all users... The current use of a script to generate a fdi file based on the xorg.conf is far better, even if it still could use some cleanup.
Comment on attachment 171064 [details, diff] xorg-server-1.5.2.ebuild-x11-input.patch I found that 10-x11-input.fdi is generated by migrate-xorg-to-fdi.py in >=sys-apps/hal-0.5.11-r2. So xorg-server doesn't have to install it.
I recommend making -hal default in xorg-server. This USE flag brings too many problems for what it offers. If someone feels like learning how to configure xorg from within hal, they can always enable it. Most people get confused and messed up and end up adding -hal themselves.
...or at least add a ewarn telling users that their xorg.conf wont work if they have +hal in xorg-server :)
This is driven by upstream development, and we are one of the only distributions to even offer the ability to run without D-Bus / HAL in X.Org Please enjoy the privileges you have. We are moving the conversion script around to avoid a circular dependency and continuing on the chosen path.
(In reply to comment #0) > When xorg-server is built with USE=hal and user switches to non-US keyboard > layout, keybard is totally hosed -- for example, the up arrow is re-mapped to > PrintScreen. > I got the same problem, i "fixed" it by disabling keyboard layouts in kde. I thus suggest disabling any other "keyboard layout"-mechanism. hth
