Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
WIP: Move the database of supported devices out into runtime loaded f… #293
When fwupd is installed in long-term support distros it's very hard to backport
There are several reasons why we can't just include the mapping and quirk
The idea with FuHwdb is that the end user can drop an additional (or replace
This allows us to fix issues like #265
This looks good.
For the Jabra DFU quirk handling code to be completely freed of PID switch statements, we would need to be able to also encode the 'rep' and 'adr' bytes of the FWU mode switch command in the quirks file. Then new DFU devices that do not require new quirks can be added without code changes.
I like the approach. Something else I think that could be interesting is to let the quirks come down with LVFS metadata distributed with updates.
If you allow quirks to be put directly into CAB files, you can in effect not have to even do "OS" updates of quirks for supporting new devices in some cases.
Okay, lots of fixes. @superm1 if you can test the new Dell stuff that would be handy. I'm also not sure about the prefix names, e.g. do we want:
I'm also not sure how to document the quirks; in the code they'd be scattered around and in the .quirk files there might be multiple files adding keys with the same prefix. In a random
I think it would be a good practice to put all the quirks used in
To avoid having to do code inline how about every quirk in the header file gets a comment like this:
Standard behavior: Version format is recognized as AA.BB.CCDD
I think adding pointers (or copying )the code is unnecessary effort. Once you've got a string, it's easy enough to just search from github or
Other idea is just that ini style file like you've got implemented but same strings above. Everything that is quirkable should have an empty section then by default in the ini file.
Regarding prefix name, nothing else is going to use this other than fwupd right? I think dbus style naming is confusing outside a dbus context. I'm personally a fan of the first option you listed (
That looks really good, and gtk-doc output is definitely a much better consumer than a header file.
The DFU ones are still missing, is that intentional? I was actually thinking that those are the more interesting ones because there are so many and they can be used together.