Add support for firmware versions

[jexposit]

Patches from Peter (#620) plus changes from my side.

Requires https://lore.kernel.org/linux-input/[email protected]/T/ or https://github.com/JoseExposito/digimend-kernel-drivers/tree/sysfs-fw-name.

Fixes #610

cc @whot

[whot]

One typo found, would be great if you could squash that in. Otherwise this LGTM, we can merge this once upstream accepts your kernel patch. Can you ping me when that happens? Thanks

[whot]

Note to self: this may become an issue if we ever get a fw exported that has a different underscorify pattern.

[jexposit]

I don't have a strong preference for this regex (I usually have a strong preference against using regexes), but in this case I think that makes easier to parse the fw name.

If you prefer to match against a list of well known fw names, I'm happy to change this function.

[whot]

ftr I have merged the first few cleanup patches, so a rebase should half the commit list

[jexposit]

@whot the kernel patch has been merged.

In the end, instead of creating a custom sysfs property, we ended up using hid->uniq. Since this a generic attribute all devices has, I wonder if it makes sense to refactor a little bit the series to use uniq instead of fw as variable names and update the documentation.

Something else I have in my to-do list is displaying that information with libwacom-list-local-devices so user can actually discover it.

[whot]

I wonder if it makes sense to refactor a little bit the series to use uniq instead of fw as variable names and update the documentation.

yes, definitely. This also leaves room for a future firmware attribute if uniq is no longer sufficient.

Something else I have in my to-do list is displaying that information with libwacom-list-local-devices so user can actually discover it.

I think --format=datafile should work automatically, the yaml format will need an extra entry though.

[jexposit]

I wonder if it makes sense to refactor a little bit the series to use uniq instead of fw as variable names and update the documentation.

yes, definitely. This also leaves room for a future firmware attribute if uniq is no longer sufficient.

Refactored the last patch to use uniq instead of fw

Something else I have in my to-do list is displaying that information with libwacom-list-local-devices so user can actually discover it.

I think --format=datafile should work automatically, the yaml format will need an extra entry though.

Also added an extra entry to tools/list-devices.c

[whot]

one indentation error, rest looks good, thanks!

[jexposit]

Resolved and rebased. Thanks for the review!

[whot]

../libwacom/libwacom.c:234:33: error: ‘G_REGEX_DEFAULT’ undeclared (first use in this function); did you mean ‘G_REGEX_DOTALL’?

Introduced in 2.74 and that's too new for Ubuntu 22.04. Looking at glib commit 2.73.1-26-g879b9cd669f0 we should be fine with an

#ifndef G_REGEX_DEFAULT
#define G_REGEX_DEFAULT 0
#endif

[jexposit]

Ops, missed the CI emails. I replaced compile_options and match_options with 0 as in the docs:
https://docs.gtk.org/glib/ctor.Regex.new.html

[jexposit]

Is the FreeBSD failure expected?

[whot]

Is the FreeBSD failure expected?

yeah, it's very unreliable and fails often (all the time?) but I'm ETIME on debugging that. cc @jbeich

[whot]

I think we're good here, let's merge this! thanks for all the effort

[jbeich]

it's very unreliable

Try applying labwc/labwc@00ec29c834b7. I suspect v0 isn't maintained anymore or emulating on macOS is still unstable.

[whot]

@jbeich thanks, that was it, fixed in #662