Summary: | sys-apps/hal-0.5.10 breaks layout switching in X server via Xkb | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Andrey Melentyev <andrey.melentyev> |
Component: | [OLD] Core system | Assignee: | Freedesktop bugs <freedesktop-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | astar, betelgeuse, caster, ciklop1979, dhp_gentoo, dliana, dschridde+gentoobugs, it-knodel, jakub, jdaluz, loki_val, maekke, marek, Martin.vGagern, matrix47, mkyral, mmokrejs, pesa, Samuele.Kaplun, SDNick484, spatz, themactep, thermal, tobias.pal, togge.gentoo, vladimir, x11 |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 210710 | ||
Attachments: | use-multiple-layouts.fdi |
Description
Andrey Melentyev
2007-11-23 09:57:35 UTC
Coming from bug#200087 I can confirm this. hal-0.5.10 / evdev-1.2.0 ignores XkbLayout completely. (Xorg.log says it is using Option "xkb_layout" "us".) I believe this to be an instantiation of https://bugs.freedesktop.org/show_bug.cgi?id=13217: xserver 1.4 ignoring keyboards configured via xorg.conf Yep. You need a custom FDI file to be written for this configuration. Documentation on how to write the file has yet to be written. Please see http://blog.cardoe.com/archives/2007/11/23/hal-0510-and-things-todo-before-hitting-the-tree/ for details. (In reply to comment #3) > Yep. You need a custom FDI file to be written for this configuration. > Documentation on how to write the file has yet to be written. Please see > http://blog.cardoe.com/archives/2007/11/23/hal-0510-and-things-todo-before-hitting-the-tree/ > for details. > Hmm. Layout switching configuration with xorg.conf used to work for ages. Why can't HAL use existing preferences? (In reply to comment #3) > Yep. You need a custom FDI file to be written for this configuration. Pardon me, but that's supposedly a bad joke? You tell people to write some cryptic custom XML configs for their xorg.conf to be honored? May I ask WTH is this 'feature' about? How about entirely removing this major regression? Ugh. (In reply to comment #5) > (In reply to comment #3) > > Yep. You need a custom FDI file to be written for this configuration. > > Pardon me, but that's supposedly a bad joke? You tell people to write some > cryptic custom XML configs for their xorg.conf to be honored? May I ask WTH is > this 'feature' about? How about entirely removing this major regression? > > Ugh. > Your comments are neither constructive nor helpful. This is the path that the xorg-server maintainers have decided to take. They have decided to deprecate xorg.conf in favor of a HAL configuration. As they have not populated hal-info with all the data to autodetect settings for everyone, people are left with writing their own HAL FDI files currently. Hmm. I don't understand how my bug is related to xorg-server and its maintainers. I see only the fact that new HAL ignores my existing X.org configuration and rewrites it with its own default unusable settings. So here's some kind of FDI which works-for-me and allows me to switch between english and russian layouts with Alt+Shift: <?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- --> <match key="info.capabilities" contains="input.keyboard"> <merge key="input.x11_driver" type="string">keyboard</merge> <merge key="input.xkb.layout" type="string">us,ru</merge> <merge key="input.xkb.model" type="string">pc101</merge> <merge key="input.xkb.rules" type="string">xorg</merge> <merge key="input.xkb.variant" type="string">,winkeys</merge> <merge key="input.xkb.options" type="string">grp:alt_shift_toggle,grp_led:scroll</merge> </match> of course it is not universal solution, someone needs another driver or layout, but maybe someone will find it helpful. This text should be placed in some file in /etc/hal/fdi/policy/ If xorg-server is going to rely on keyboard configuration to be stored in HAL and require that people write the files themselves, xorg-server should be like every other package out there (example, libgphoto2) and provide documentation on how to write configuration files since xorg.conf is not the place to configure your keyboard. Or provide some sample files. (In reply to comment #7) > Hmm. I don't understand how my bug is related to xorg-server and its > maintainers. I see only the fact that new HAL ignores my existing X.org > configuration and rewrites it with its own default unusable settings. Incorrect. xorg-server now ignores it's own xorg.conf and expects HAL to provide it with keyboard configuration data. However, if xorg-server is going to do that, they should provide some documentation how to write these configuration files. The HAL specification merely documents a list of valid keys, but the data those keys contain is up to the xorg-server guys. Could you please add some elog comments about this the ebuilds so that users know the the breakage is known and can at least find the information provided here easily. As an alternative to fdi files I guess putting setxkbmap <layout> to ~/.xinitrc could work too. At least here setxkbmap fi works. It also makes Xorg server 1.4.0.90 ignore the specified keyboard layout (it adds my usb keyboard with evdev driver and applies us keyboard layout). (In reply to comment #12) > It also makes Xorg server 1.4.0.90 ignore the specified keyboard layout (it > adds my usb keyboard with evdev driver and applies us keyboard layout). Yes, as noted above, xorg-server chooses to *ignore* the configuration in xorg.conf if you enable hal. If you have no use for this kind of behind-the-scenes magic that clearly is not ready for prime time here, you can recompile xorg-server with USE="-hal" and move on. Also noting that unmasking this again when none of the issues at hand wrt xorg-server breakage have been addressed is a rather bad idea. :/ (In reply to comment #13) > Also noting that unmasking this again when none of the issues at hand wrt > xorg-server breakage have been addressed is a rather bad idea. :/ Even funnier when evdev keyboard works like for me - cursor up works as printscreen, page up/down etc does nothing... great! (In reply to comment #14) > > Even funnier when evdev keyboard works like for me - cursor up works as > printscreen, page up/down etc does nothing... great! > Do you have the model set for something else than evdev? This caused similar effects for me when I accidentally switched at some point. (In reply to comment #14) > (In reply to comment #13) > > Also noting that unmasking this again when none of the issues at hand wrt > > xorg-server breakage have been addressed is a rather bad idea. :/ > > Even funnier when evdev keyboard works like for me - cursor up works as > printscreen, page up/down etc does nothing... great! > Maybe you are experiencing bug #200060 ? Or maybe that bug and this one are just the same issue that pops up in different (funny) ways? Anyway, I also think that unmasking hal-0.5.10 without fixing these issues was a very bad idea... (In reply to comment #15) > Do you have the model set for something else than evdev? This caused similar > effects for me when I accidentally switched at some point. Hm according to log it sets evdev, but it could be my KDE setting changing it (since I noticed the cursors work on kdb but not after login). > Maybe you are experiencing bug #200060 ? Or maybe that bug and this one are > just the same issue that pops up in different (funny) ways? I'd say a bit different issue, but same cause. > Anyway, I also think that unmasking hal-0.5.10 without fixing these issues was > a very bad idea... Me too. Well at least I hope it won't get stable before this is sorted out... (In reply to comment #17) > Hm according to log it sets evdev, but it could be my KDE setting changing it > (since I noticed the cursors work on kdb but not after login). Right so it was KDE... changed layout to evdev there, and it works, layout switching via KDE also works, good. And no fdi file needed. Too bad this is per-user setting so the ebuild can't do anything except big fat warning which users will ignore anyway :) *** Bug 200157 has been marked as a duplicate of this bug. *** My keyboard config in xorg.conf is only Section "InputDevice" Identifier "Keyboard0" Driver "kbd" EndSection I keep it configured via KDE Control Panel, but with hal-0.5.10 that didn't work. Downgrading to hal-0.5.9-r3 works beautifully. Please mask HAL 0.5.10 until this is fixed! (In reply to comment #20) > > I keep it configured via KDE Control Panel > I forgot to add: my default layout is Brazilian ABNT 2 (br, abnt2 variant) (In reply to comment #20) > Please mask HAL 0.5.10 until this is fixed! Just stick Option "AutoAddDevices" "False" in ServerLayout section of xorg.conf and HAL will stop messing with your keyboard. Jakub do you have similar peaces of advices to fix mice and video card detection problems ? is your AutoAddDevices thing specific to keyboards ? I'm not sure, but if the only fix that we are waiting for is proper documentation for new HAL features, then maybe we should somehow merge this bug with bug #200060 ? (In reply to comment #23) > Jakub do you have similar peaces of advices to fix mice and video card > detection problems ? is your AutoAddDevices thing specific to keyboards ? See http://dev.gentoo.org/~compnerd/temp/hal-config-examples/; as for video card, I have no idea whether it could be even remotely related to HAL... (In reply to comment #22) > (...) Thank you! *** Bug 206625 has been marked as a duplicate of this bug. *** To fix this behavior, just set your KDE-keyboard-layout in KControl to "evdev managed Keyboard" HTH for you too. (In reply to comment #28) > To fix this behavior, just set your KDE-keyboard-layout in KControl to "evdev > managed Keyboard" re-read comments 2 and 4. I had this problem too (by the time I tried to use X-1.4 ... I now reverted to 1.3 because 1.4 has too many bugs), and I wonder how you can propose us a KDE fix: - I dont use KDE at all - the X bug should not have a WM fix: what about non-KDE wm ? what about people who do not want wm at all ? from times to times, I need to just run X and Eterm, nothing more ! X regression bug should not have WM fix. And this is at least the 4th regression bug I found in X-1.4 Myself have given up both hal-0.5.10 and xorg-server-1.4 series. As I have read on some debian and archlinux lists and forums, one has to use the evdev instead of kbd driver in xorg.conf and also use evdev in those .fdi files, otherwise things do not work perfectly as before (somebody posted somewhere a nice list of what exactly works and does not work in each combination). Unfortunately, I was still having problems so I gave up. For details see bug #204128. Please, take a look at my comment to bug 200060, this may be the answer to comment #29. *** Bug 205077 has been marked as a duplicate of this bug. *** *** Bug 204857 has been marked as a duplicate of this bug. *** (In reply to comment #23) > Jakub do you have similar peaces of advices to fix mice and video card > detection problems ? is your AutoAddDevices thing specific to keyboards ? > The entry resolved my mouse issue, no clue on vid cards. You do need a working xorg.conf as it disables ALL auto detected stuff. Basically if your xorg.conf worked for Xorg 1.3 or prior you'll be fine, but there's a chance if you've only used Xorg 1.4, then you'll break something (easy to fix though, the system will still boot to a cli). *** Bug 212597 has been marked as a duplicate of this bug. *** Created attachment 183879 [details] use-multiple-layouts.fdi Working definition under xorg-server-1.5.3. I can switch using alt+shift from us to czech keyboard layout. More info at http://lists.freedesktop.org/mailman/listinfo/xorg under thread name "[Bug 19947] xkbcomp-1.0.5: Group width mismatch between key and type" around Feb23 2009. From: Peter Hutterer this is what actually is loaded in the server. You see how all your options are missing? This is because of a wrong setup (fdi file below). when I run setxkbmap with the settings you're presumably trying to get: $> setxkbmap -layout "us,cz" -variant ",qwerty" -option "grp:alt_shift_toggle"\ -option "grp_led:scroll" -option "caps:shift_nocancel" -print xkb_keymap { xkb_keycodes { include "evdev+aliases(qwerty)" }; xkb_types { include "complete+caps(shift_nocancel)" }; xkb_compat { include "complete+ledscroll(group_lock)" }; xkb_symbols { include "pc+us+cz(qwerty):2+inet(evdev)+group(alt_shift_toggle)" }; xkb_geometry { include "pc(pc104)" }; }; this command should work for you. (remove the -print option to set it and check the server log) what's the status on this bug ? Layout switching works correctly with xorg-server 1.5.3 with evdev (probably even keyboard as well). If this is not the case, please don't hesitate to reopen this bug with updated information. Thanks |