Bug 16975 - setxkbmap is unable to explain the rules it applied
setxkbmap is unable to explain the rules it applied
Status: NEW
Product: xorg
Classification: Unclassified
Component: Server/Input/XKB
6.8.2
Other All
: medium normal
Assigned To: Daniel Stone
Xorg Project Team
:
Depends on:
Blocks: 16872
  Show dependency treegraph
 
Reported: 2008-08-03 15:03 UTC by Sergey V. Udaltsov
Modified: 2012-05-31 10:21 UTC (History)
2 users (show)

See Also:


Attachments
Add debug printing to libxkbfile (6.59 KB, patch)
2009-01-21 16:48 UTC, Sergey V. Udaltsov
no flags Details | Splinter Review
Sample output in debug mode (79.63 KB, text/plain)
2009-01-21 16:50 UTC, Sergey V. Udaltsov
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sergey V. Udaltsov 2008-08-03 15:03:37 UTC
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.
Comment 1 Sergey V. Udaltsov 2009-01-21 16:48:51 UTC
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.
Comment 2 Sergey V. Udaltsov 2009-01-21 16:50:10 UTC
Created attachment 22142 [details]
Sample output in debug mode

This is what I get with that patch
Comment 3 Sergey V. Udaltsov 2009-06-12 06:45:41 UTC
Anyone willing to look at the patch and finally apply it?
Comment 4 Tristan Miller 2012-05-31 09:59:08 UTC
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.
Comment 5 Daniel Stone 2012-05-31 10:01:58 UTC
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.
Comment 6 Alan Coopersmith 2012-05-31 10:21:58 UTC
(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.