Template:3rd party drivers: Difference between revisions
(don't mess up Sundtek with Kernel driver disadvantages, it's totally different than nvidia drivers too so naming it in the same context is just wrong.) |
(remove the "sometimes" statements, sometimes even an asteroid crashes onto earth and hits someone, add clear pro and con statements, and yes we live in 2013 things evolve.) |
||
| Line 1: | Line 1: | ||
<div style="padding: 1px 2px 1px 2px; background-color: #ffeaa5; border: solid 1px #ffeaa5; font-size:-1;"> |
<div style="padding: 1px 2px 1px 2px; background-color: #ffeaa5; border: solid 1px #ffeaa5; font-size:-1;"> |
||
| ⚫ | |||
Why you SHOULD NOT want a device with 3rd party KERNEL drivers: |
|||
== In-Kernel Drivers == |
|||
| ⚫ | |||
<b>Advantages:</b><br/> |
|||
Sometimes there is another v4l-dvb fork, think multiproto, em28xx-new or s2-liplianin. These either get merged into v4l-dvb or are eventually forgotten. Sometimes a user has written a patch for a particular device, but the patch for whatever reason is not incorporated in v4l-dvb. And sometimes the manufacturer creates their own closed-source driver, like nVidia does for graphics chips. |
|||
1. You might get well support for your device<br/> |
|||
2. If the manufacturer provides open source drivers, volunteers are able to provide long term support and submit it to the Linux Kernel. |
|||
<b>Disadvantages:</b><br/> |
|||
Whatever the cause, all these are not part of v4l-dvb. Sooner or later the user or manufacturer might stop supporting these, but the Linux kernel will move on. When that happens, you have a few options: |
|||
1. If the manufacturer provides binary modules, or object files you might have to recompile the 3rd party driver every time you update your local kernel version<br /> |
|||
In case a manufacturer provides open source drivers the patches can be sent to the linux-media mailinglist [mailto:majordomo@vger.kernel.org?body=subscribe%20linux-media Linux-Media Mailing List] (LMML)<br /> |
|||
1. Stick with your current kernel for ever and ever. Not recommended.<br /> |
|||
2. Create and submit a patch for v4l-dvb to support the device that does get incorporated in v4l-dvb. Unless you're a programmer, you may not be able to.<br /> |
|||
3. Hire someone else to do that. May be expensive.<br /> |
|||
4. Buy a new device. Oh, you probably shouldn't have bought this one in the first place.<br /> |
|||
== Userspace Drivers == |
|||
You can contact the [mailto:majordomo@vger.kernel.org?body=subscribe%20linux-media Linux-Media Mailing List] (LMML) and see if perhaps there is a developer who would be willing to borrow your device to create support for it. No guarantees though. |
|||
<b>Advantages:</b><br/> |
|||
In the end, you should (sadly) generally not buy these. |
|||
1. Generic over nearly all Linux versions starting from 2.6.15 on<br/> |
|||
2. No recompilation needed if you update your kernel version<br/> |
|||
3. Manufacturer might provide well support for the device you bought<br/> |
|||
4. Drivers can be profiled easily and more accurately than in kernelspace<br/> |
|||
5. If the driver crashes your system won't be affected<br/> |
|||
<b>Disadvantages:</b><br/> |
|||
While 3rd party Kernel drivers can easily suffer discontinued support since the Linux kernel keeps evolving and the internal Kernel API changes. |
|||
1. this is only meant for hackers that they won't have insight about what the manufacturer is doing, regular endusers usually won't cope with device driver sources anyway<br/> |
|||
Drivers based on application level do not have that restriction these will just work since they are independent of various Linux kernel versions and do not require any recompilation (eg. Sundtek is doing this approach and supports nearly any Linux). |
|||
Independent drivers are only possible for USB (regularly since 2.6.15), PCI/e drivers can be done on application level using VFIO nowadays. |
|||
</div> |
</div> |
||
Revision as of 23:14, 13 December 2013
Sometimes a manufacturer forks v4l-dvb all on their own and writes a driver for their device so they can claim Linux support.
In-Kernel Drivers
Advantages:
1. You might get well support for your device
2. If the manufacturer provides open source drivers, volunteers are able to provide long term support and submit it to the Linux Kernel.
Disadvantages:
1. If the manufacturer provides binary modules, or object files you might have to recompile the 3rd party driver every time you update your local kernel version
In case a manufacturer provides open source drivers the patches can be sent to the linux-media mailinglist Linux-Media Mailing List (LMML)
Userspace Drivers
Advantages:
1. Generic over nearly all Linux versions starting from 2.6.15 on
2. No recompilation needed if you update your kernel version
3. Manufacturer might provide well support for the device you bought
4. Drivers can be profiled easily and more accurately than in kernelspace
5. If the driver crashes your system won't be affected
Disadvantages:
1. this is only meant for hackers that they won't have insight about what the manufacturer is doing, regular endusers usually won't cope with device driver sources anyway