libfprint-2-tod1-broadcom USB driver
Hi Geekos! Recently, i have been trying to implement Broadcom fingerprint reader driver mentioned in subject. For this i have tried following approach: https:// github.com/dsd/fprintd/issues/3#issuecomment-962422370 It contains binary firmware, udev rules, fprint library and firmware install script written in python. Result of my tries can be found here: https://paste.opensuse.org/view/raw/ 72229198 (except of the 70-libfprint-2.rules, which is the openSUSE one and listed just for comparison. FYI i am trying with 0a5c:5843 device. My tries were however unsuccessful (fprint does not recognize the device and so KDE does). My question is, is there anything different between (open)SUSE and Debian or Arch regarding UDEV and/or firmware installation? I can provide any debug information required, but i am stucked here it seems. I would be glad for any hints! It would be nice to get this reader working, since it is present in many Dell laptops and it is reported to be working in Debian derivates and Arch. Best regards! Gryffus
On 11.05.2022 17:31, Lukáš Krejza wrote:
Hi Geekos!
Recently, i have been trying to implement Broadcom fingerprint reader driver mentioned in subject. For this i have tried following approach: https:// github.com/dsd/fprintd/issues/3#issuecomment-962422370
It contains binary firmware, udev rules, fprint library and firmware install script written in python.
Result of my tries can be found here: https://paste.opensuse.org/view/raw/ 72229198 (except of the 70-libfprint-2.rules, which is the openSUSE one and listed just for comparison. FYI i am trying with 0a5c:5843 device.
My tries were however unsuccessful (fprint does not recognize the device and so KDE does).
My question is, is there anything different between (open)SUSE and Debian or Arch regarding UDEV and/or firmware installation?
Dynamic driver loading requires fork of libfprint - libfprint-tod. As far as I can tell it is not available for openSUSE while Ubuntu is using this version. Even if this version were available, it most certainly would not use /usr/lib/x86_64-linux-gnu path. I cannot comment on possibility to replace libfprint with libfprint-tod in openSUSE, but as long as it works for other distributions may be it is an option ... someone needs to package it first :)
I can provide any debug information required, but i am stucked here it seems. I would be glad for any hints! It would be nice to get this reader working, since it is present in many Dell laptops and it is reported to be working in Debian derivates and Arch.
Best regards! Gryffus
Dne středa 11. května 2022 18:38:13 CEST, Andrei Borzenkov napsal(a):
On 11.05.2022 17:31, Lukáš Krejza wrote:
Hi Geekos!
Recently, i have been trying to implement Broadcom fingerprint reader driver mentioned in subject. For this i have tried following approach: https:// github.com/dsd/fprintd/issues/3#issuecomment-962422370
It contains binary firmware, udev rules, fprint library and firmware install script written in python.
Result of my tries can be found here: https://paste.opensuse.org/view/raw/ 72229198 (except of the 70-libfprint-2.rules, which is the openSUSE one and listed just for comparison. FYI i am trying with 0a5c:5843 device. My tries were however unsuccessful (fprint does not recognize the device and so KDE does).
My question is, is there anything different between (open)SUSE and Debian or Arch regarding UDEV and/or firmware installation?
Dynamic driver loading requires fork of libfprint - libfprint-tod. As far as I can tell it is not available for openSUSE while Ubuntu is using this version.
I am using this one: https://build.opensuse.org/package/show/home:sp1rit/ libfprint-tod which has been fixed few hours ago for Tumbleweed by Sp1rit (only tests failed, which was fixed in latest git as i informed Sp1rit already)
Even if this version were available, it most certainly would not use /usr/lib/x86_64-linux-gnu path.
Cool! This has lead me to fiddling with fprint more and i got this message in logs: (fprintd:13711): libfprint-tod-DEBUG: 18:53:39.091: Impossible to load the shared drivers dir Error opening directory ?/usr/lib64/libfprint-2/tod-1?: No such file or directory I will fix the paths and keep you informed.
I cannot comment on possibility to replace libfprint with libfprint-tod in openSUSE, but as long as it works for other distributions may be it is an option ... someone needs to package it first :)
I can provide any debug information required, but i am stucked here it seems. I would be glad for any hints! It would be nice to get this reader working, since it is present in many Dell laptops and it is reported to be working in Debian derivates and Arch.
Best regards! Gryffus
I think biggest problem problem with including will be closed source library for the libfprint-2-tod1-broadcom driver. But the firmware itself is a binary blob too, so what do i know? Maybe it can be workaround with a pullin or packaged on packman? But testing first... Thanks! Gryffus
Dne středa 11. května 2022 18:55:57 CEST, Lukáš Krejza napsal(a):
Dne středa 11. května 2022 18:38:13 CEST, Andrei Borzenkov napsal(a):
On 11.05.2022 17:31, Lukáš Krejza wrote:
Hi Geekos!
Recently, i have been trying to implement Broadcom fingerprint reader driver mentioned in subject. For this i have tried following approach: https:// github.com/dsd/fprintd/issues/3#issuecomment-962422370
It contains binary firmware, udev rules, fprint library and firmware install script written in python.
Result of my tries can be found here: https://paste.opensuse.org/view/raw/ 72229198 (except of the 70-libfprint-2.rules, which is the openSUSE one and listed just for comparison. FYI i am trying with 0a5c:5843 device. My tries were however unsuccessful (fprint does not recognize the device and so KDE does).
My question is, is there anything different between (open)SUSE and Debian or Arch regarding UDEV and/or firmware installation?
Dynamic driver loading requires fork of libfprint - libfprint-tod. As far as I can tell it is not available for openSUSE while Ubuntu is using this version.
I am using this one: https://build.opensuse.org/package/show/home:sp1rit/ libfprint-tod which has been fixed few hours ago for Tumbleweed by Sp1rit (only tests failed, which was fixed in latest git as i informed Sp1rit already)
Even if this version were available, it most certainly would not use /usr/lib/x86_64-linux-gnu path.
Cool! This has lead me to fiddling with fprint more and i got this message in logs: (fprintd:13711): libfprint-tod-DEBUG: 18:53:39.091: Impossible to load the shared drivers dir Error opening directory ?/usr/lib64/libfprint-2/tod-1?: No such file or directory
I will fix the paths and keep you informed.
I cannot comment on possibility to replace libfprint with libfprint-tod in openSUSE, but as long as it works for other distributions may be it is an option ... someone needs to package it first :)
I can provide any debug information required, but i am stucked here it seems. I would be glad for any hints! It would be nice to get this reader working, since it is present in many Dell laptops and it is reported to be working in Debian derivates and Arch.
Best regards! Gryffus
I think biggest problem problem with including will be closed source library for the libfprint-2-tod1-broadcom driver. But the firmware itself is a binary blob too, so what do i know? Maybe it can be workaround with a pullin or packaged on packman? But testing first...
Thanks! Gryffus
And we have a success here! Well, kind of. The reader is now detected properly and is able to enroll a fingerprint, but it freezes on verifying it. But it is detected correctly by fprintd and in KDE too. https://paste.opensuse.org/view/raw/96485161 Now some packaging work and more testing. Regards, Gryffus
On 11.05.2022 19:55, Lukáš Krejza wrote: ...
I cannot comment on possibility to replace libfprint with libfprint-tod in openSUSE, but as long as it works for other distributions may be it is an option ... someone needs to package it first :)
...
I think biggest problem problem with including will be closed source library for the libfprint-2-tod1-broadcom driver.
It is not part of libfprint-tod. The whole point of dynamic loading is to enable packaging drivers separately. Providing your closed source driver for openSUSE is different matter entirely.
Dne středa 11. května 2022 19:52:35 CEST, Andrei Borzenkov napsal(a):
On 11.05.2022 19:55, Lukáš Krejza wrote: ...
I cannot comment on possibility to replace libfprint with libfprint-tod in openSUSE, but as long as it works for other distributions may be it is an option ... someone needs to package it first :)
...
I think biggest problem problem with including will be closed source library for the libfprint-2-tod1-broadcom driver.
It is not part of libfprint-tod. The whole point of dynamic loading is to enable packaging drivers separately.
Providing your closed source driver for openSUSE is different matter entirely.
Yeah, exactly. I am adding Sp1rit to the loop. @Sp1rit, do you plan to submit libfprint-tod to Factory? I noticed that there are some build failures for older Leap versions, but i don't know if these are required to be resolved before Factory submission. For the driver, i have created libfprint-tod-broadcom in my home repo and will continue my work there, so i would be glad if anyone competent could comment if i should move it to Packman of create the package as a pullin, like for example Broadcom wireless firmware packages. Which one is preferred? Thanks. Gryffus
Dne středa 11. května 2022 20:18:35 CEST, Lukáš Krejza napsal(a):
Dne středa 11. května 2022 19:52:35 CEST, Andrei Borzenkov napsal(a):
On 11.05.2022 19:55, Lukáš Krejza wrote: ...
I cannot comment on possibility to replace libfprint with libfprint-tod in openSUSE, but as long as it works for other distributions may be it is an option ... someone needs to package it first :)
...
I think biggest problem problem with including will be closed source library for the libfprint-2-tod1-broadcom driver.
It is not part of libfprint-tod. The whole point of dynamic loading is to enable packaging drivers separately.
Providing your closed source driver for openSUSE is different matter entirely.
Yeah, exactly. I am adding Sp1rit to the loop.
@Sp1rit, do you plan to submit libfprint-tod to Factory? I noticed that there are some build failures for older Leap versions, but i don't know if these are required to be resolved before Factory submission.
For the driver, i have created libfprint-tod-broadcom in my home repo and will continue my work there, so i would be glad if anyone competent could comment if i should move it to Packman of create the package as a pullin, like for example Broadcom wireless firmware packages. Which one is preferred?
Thanks.
Gryffus
As a side note, Arch keeps both forks packaged and i think it is the correct path. From https://wiki.archlinux.org/title/fprint : "Some devices require a different fork of libfprint specifically made for touch-based sensors and not (yet?) merged with the main libfprint: libfprint- tod. This is available as libfprint-tod-git" We might ask fprint upstream if they plan to merge it or what is their opinion on the matter. Regards, Gryffus
Am Mittwoch, dem 11.05.2022 um 20:18 +0200 schrieb Lukáš Krejza:
Dne středa 11. května 2022 19:52:35 CEST, Andrei Borzenkov napsal(a):
On 11.05.2022 19:55, Lukáš Krejza wrote: ...
I cannot comment on possibility to replace libfprint with libfprint-tod in openSUSE, but as long as it works for other distributions may be it is an option ... someone needs to package it first :)
...
I think biggest problem problem with including will be closed source library for the libfprint-2-tod1-broadcom driver.
It is not part of libfprint-tod. The whole point of dynamic loading is to enable packaging drivers separately.
Providing your closed source driver for openSUSE is different matter entirely.
Yeah, exactly. I am adding Sp1rit to the loop.
Sorry, wrote my first email before seeing this one in my inbox :/
@Sp1rit, do you plan to submit libfprint-tod to Factory? I noticed that there are some build failures for older Leap versions, but i don't know if these are required to be resolved before Factory submission.
Typically not for Factory, but AFAIK sometimes for individual devel projects. I never really intended to submit this to factory, given that it's basically just a "fork" of libfprint. The specfile is also just a marginally modified specfile from hardware/libfprint (no idea if how much they have drifted between each other over two years). Because this just still just a "fork" it also ships a libfprint-2.so.2 in addition to the libfprint-2-tod.so.1. I also don't know what Factories policy in regards to these kinds of forks are, but I guess it's up to libfprints maintainer? Additionally, 3v1n0s "tod" branch had originally no proper versioning, so I assumed that it was going to be merged at some point into upstream libfprint. Given, that by now 3v1n0 actually tags releases and even has a seperate "tod-devel" branch, it seems like libfprint-tod is here to stay, so it might also have a place in Factory? I asume the best part forward would be merging the two spec files from libfprint and libfprint-tod to create some kind of multi source, single spec package. But I have no experience with that (but I think that what the Kernel packages do?)
For the driver, i have created libfprint-tod-broadcom in my home repo and will continue my work there, so i would be glad if anyone competent could comment if i should move it to Packman of create the package as a pullin, like for example Broadcom wireless firmware packages. Which one is preferred?
Given the propriatory nature of basically al "plugins" for these on hw verify sensors, I stayed far away from packaging the goodix one I use, but if you end up doing so for your sensor, they should probably go into a non openSUSE repo, like Packman.
Thanks.
Gryffus
Cheers, Florian "sp1rit" -- $\int_\text{now}^{+\infty}\text{Keep trying}$ Matrix: @sp1rit:tchncs.de <sp1rit@disroot.org> D248BF2F4C6A82A1E0569D897D8C1CD573166D09 <sp1rit@national.shitposting.agency> BBDE032EAAFBFC627FB7E635B1F4055D8460CE34
On Wed, 2022-05-11 at 20:55 +0200, Florian "sp1rit" wrote:
Am Mittwoch, dem 11.05.2022 um 20:18 +0200 schrieb Lukáš Krejza:
@Sp1rit, do you plan to submit libfprint-tod to Factory? I noticed that there are some build failures for older Leap versions, but i don't know if these are required to be resolved before Factory submission.
Typically not for Factory, but AFAIK sometimes for individual devel projects. I never really intended to submit this to factory, given that it's basically just a "fork" of libfprint.
Using non-official repositories is generally discouraged. That's not my personal opinion, but frequently stated on this ML. Nothing outside of Factory (and the few semi-officially endorsed repos like packman) "exists", really, except for die-hard developers. Lukáš' post shows that there's user interest in including the -tod release officially. Technically, that shouldn't be a big issue, it could be realized with Provides: and Conflicts: tags. It depends on how well-maintained the upstream -tod fork is. Was it a one-time fork, or do they actively pull in fixes and changes from the libfprintd project? And it also depends on someone's (your?) willingness to take on the burden of doing the maintenance. Fingerprint readers have the special property that every system typically has just one device, so including both would even work if libfprintd-tod supported only a subset of libfprintd's supported devices. Regards Martin
Dne čtvrtek 12. května 2022 13:31:14 CEST, Martin Wilck napsal(a):
On Wed, 2022-05-11 at 20:55 +0200, Florian "sp1rit" wrote:
Am Mittwoch, dem 11.05.2022 um 20:18 +0200 schrieb Lukáš Krejza:
@Sp1rit, do you plan to submit libfprint-tod to Factory? I noticed that there are some build failures for older Leap versions, but i don't know if these are required to be resolved before Factory submission.
Typically not for Factory, but AFAIK sometimes for individual devel projects. I never really intended to submit this to factory, given that it's basically just a "fork" of libfprint.
Using non-official repositories is generally discouraged. That's not my personal opinion, but frequently stated on this ML. Nothing outside of Factory (and the few semi-officially endorsed repos like packman) "exists", really, except for die-hard developers.
Lukáš' post shows that there's user interest in including the -tod release officially. Technically, that shouldn't be a big issue, it could be realized with Provides: and Conflicts: tags.
It depends on how well-maintained the upstream -tod fork is. Was it a one-time fork, or do they actively pull in fixes and changes from the libfprintd project? And it also depends on someone's (your?) willingness to take on the burden of doing the maintenance.
Fingerprint readers have the special property that every system typically has just one device, so including both would even work if libfprintd-tod supported only a subset of libfprintd's supported devices.
Regards Martin
Hey Martin, I wouldn't rush with submission to Factory yet due to few reasons: 1) We will probably change names of packages to correspond with other distros and SUSE .so lib rpm naming convention. Currently, the "-tod" fork provides both libraries ( libfprint-2.so.2.0.0 _and_ libfprint-2-tod.so.1 ). We need to split these into 2 packages and make correct dependencies, as you already mentioned. But i think, that dropping "upstream" version completely would be wrong. I have asked developer of the "-tod" fork about differences in the libfprint-2.so.2.0.0 libraries between the forks here: https:// gitlab.freedesktop.org/3v1n0/libfprint/-/issues/5 if you want follow. 2) In the mentioned bug report, I am trying to solve also a (minor) bug that I am experiencing during testing. This needs to be resolved too, before the submission. 3) Currently, Arch linux packages both versions separately, for more info, please refer here: https://wiki.archlinux.org/title/fprint . We can get some inspiration there too (except that they provide both libraries in one package for the "tod" fork too, which i would like to avoid and solve it with dependencies) 4) The libfprint-tod and libfprint libraries are fully open-source, however, "tod" fork is basically useless without the closed source driver components. Main purpose of the fork is allowing loading external drivers as a libraries that are provided by vendors. This means that it is virtually useless without submitting the drivers (to packman or as a pullin packages) 5) Actual question here: Does RPM support Provides: modalias and/or Supplements: modalias for USB IDs? I would use it for the closed driver components, if possible. Regards, Gryffus
On Thu, 2022-05-12 at 14:57 +0200, Lukáš Krejza wrote:
But i think, that dropping "upstream" version completely would be wrong.
I wasn't suggesting that. I rather thought of an alternatives-like approach.
4) The libfprint-tod and libfprint libraries are fully open-source, however, "tod" fork is basically useless without the closed source driver components. Main purpose of the fork is allowing loading external drivers as a libraries that are provided by vendors. This means that it is virtually useless without submitting the drivers (to packman or as a pullin packages)
Understood. Doing that in packman would be one option. The other is providing an installation script and/or simply a reasonable HOWTO or wiki page. Most of the time, users will just have to drop a given file to a certain location. This is similar to dropping a FW blob into /lib/firmware, which a lot of us have had to do before.
5) Actual question here: Does RPM support Provides: modalias and/or Supplements: modalias for USB IDs? I would use it for the closed driver
components, if possible.
A couple of packages use this feature, e.g. bluez-firmware. Regards, Martin
Dne čtvrtek 12. května 2022 15:17:26 CEST, Martin Wilck napsal(a):
On Thu, 2022-05-12 at 14:57 +0200, Lukáš Krejza wrote:
But i think, that dropping "upstream" version completely would be wrong.
I wasn't suggesting that. I rather thought of an alternatives-like approach.
It seems we can drop the "original" version altogether, which would solve it even without needing alternatives. Check my other reply to Andrei. <snip>
5) Actual question here: Does RPM support Provides: modalias and/or Supplements: modalias for USB IDs? I would use it for the closed driver
components, if possible.
A couple of packages use this feature, e.g. bluez-firmware.
Thank you! I will implement it for the driver packages too :)
Regards, Martin
Regards, Gryffus
On Thu, May 12, 2022 at 2:32 PM Martin Wilck <martin.wilck@suse.com> wrote:
It depends on how well-maintained the upstream -tod fork is. Was it a one-time fork, or do they actively pull in fixes and changes from the libfprintd project?
Well, Ubuntu unconditionally ships libfprint-tod as replacement for libfprint (they split it into libfprint "proper" and libfprint-tod shared library), at least in 20.04 and 22.04 so it must be working for them. Briefly looking in GIT Merge tag 'v1.94.3' into tod 2021-11-02: v1.94.3 release So it appears to be actively pulling from the original libfprint.
Dne čtvrtek 12. května 2022 15:17:43 CEST, Andrei Borzenkov napsal(a):
On Thu, May 12, 2022 at 2:32 PM Martin Wilck <martin.wilck@suse.com> wrote:
It depends on how well-maintained the upstream -tod fork is. Was it a one-time fork, or do they actively pull in fixes and changes from the libfprintd project?
Well, Ubuntu unconditionally ships libfprint-tod as replacement for libfprint (they split it into libfprint "proper" and libfprint-tod shared library), at least in 20.04 and 22.04 so it must be working for them. Briefly looking in GIT
Merge tag 'v1.94.3' into tod 2021-11-02: v1.94.3 release
So it appears to be actively pulling from the original libfprint.
If this is the case, we can really drop the "proper" version and provide 2 packages built from "tod" fork instead (+ the drivers on Packman), like following: 1) libfprint-2-2 - containing libfprint-2.so.2 - built from "tod" fork package, packaged on b.o.o. 2) libfprint-2-tod1 - containing libfprint-2-tod.so.1 - built from "tod" fork package, packaged on b.o.o. 3) libfprint-2-tod1-broadcom - containing firmwares, udev rules and libfprint-2-tod-1-broadcom.so, packaged on Packman 4) libfprint-2-tod1-goodix - containing firmwares, udev rules and libfprint-2- tod-1-goodix.so, packaged on Packman This looks like the cleaniest solution to me and also corresponds with what other distros do. I have already proposed this to Sp1rit. Regards, Gryffus
On Thu, 2022-05-12 at 16:22 +0200, Lukáš Krejza wrote:
Dne čtvrtek 12. května 2022 15:17:43 CEST, Andrei Borzenkov napsal(a):
On Thu, May 12, 2022 at 2:32 PM Martin Wilck <martin.wilck@suse.com> wrote:
It depends on how well-maintained the upstream -tod fork is. Was it a one-time fork, or do they actively pull in fixes and changes from the libfprintd project?
Well, Ubuntu unconditionally ships libfprint-tod as replacement for libfprint (they split it into libfprint "proper" and libfprint-tod shared library), at least in 20.04 and 22.04 so it must be working for them. Briefly looking in GIT
Merge tag 'v1.94.3' into tod 2021-11-02: v1.94.3 release
So it appears to be actively pulling from the original libfprint.
If this is the case, we can really drop the "proper" version and provide 2 packages built from "tod" fork instead (+ the drivers on Packman), like following:
1) libfprint-2-2 - containing libfprint-2.so.2 - built from "tod" fork package, packaged on b.o.o. 2) libfprint-2-tod1 - containing libfprint-2-tod.so.1 - built from "tod" fork package, packaged on b.o.o.
3) libfprint-2-tod1-broadcom - containing firmwares, udev rules and libfprint-2-tod-1-broadcom.so, packaged on Packman 4) libfprint-2-tod1-goodix - containing firmwares, udev rules and libfprint-2- tod-1-goodix.so, packaged on Packman
This looks like the cleaniest solution to me and also corresponds with what other distros do. I have already proposed this to Sp1rit.
Yes, that should work. However I'm unsure about dropping libfprint and replacing it with libfprint-tod entirely, given that it opens up new attack surfaces, which is obviusly not desired in such a piece of (critical) PAM infrastrucute. I guess it's up to the maintainer of libfprint to decide (Mailaender, fstrba, thoenig) if libfprint-2-2 should be provided by libfprint-tod sources.
Regards, Gryffus
Regards, Florian "sp1rit" -- $\int_\text{now}^{+\infty}\text{Keep trying}$ Matrix: @sp1rit:tchncs.de <sp1rit@disroot.org> D248BF2F4C6A82A1E0569D897D8C1CD573166D09 <sp1rit@national.shitposting.agency> BBDE032EAAFBFC627FB7E635B1F4055D8460CE34
Am Mittwoch, dem 11.05.2022 um 18:55 +0200 schrieb Lukáš Krejza:
Dne středa 11. května 2022 18:38:13 CEST, Andrei Borzenkov napsal(a):
On 11.05.2022 17:31, Lukáš Krejza wrote:
Hi Geekos!
Recently, i have been trying to implement Broadcom fingerprint reader driver mentioned in subject. For this i have tried following approach: https:// github.com/dsd/fprintd/issues/3#issuecomment-962422370
It contains binary firmware, udev rules, fprint library and firmware install script written in python.
Result of my tries can be found here: https://paste.opensuse.org/view/raw/ 72229198 (except of the 70-libfprint-2.rules, which is the openSUSE one and listed just for comparison. FYI i am trying with 0a5c:5843 device. My tries were however unsuccessful (fprint does not recognize the device and so KDE does).
My question is, is there anything different between (open)SUSE and Debian or Arch regarding UDEV and/or firmware installation?
Dynamic driver loading requires fork of libfprint - libfprint-tod. As far as I can tell it is not available for openSUSE while Ubuntu is using this version.
I am using this one: https://build.opensuse.org/package/show/home:sp1rit/ libfprint-tod which has been fixed few hours ago for Tumbleweed by Sp1rit (only tests failed, which was fixed in latest git as i informed Sp1rit already)
Even if this version were available, it most certainly would not use /usr/lib/x86_64-linux-gnu path.
Cool! This has lead me to fiddling with fprint more and i got this message in logs: (fprintd:13711): libfprint-tod-DEBUG: 18:53:39.091: Impossible to load the shared drivers dir Error opening directory ?/usr/lib64/libfprint- 2/tod-1?: No such file or directory
I will fix the paths and keep you informed.
I cannot comment on possibility to replace libfprint with libfprint-tod in openSUSE, but as long as it works for other distributions may be it is an option ... someone needs to package it first :)
I can provide any debug information required, but i am stucked here it seems. I would be glad for any hints! It would be nice to get this reader working, since it is present in many Dell laptops and it is reported to be working in Debian derivates and Arch.
Best regards! Gryffus
I think biggest problem problem with including will be closed source library for the libfprint-2-tod1-broadcom driver. But the firmware itself is a binary blob too, so what do i know? Maybe it can be workaround with a pullin or packaged on packman? But testing first...
Hi, sp1rit here, since you've asked me about packaging udev/firmware rules for SUSE privately, but have since created this thread, I'll reply here for prosperities sake. I (luckily) don't run any broadcom devices, but use Goodix Fingerprint sensor (that does on HW verify). It sadly needs a propriatory shared library which is available in Cannonical/Dells XPS 9500 PPA [0]. I just dumped the library into `/usr/lib64/libfprint-2/tod-1/`, copied the udev rules into the same dir as Ubuntu (`/lib/udev/rules.d/`) and added myself to plugdev (If I wasn't already, don't remember). The general layout of that tod-broadcom driver [1] seems awfully similar. So I presume you should be able to put that shared lib into the same dir as me, same with that udev file (which seems to not need you to be part of any specific group). The difference seems to be these additional broadcom binary blobs in `/var/lib/fprint/fw`, I assume you also should just copy the into the same dir as Ubuntu does.
Thanks! Gryffus
Hope it helps, Florian "sp1rit" [0]:https://git.launchpad.net/~oem-solutions-engineers/libfprint-2-tod1-goodix/+... [1]:https://git.launchpad.net/libfprint-2-tod1-broadcom/tree/ -- $\int_\text{now}^{+\infty}\text{Keep trying}$ Matrix: @sp1rit:tchncs.de <sp1rit@disroot.org> D248BF2F4C6A82A1E0569D897D8C1CD573166D09 <sp1rit@national.shitposting.agency> BBDE032EAAFBFC627FB7E635B1F4055D8460CE34
participants (6)
-
Andrei Borzenkov -
Florian "sp1rit" -
Lukáš Krejza -
Martin Wilck -
Martin Wilck -
sp1rit