Sometimes setxkbmap makes non-trivial decisions regarding the way it applies the rules. Even using dozen of -v options does not help. What would be useful to have is some way to see the list of the rules applied to the input components (with references to line numbers in the rules file perhaps). I think it should be easy enough - but might help a great deal with debugging issues with xkeyboard-config.
Created attachment 22141 [details] [review] Add debug printing to libxkbfile There is a set of PR_DEBUG macros in maprules.c. They only work if DEBUG is enable at build time. This hack is using them to output rules processing info.
Created attachment 22142 [details] Sample output in debug mode This is what I get with that patch
Anyone willing to look at the patch and finally apply it?
This issue isn't specific to troubleshooting complicated decisions on how setxkbmap applies rules. Setxkbmap is utterly unable to report the nature or location of dead-simple problems such as syntax errors in a symbols file; no matter how high the verbosity level is set, the best it can do is say "Error loading new keyboard description". I once had, unbeknownst to me, a stray semicolon in a symbols file, and could not for the life of me figure out why setxkbmap was refusing to load the keyboard description. I had to do a binary search on almost the entire file (that is, removing half of it, then trying setxkbmap to see if it still failed, and so on) in order to isolate the problem. This tedious debugging could be easily avoided if setxkbmap were to simply print out the relevant line number of the problematic file.
On 31 May 2012 17:59, <bugzilla-daemon@freedesktop.org> wrote: > This issue isn't specific to troubleshooting complicated decisions on how > setxkbmap applies rules. Setxkbmap is utterly unable to report the nature or > location of dead-simple problems such as syntax errors in a symbols file; no > matter how high the verbosity level is set, the best it can do is say "Error > loading new keyboard description". I once had, unbeknownst to me, a stray > semicolon in a symbols file, and could not for the life of me figure out why > setxkbmap was refusing to load the keyboard description. I had to do a binary > search on almost the entire file (that is, removing half of it, then trying > setxkbmap to see if it still failed, and so on) in order to isolate the > problem. This tedious debugging could be easily avoided if setxkbmap were to > simply print out the relevant line number of the problematic file. Unfortunately it's not quite that simple, as setxkbmap often just asks the X server to compile the map, and then gets success/failure back, with the failure not containing an error code. We can't fix that without new protocol.
(In reply to comment #5) > Unfortunately it's not quite that simple, as setxkbmap often just asks > the X server to compile the map, and then gets success/failure back, > with the failure not containing an error code. We can't fix that > without new protocol. We can recommend to users that when they get a failure they look in the appropriate log file, if they have access, such as /var/log/gdm/:0.log - unfortunately we don't seem to be capturing the xkbcomp stderr into /var/log/Xorg.0.log, just letting the display manager capture it with the rest of the Xorg stderr messages.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/294.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.