Comment 22 for bug 1890186

Ok here's my understanding of this:

Most keyboards report a single usb device 'interface' for the keyboard (some have separate interface(s) for builtin mice or other non-keyboard stuff). However, your keyboard reports two separate 'interfaces' for your single keyboard. Unfortunately, both of the interfaces it reports use the exact same vendor and product id, so there's no way for systemd to tell which is which, from the bus/vendor/product info.

The setting in the hwdb matches specifically on this bus/vendor/product id info (the b0003v045Ep00DB string):
evdev:input:b0003v045Ep00DB*

This applies the scancode remapping to *both* of the interfaces that your keyboard reports. However, only one of the interfaces actually supports the remapped scancodes, so when systemd attempts to tell the kernel to map the specific scancode to the assigned keycode, the kernel rejects it, which results in the warning messages you saw in the logs.

However these warning log messages are only produced for the second interface which doesn't actually support or provide the scancodes in question. So, this logged warning is completely harmless and you can ignore it.

It's possible that we might be able to figure out how to finesse systemd hwdb config to get around the fact that your hardware keyboard is essentially broken (because it reports two separate interfaces with identical vendor/product ids but with different operation and behavior). However since these logged errors are completely harmless, and any 'fix' could possibly (accidentally) cause the mapped keys to *not* function, I don't think it's worth it to bother fixing this.

Therefore I'm going to close this as wontfix, since I believe this is a hardware problem that does not have any actual impact on the system's operation, besides logging a harmless warning message.