Where to patch dvb driver in LibreELEC 9? Overlay confuses me...

wismann · April 12, 2018 at 9:32 PM

I want to patch a dvb driver for my box (stb0899_drv.c for Technisat SkyStar USB 2 HD CI).

I have successfully built HEAD of origin/master. Now I need to know where to patch the source file.

The driver is present three times in the source tree:

/image/system/usr/lib/kernel-overlays/driver.dvb.hauppauge/lib/modules/4.14.30/updates/driver.dvb.hauppauge/stb0899.ko
/image/system/usr/lib/kernel-overlays/base/lib/modules/4.14.30/kernel/drivers/media/dvb-frontends/stb0899.ko
/image/system/usr/lib/kernel-overlays/driver.dvb.crazycat/lib/modules/4.14.30/updates/driver.dvb.crazycat/stb0899.ko

Which of these will be seen from the kernel and how could I determine this myself? Any resources to the overlay happening here?

And where should I put the patch?

Sorry for the noobish questions

**chewitt** · April 13, 2018 at 5:21 AM Official Post

The build-system unpacks sources for a package, then applies diff patches in alphanumeric sequence before building the package. Patches follow a naming convention and need to be in diff format; patches are relative to the root folder of the unpacked sources.

See LibreELEC.tv/packages/linux-driver-addons/dvb/crazycat/patches at master · LibreELEC/LibreELEC.tv · GitHub for examples. If you're working on 'Generic' (4.14 kernel) ignore the amlogic folders which are specific to other kernels (although the format is the same).

wismann · April 13, 2018 at 6:09 AM

Thank you.

So you're suggesting patching the crazycat package. But how do I know if the driver from the crazycat package makes it into the image instead of the one from the hauppauge package?

**CvH** · April 13, 2018 at 9:24 AM Official Post

You can patch the vanilla kernel adding your patch here LibreELEC.tv/packages/linux/patches/default then the patch is used if you use the "standard kernel drivers" at the driver chooser.

If you like to test and play around with your patch you can also add them to the crazycat or hauppauge package. There you can build the whole image or just create and updated addon.

There you need to place your patch here LibreELEC.tv/packages/linux-driver-addons/dvb/hauppauge/sources/backports and add the patch to here LibreELEC.tv/driver.dvb.hauppauge-02-add-to-backports.patch

PROJECT=Generic ARCH=x86_64 scripts/create_addon hauppauge creates then an addon that could be installed and activated via the driver chooser.

The normal kernel is 4.14, crazycat and hauppauge are ~4.15 based, soon after pr is merged they are based at 4.17.

matthuo · April 7, 2022 at 1:41 PM

Quote from chewitt

The build-system unpacks sources for a package, then applies diff patches in alphanumeric sequence before building the package. Patches follow a naming convention and need to be in diff format; patches are relative to the root folder of the unpacked sources.
See LibreELEC.tv/packages/linux-driver-addons/dvb/crazycat/patches at master · LibreELEC/LibreELEC.tv · GitHub for examples. If you're working on 'Generic' (4.14 kernel) ignore the amlogic folders which are specific to other kernels (although the format is the same).

What are the specific naming rules? I'm currently doing a Patch, what is the correct naming convention?

In addition, the purpose of my Patch is to add DTS to support the new RK3399 device. Would like to ask, is it possible to replace the new package in source/u-boot/? Specifically, I changed the Makefile, added the DTS file, and added the defconfig file. That should be fine, right?

**chewitt** · April 8, 2022 at 6:19 AM

LE patches generally follow <package>-<number>-description.patch but it depends on who created them and where they are used, e.g. for Amlogic kernel stuff I'm generating patches using "git format-patch" so things are number sequenced; other maintainers bundle patches together into large sets (which I don't like, but each to their own). Regardless of the naming convention the build-system applies patches in alphanumeric sequence.

If you intention is to submit the patches to our git repo; be advised that we will not accept/merge them unless we can see the same patches on a kernel and/or u-boot mailing list with acks from maintainers, i.e. we will accept a backport of an upstream accepted patch, we will not accept an orphan patch that only exists in LE (else we will never get to drop the patch in a future kernel/u-boot bump).