1:56 a.m.
Hi,
Has anyone tried packaging v4l2loopback into Fedora? I'd really like
to set up a screen capture device for video conferencing stuff, but I
keep running into problems with SecureBoot. I don't really know what
I'm doing with mokutil or DKMS and I'm generally uncomfortable
building kernel modules myself. I would be far more comfortable simply
installing directly from a Fedora RPM that contains the signed kernel
module needed.
Does anybody have the requisite knowledge to create Fedora packaging
of v4l2loopback and is willing to package for F31? I'd be happy to
test... and possibly co-maintain, if the package maintenance were
sufficiently simple.
Thanks,
Christopher
11:22 a.m.
On Sun, Apr 5, 2020 at 9:03 AM Leigh Scott <leigh123linux(a)gmail.com> wrote:
Aren't external kernel modules banned by fedora packaging rules?
My recollection (from some time ago) was there was
a process to request a (short term) exception to
allow one to ship a kernel module if the kernel
module developer (not the packager) would
document the plans (and commit) to upstreaming
with a reasonable date attached. I don't recall such
a process being used any time recently, and I am
not even sure the process is still considered
operational (lots of policies get retired).
RPMFusion, of course, does ship kernel modules,
so there is that if someone wants to go that route.
2:18 p.m.
On Sun, 5 Apr 2020 at 11:08, Leigh Scott <leigh123linux(a)gmail.com> wrote:
Aren't external kernel modules banned by fedora packaging rules?
Yes, they are:
https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-pac...
--
Iñaki Úcar
3:12 p.m.
On Sun, Apr 5, 2020 at 3:20 PM Iñaki Ucar <iucar(a)fedoraproject.org> wrote:
On Sun, 5 Apr 2020 at 11:08, Leigh Scott <leigh123linux(a)gmail.com> wrote:
>
> Aren't external kernel modules banned by fedora packaging rules?
Yes, they are:
https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-pac...
According to those guidelines, they can't be packaged outside the main
kernel package. But, they can still be included in the main kernel
packaging. So, I guess I'm trying to reach out to whoever's involved
in packaging that.
3:43 p.m.
On Sun, 5 Apr 2020 at 22:23, Christopher <ctubbsii(a)fedoraproject.org> wrote:
On Sun, Apr 5, 2020 at 3:20 PM Iñaki Ucar <iucar(a)fedoraproject.org> wrote:
>
> On Sun, 5 Apr 2020 at 11:08, Leigh Scott <leigh123linux(a)gmail.com> wrote:
> >
> > Aren't external kernel modules banned by fedora packaging rules?
>
> Yes, they are:
https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-pac...
>
According to those guidelines, they can't be packaged outside the main
kernel package. But, they can still be included in the main kernel
packaging. So, I guess I'm trying to reach out to whoever's involved
in packaging that.
You can try contacting the Kernel Team, but the upstream maintainer
doesn't seem to be actively pushing for merging this into Linus' tree,
so it's hard to make a case for it in its current status [1]. RPM
Fusion and Copr are better targets for this.
[1] https://fedoraproject.org/wiki/KernelDriverPolicy
--
Iñaki Úcar
8:44 p.m.
On Sun, Apr 5, 2020 at 4:45 PM Iñaki Ucar <iucar(a)fedoraproject.org> wrote:
On Sun, 5 Apr 2020 at 22:23, Christopher <ctubbsii(a)fedoraproject.org> wrote:
>
> On Sun, Apr 5, 2020 at 3:20 PM Iñaki Ucar <iucar(a)fedoraproject.org> wrote:
> >
> > On Sun, 5 Apr 2020 at 11:08, Leigh Scott <leigh123linux(a)gmail.com>
wrote:
> > >
> > > Aren't external kernel modules banned by fedora packaging rules?
> >
> > Yes, they are:
https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-pac...
> >
>
> According to those guidelines, they can't be packaged outside the main
> kernel package. But, they can still be included in the main kernel
> packaging. So, I guess I'm trying to reach out to whoever's involved
> in packaging that.
You can try contacting the Kernel Team, but the upstream maintainer
doesn't seem to be actively pushing for merging this into Linus' tree,
so it's hard to make a case for it in its current status [1]. RPM
Fusion and Copr are better targets for this.
[1] https://fedoraproject.org/wiki/KernelDriverPolicy
The previous packaging was on COPR, but it appears abandoned, probably
because it's kind of worthless if it's not signed. And, it's a lot of
manual work to self-sign and register the key with mokutil, and even
more effort to figure out how to get DKMS to automatically sign after
building, on kernel updates.
I don't know enough about RPMFusion packaging. I use RPMFusion, but
haven't looked into the contribution process. In particular, I wonder
if their modules are signed by a key that's already trusted in Fedora.
My guess is not, and then it's the same problem as with COPR.
I'm probably going to abandon the effort anyway. obs-studio in Fedora
crashes constantly every time I try to change the settings and save,
so I couldn't figure out how to get it to work with v4l2loopback. I
also couldn't figure out how to get Slack or Chrome (Hangouts) to even
recognize the second v4l device. Only cheese saw the new video device
at all, but it couldn't display it, for some unknown reason.
Thanks for the advice, but I think I've reached the end of what I can
figure out or champion on my own.
2:50 a.m.
On Sun, Apr 5, 2020 at 4:45 PM Iñaki Ucar
<iucar(a)fedoraproject.org> wrote:
I don't know enough about RPMFusion packaging. I use RPMFusion,
but
haven't looked into the contribution process. In particular, I wonder
if their modules are signed by a key that's already trusted in Fedora.
My guess is not, and then it's the same problem as with COPR.
We don't sign any kmods at rpmfusion, there were some attempts to add signing to
akmods.
https://bugzilla.redhat.com/show_bug.cgi?id=1454824
2:57 a.m.
On Mon, 6 Apr 2020 at 03:53, Christopher <ctubbsii(a)fedoraproject.org> wrote:
The previous packaging was on COPR, but it appears abandoned, probably
because it's kind of worthless if it's not signed. And, it's a lot of
manual work to self-sign and register the key with mokutil, and even
more effort to figure out how to get DKMS to automatically sign after
building, on kernel updates.
I don't know enough about RPMFusion packaging. I use RPMFusion, but
haven't looked into the contribution process. In particular, I wonder
if their modules are signed by a key that's already trusted in Fedora.
My guess is not, and then it's the same problem as with COPR.
I don't know. But if you want to keep SecureBoot enabled, probably the
only way to go is to work with upstream to get the module into the
mainline kernel. If this module is as popular as it seems, it
shouldn't be hard to find more people interested and more hands to do
the necessary work.
I'm probably going to abandon the effort anyway. obs-studio in
Fedora
crashes constantly every time I try to change the settings and save,
Let me guess... GNOME Wayland session? I got a bug report in a Qt
package I maintain with this kind of issue. It's fixed by setting
QT_QPA_PLATFORM=xcb. Please, file a bug and tell obs' maintainer that
the best way to workaround the lack of Wayland compatibility is to add
that to obs' .desktop file as follows:
Exec=env QT_QPA_PLATFORM=xcb obs-studio
so I couldn't figure out how to get it to work with v4l2loopback.
I
also couldn't figure out how to get Slack or Chrome (Hangouts) to even
recognize the second v4l device. Only cheese saw the new video device
at all, but it couldn't display it, for some unknown reason.
Sorry, I can't help you with that.
--
Iñaki Úcar
3:40 a.m.
On Mon, Apr 6, 2020 at 3:59 AM Iñaki Ucar <iucar(a)fedoraproject.org> wrote:
On Mon, 6 Apr 2020 at 03:53, Christopher <ctubbsii(a)fedoraproject.org> wrote:
>
> The previous packaging was on COPR, but it appears abandoned, probably
> because it's kind of worthless if it's not signed. And, it's a lot of
> manual work to self-sign and register the key with mokutil, and even
> more effort to figure out how to get DKMS to automatically sign after
> building, on kernel updates.
>
> I don't know enough about RPMFusion packaging. I use RPMFusion, but
> haven't looked into the contribution process. In particular, I wonder
> if their modules are signed by a key that's already trusted in Fedora.
> My guess is not, and then it's the same problem as with COPR.
I don't know. But if you want to keep SecureBoot enabled, probably the
only way to go is to work with upstream to get the module into the
mainline kernel. If this module is as popular as it seems, it
shouldn't be hard to find more people interested and more hands to do
the necessary work.
> I'm probably going to abandon the effort anyway. obs-studio in Fedora
> crashes constantly every time I try to change the settings and save,
Let me guess... GNOME Wayland session? I got a bug report in a Qt
package I maintain with this kind of issue. It's fixed by setting
QT_QPA_PLATFORM=xcb. Please, file a bug and tell obs' maintainer that
the best way to workaround the lack of Wayland compatibility is to add
that to obs' .desktop file as follows:
Exec=env QT_QPA_PLATFORM=xcb obs-studio
GNOME, but I think it happens in both Xorg and Wayland. I haven't
attempted to troubleshoot this. One thing at a time. :)
4:31 a.m.
On Mon, 2020-04-06 at 04:40 -0400, Christopher wrote:
On Mon, Apr 6, 2020 at 3:59 AM Iñaki Ucar
<iucar(a)fedoraproject.org>
wrote:
> On Mon, 6 Apr 2020 at 03:53, Christopher <
> ctubbsii(a)fedoraproject.org> wrote:
> > The previous packaging was on COPR, but it appears abandoned,
> > probably
> > because it's kind of worthless if it's not signed. And, it's a
> > lot of
> > manual work to self-sign and register the key with mokutil, and
> > even
> > more effort to figure out how to get DKMS to automatically sign
> > after
> > building, on kernel updates.
> >
> > I don't know enough about RPMFusion packaging. I use RPMFusion,
> > but
> > haven't looked into the contribution process. In particular, I
> > wonder
> > if their modules are signed by a key that's already trusted in
> > Fedora.
> > My guess is not, and then it's the same problem as with COPR.
>
> I don't know. But if you want to keep SecureBoot enabled, probably
> the
> only way to go is to work with upstream to get the module into the
> mainline kernel. If this module is as popular as it seems, it
> shouldn't be hard to find more people interested and more hands to
> do
> the necessary work.
>
> > I'm probably going to abandon the effort anyway. obs-studio in
> > Fedora
> > crashes constantly every time I try to change the settings and
> > save,
>
> Let me guess... GNOME Wayland session? I got a bug report in a Qt
> package I maintain with this kind of issue. It's fixed by setting
> QT_QPA_PLATFORM=xcb. Please, file a bug and tell obs' maintainer
> that
> the best way to workaround the lack of Wayland compatibility is to
> add
> that to obs' .desktop file as follows:
>
> Exec=env QT_QPA_PLATFORM=xcb obs-studio
GNOME, but I think it happens in both Xorg and Wayland. I haven't
attempted to troubleshoot this. One thing at a time. :)
Do let me know if you face any issues with OBS Studio under Fedora.
I'm really trying to keep it in good shape, and up-to-date.
If you experience any issues the best thing to do is to report a bug on
RPMFusion.
Kind regards,
Momo.
10:39 p.m.
On Mon, Apr 6, 2020 at 5:35 AM Momčilo Medić
<fedorauser(a)fedoraproject.org> wrote:
On Mon, 2020-04-06 at 04:40 -0400, Christopher wrote:
> On Mon, Apr 6, 2020 at 3:59 AM Iñaki Ucar <iucar(a)fedoraproject.org>
> wrote:
> > On Mon, 6 Apr 2020 at 03:53, Christopher <
> > ctubbsii(a)fedoraproject.org> wrote:
> > > The previous packaging was on COPR, but it appears abandoned,
> > > probably
> > > because it's kind of worthless if it's not signed. And, it's
a
> > > lot of
> > > manual work to self-sign and register the key with mokutil, and
> > > even
> > > more effort to figure out how to get DKMS to automatically sign
> > > after
> > > building, on kernel updates.
> > >
> > > I don't know enough about RPMFusion packaging. I use RPMFusion,
> > > but
> > > haven't looked into the contribution process. In particular, I
> > > wonder
> > > if their modules are signed by a key that's already trusted in
> > > Fedora.
> > > My guess is not, and then it's the same problem as with COPR.
> >
> > I don't know. But if you want to keep SecureBoot enabled, probably
> > the
> > only way to go is to work with upstream to get the module into the
> > mainline kernel. If this module is as popular as it seems, it
> > shouldn't be hard to find more people interested and more hands to
> > do
> > the necessary work.
> >
> > > I'm probably going to abandon the effort anyway. obs-studio in
> > > Fedora
> > > crashes constantly every time I try to change the settings and
> > > save,
> >
> > Let me guess... GNOME Wayland session? I got a bug report in a Qt
> > package I maintain with this kind of issue. It's fixed by setting
> > QT_QPA_PLATFORM=xcb. Please, file a bug and tell obs' maintainer
> > that
> > the best way to workaround the lack of Wayland compatibility is to
> > add
> > that to obs' .desktop file as follows:
> >
> > Exec=env QT_QPA_PLATFORM=xcb obs-studio
>
> GNOME, but I think it happens in both Xorg and Wayland. I haven't
> attempted to troubleshoot this. One thing at a time. :)
Do let me know if you face any issues with OBS Studio under Fedora.
I'm really trying to keep it in good shape, and up-to-date.
If you experience any issues the best thing to do is to report a bug on
RPMFusion.
Sure. Can do. Where's the issue tracker URL?
11:59 a.m.
On Sun, 5 Apr 2020 21:44:16 -0400
Christopher <ctubbsii(a)fedoraproject.org> wrote:
I'm probably going to abandon the effort anyway. obs-studio in
Fedora
crashes constantly every time I try to change the settings and save,
so I couldn't figure out how to get it to work with v4l2loopback. I
You are using obs in a different way than I am, but it works without
issue here for my unsophisticated use. I've never had a crash. F31. I
am able to change settings, I changed the keymappings to use the left
windows key, finally getting some use out of it. I am using X, and I
start obs from a terminal so if anything *does* go wrong, I see the
output from the program. I've been really pleased with its
performance, though I'm sure I'm not really stressing it out the way
you want to.
10:47 p.m.
On Mon, Apr 6, 2020 at 1:00 PM stan via devel
<devel(a)lists.fedoraproject.org> wrote:
On Sun, 5 Apr 2020 21:44:16 -0400
Christopher <ctubbsii(a)fedoraproject.org> wrote:
> I'm probably going to abandon the effort anyway. obs-studio in Fedora
> crashes constantly every time I try to change the settings and save,
> so I couldn't figure out how to get it to work with v4l2loopback. I
You are using obs in a different way than I am, but it works without
issue here for my unsophisticated use. I've never had a crash. F31. I
am able to change settings, I changed the keymappings to use the left
windows key, finally getting some use out of it. I am using X, and I
start obs from a terminal so if anything *does* go wrong, I see the
output from the program. I've been really pleased with its
performance, though I'm sure I'm not really stressing it out the way
you want to.
I actually got it working with v4l2loopback. It normally works quite
well. But, changing settings still crashes.
Literally, all I have to do is: File -> Settings -> toggle any setting
(just to make "Apply" button available) -> click Apply
This results in a Segmentation fault every time.
In any case, the settings are usually saved first, so when I restart, it's fine.
If I get the motivation, I'll file a bug against the RPMFusion package.
As for the original issue regarding packaging: there is a ticket being
tracked to get it upstream into the kernel:
https://github.com/umlaeute/v4l2loopback/issues/268
12:11 a.m.
On Mon, 6 Apr 2020 23:47:53 -0400
Christopher <ctubbsii(a)fedoraproject.org> wrote:
I actually got it working with v4l2loopback. It normally works quite
That's great!
well. But, changing settings still crashes.
That's not.
Literally, all I have to do is: File -> Settings -> toggle any
setting
(just to make "Apply" button available) -> click Apply
This results in a Segmentation fault every time.
In any case, the settings are usually saved first, so when I restart,
it's fine. If I get the motivation, I'll file a bug against the
RPMFusion package.
Strange that the behavior is so different, especially on something as
basic as changing settings.
As for the original issue regarding packaging: there is a ticket
being
tracked to get it upstream into the kernel:
https://github.com/umlaeute/v4l2loopback/issues/268
Interesting, though I probably won't ever have a use for it, I think
I'll try building it into a custom kernel just for fun. Since it
doesn't seem to be changing a lot, once and done.
5:05 a.m.
On Tue, 7 Apr 2020 at 05:58, Christopher <ctubbsii(a)fedoraproject.org> wrote:
If I get the motivation, I'll file a bug against the RPMFusion package.
Here's the bug tracker: https://bugzilla.rpmfusion.org/
As for the original issue regarding packaging: there is a ticket
being
tracked to get it upstream into the kernel:
https://github.com/umlaeute/v4l2loopback/issues/268
Yeap, I saw this, and that's why I said that upstream doesn't seem to
be willing to push this forward, because the maintainer's message is
basically "I'm totally open, but I'm not going to move a finger
besides merging PRs".
--
Iñaki Úcar
10:39 p.m.
On Tue, Apr 7, 2020 at 6:06 AM Iñaki Ucar <iucar(a)fedoraproject.org> wrote:
On Tue, 7 Apr 2020 at 05:58, Christopher <ctubbsii(a)fedoraproject.org> wrote:
>
> If I get the motivation, I'll file a bug against the RPMFusion package.
Here's the bug tracker: https://bugzilla.rpmfusion.org/
Thanks.
> As for the original issue regarding packaging: there is a ticket being
> tracked to get it upstream into the kernel:
> https://github.com/umlaeute/v4l2loopback/issues/268
Yeap, I saw this, and that's why I said that upstream doesn't seem to
be willing to push this forward, because the maintainer's message is
basically "I'm totally open, but I'm not going to move a finger
besides merging PRs".
My interpretation of their message was more "I tried a little, but
don't know where to go from here". They might just need help... but I
don't really know. :)
One more thing: can anybody point me to good docs on how to
automatically sign DKMS on build/install in Fedora? I tried editing
/etc/dkms/framework.conf to add SIGN_TOOL and also POST_INST, but
nothing seemed to work. I can't even get my script to run. I can sign
it manually after I `dkms install` but that's kind of annoying to do
after every dnf update that updates the kernel. All the docs out there
seem to be written for Ubuntu, and the instructions don't seem to work
on Fedora. If I can't get good docs, I'm going to have to start
ripping apart /usr/sbin/dkms and filling it with print debug
statements. :)
11:12 a.m.
On Sun, 5 Apr 2020 02:56:08 -0400
Christopher <ctubbsii(a)fedoraproject.org> wrote:
Has anyone tried packaging v4l2loopback into Fedora? I'd really
like
to set up a screen capture device for video conferencing stuff, but I
keep running into problems with SecureBoot. I don't really know what
I'm doing with mokutil or DKMS and I'm generally uncomfortable
building kernel modules myself. I would be far more comfortable simply
installing directly from a Fedora RPM that contains the signed kernel
module needed.
Have you looked at OBS? It's actually a tool to create streaming
content, but it performs screen capture, and has key mappings so it can
be started and stopped without switching to the gui. It is on
rpmfusion.
Does anybody have the requisite knowledge to create Fedora packaging
of v4l2loopback and is willing to package for F31? I'd be happy to
test... and possibly co-maintain, if the package maintenance were
sufficiently simple.
Not me.
This is the procedure I used to create a local key in order to sign
custom compiled kernels. So, if you decide to plow on through, you
should be able to adapt it for your purposes. Though, if Leigh is
right, and out of tree modules are forbidden as Fedora packages, you
will have to keep the module rpm on your system only.
https://bugzilla.redhat.com/show_bug.cgi?id=1719930
3:39 p.m.
On Sun, Apr 5, 2020 at 12:13 PM stan via devel
<devel(a)lists.fedoraproject.org> wrote:
On Sun, 5 Apr 2020 02:56:08 -0400
Christopher <ctubbsii(a)fedoraproject.org> wrote:
> Has anyone tried packaging v4l2loopback into Fedora? I'd really like
> to set up a screen capture device for video conferencing stuff, but I
> keep running into problems with SecureBoot. I don't really know what
> I'm doing with mokutil or DKMS and I'm generally uncomfortable
> building kernel modules myself. I would be far more comfortable simply
> installing directly from a Fedora RPM that contains the signed kernel
> module needed.
Have you looked at OBS? It's actually a tool to create streaming
content, but it performs screen capture, and has key mappings so it can
be started and stopped without switching to the gui. It is on
rpmfusion.
tl;dr - OBS requires v4l2loopback to do what I need to do. And, even
without OBS, all the instructions out there to capture and share
specific screens (or portions of screens) in Linux using apps like
Slack describe using v4l2loopback.
I'm already using OBS. I use OBS to prepare the scene by combining all
the sources into the scene layout I want, but then I need to expose
that result into an output stream that can be used in Slack or other
apps. There are OBS plugins to emit the scene to a virtual video
capture device, and it works on Windows just fine, but for it to work
on Linux, I need to use the v4l2loopback module to create a virtual
camera that can be used in those streaming apps. As I understand it,
v4l2loopback is already available on Ubuntu. There was a COPR package
for it, but it hasn't been maintained in some time, and even when
bringing it up-to-date, it uses DKMS to build an unsigned kernel
module, which won't load. I'm not comfortable messing with mokutil and
SecureBoot configuration, and don't think it should be necessary to
get this functionality.
1487
days inactive
1490
days old
18 comments
6 participants
participants (6)
-
Christopher -
Gary Buhrmaster -
Iñaki Ucar -
Leigh Scott -
Momčilo Medić -
stan