Bug 66344 - xkbcomp bad parsing of -w option
Summary: xkbcomp bad parsing of -w option
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: App/xkbcomp (show other bugs)
Version: git
Hardware: All All
: medium minor
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-06-29 00:29 UTC by Stéphane Aulery
Modified: 2014-10-30 02:41 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Stéphane Aulery 2013-06-29 00:29:22 UTC
xkbcomp's warning-level option only works if the numeric argument comes
in a separate command-line argument from the "-w".  E.g., "xkbcomp -w 3
t0.xkb" and "xkbcomp -w 4 t0.xkb" work, and produce different degrees
of verbosity.  But "xkbcomp -w3 t0.xkb" and "xkbcomp -w4 t0.xkb" both
produce no warnings, as far as I can see.

There is no explicit indication that the option was badly formed.
The numeric argument is not being treated as an option, nor is the
filename argument being consumed as the argument to "-w".  It just
silently goes wrong.

-zefram
Comment 1 Stéphane Aulery 2013-06-29 00:32:11 UTC
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
Comment 2 Peter Hutterer 2013-07-12 00:11:49 UTC
http://patchwork.freedesktop.org/patch/14035/
Comment 3 Peter Hutterer 2013-07-18 05:39:40 UTC
commit 0ebdf47fd4bc434ac3d2339544c022a869510738
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Thu Jul 11 13:53:31 2013 +1000

    Parse -w1 flag correctly (#66344)
Comment 4 Vincent Lefevre 2014-07-29 14:23:52 UTC
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.
Comment 5 Peter Hutterer 2014-08-04 05:38:25 UTC
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.
Comment 6 Vincent Lefevre 2014-08-05 06:44:45 UTC
(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
Comment 7 Stéphane Aulery 2014-10-18 12:05:47 UTC
The patch was denied on the mailing list for its style but the bug is still not fixed.
Comment 8 Peter Hutterer 2014-10-27 01:49:49 UTC
Vincent, any chance you can fix up the patch? thanks.
Comment 9 Vincent Lefevre 2014-10-27 02:58:53 UTC
(In reply to Peter Hutterer from comment #8)
> Vincent, any chance you can fix up the patch? thanks.

I'll look at it tomorrow.
Comment 10 Vincent Lefevre 2014-10-27 11:05:56 UTC
(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
Comment 11 Peter Hutterer 2014-10-30 02:41:44 UTC
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


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.