Bug 66344

xkbcomp warns whenever a keycode has been given a name but does not have
symbols explicitly defined.  This happens a lot, because keycodes files
tend to name every keycode defined for their protocol, including many
obscure keys that most keyboards don't have.  For example, the evdev
set results in a lot of

Warning:          No symbols defined for <HIRA> (keycode 99)
Warning:          No symbols defined for <HENK> (keycode 100)
Warning:          No symbols defined for <HKTG> (keycode 101)
...
Warning:          No symbols defined for <HELP> (keycode 146)
Warning:          No symbols defined for <I147> (keycode 147)
Warning:          No symbols defined for <I148> (keycode 148)
Warning:          No symbols defined for <I149> (keycode 149)

It's OK to warn about this, but since it's a very normal situation
and doesn't usually represent an actual problem it should be a very
low-priority warning, that can be turned off without losing any of the
more useful warnings.

In fact it's implemented as quite a high-priority warning.  It takes
"-w 3" to turn it off; "-w 4" or higher generates this warning.
By comparison, the warning for the reverse situation, where an attempt
is made to assign symbols to a key name that hasn't been defined, which
*does* generally indicate a real problem, is turned off at "-w 4" or
below, appearing only with "-w 5" or higher.  So at "-w 4" you get the
useless warnings but not the useful ones.

Having this warning on means that any successful run of xkbcomp generates
screenfuls of useless warnings, thus hiding real warnings.  Having this
warning off means that real warnings will be suppressed.  Neither is
a good way to operate.  The "No symbols defined for" warning needs to
be lower priority than other warnings, or independently selectable,
or just abolished entirely.

-zefram

http://patchwork.freedesktop.org/patch/14035/

commit 0ebdf47fd4bc434ac3d2339544c022a869510738
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Thu Jul 11 13:53:31 2013 +1000

    Parse -w1 flag correctly (#66344)

This patch doesn't fix every problem, such as:
* The code looks at the next argument before detecting whether -w already has a number attached to it, which yields an error when one uses -w<number> and the input file starts with a digit.
* Options like -wfoo are regarded in the same way as -w.

Here's another patch:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=14;filename=xkbcomp-w.patch;att=1;bug=673027

It doesn't doesn't check everything (garbage after the number is ignored). Anyway, that's much better than the current code.

Please send the patch as git-formatted signed-off patch to the xorg-devel list, or alternatively attach it here, I'll have a look at it then. thanks.

(In reply to comment #5)
> Please send the patch as git-formatted signed-off patch to the xorg-devel
> list, or alternatively attach it here, I'll have a look at it then. thanks.

I've improved the patch and sent it there:
  http://lists.x.org/archives/xorg-devel/2014-August/043440.html

The patch was denied on the mailing list for its style but the bug is still not fixed.

Vincent, any chance you can fix up the patch? thanks.

(In reply to Peter Hutterer from comment #8)
> Vincent, any chance you can fix up the patch? thanks.

I'll look at it tomorrow.

(In reply to Peter Hutterer from comment #8)
> Vincent, any chance you can fix up the patch? thanks.

New patch: http://lists.x.org/archives/xorg-devel/2014-October/044404.html

thanks, pushed as

commit 978998a1fe0a78829452f5432efe1b74c5049de4
Author: Vincent Lefevre <vincent@vinc17.net>
Date:   Mon Oct 27 10:50:30 2014 +0100

    xkbcomp: Improved -w option parsing