<html>
    <head>
      <base href="https://bugs.freedesktop.org/" />
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - * glob works wrongly in 60-keyboard.hwdb"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=88410#c10">Comment # 10</a>
              on <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - * glob works wrongly in 60-keyboard.hwdb"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=88410">bug 88410</a>
              from <span class="vcard"><a class="email" href="mailto:kay@vrfy.org" title="Kay Sievers <kay@vrfy.org>"> <span class="fn">Kay Sievers</span></a>
</span></b>
        <pre>(In reply to Kay Sievers from <a href="show_bug.cgi?id=88410#c8">comment #8</a>)
<span class="quote">> (In reply to Zbigniew Jedrzejewski-Szmek from <a href="show_bug.cgi?id=88410#c7">comment #7</a>)
> > > All file names are sorted, the file contents are applied record -by-record from top to bottom.
> > Kay, I think you're thiking about rules files. This is about the hwdb.

> No, all fine, this was about hwdb.

> > I added some debugging statements to figure this out.
> > 
> > fnmatch trie: "*:bvr*:bd*:svnMICRO-STAR*:pn*U100*:pvr*" → yes
> > hwdb_add_property: KEYBOARD_KEY_f7 → reserved
> > hwdb_add_property: KEYBOARD_KEY_f8 → reserved

> These are the keys which are specified later in the source hwdb files, but
> they are applied first here. These later ones are supposed to overwrite the
> earlier ones. The "reserved" should win here.

> This is a bug in the hwdb code. Maybe it things changed recently regarding
> this logic?</span >

Oh, we have multiple records with _different_ match strings which get merged.
I forgot about this detail there.

With different match strings, it should not be about the order in the
file, but about the length of the match string. The data is put in a
patricia trie and the order of individual records should _not_ matter for
_different_ match strings.

The intended behavior is that records with longer match strings overwrite
shorter match strings. That means, things which are stored "deeper" in the
tree are more specific/"better" matches than the broader ones stored closer
to the root. And the more specific ones should overwrite the broader ones.

Seem like this logic should be fixed.</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are the QA Contact for the bug.</li>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>