Because of the success of the Video4Linux project, there are large numbers of device drivers available for multimedia cards, digital cameras, and USB devices currently on the market. Since V4L is an active, dynamic project with numerous contributing developers, new hardware drivers are created and bugs are addressed

On the other hand, BSD supports older Brooktree 'bktr' tuner chips that are no longer in production. If you want to watch TV on your FreeBSD system you might be able to find an old analog 'bktr' card on eBay. But why bother? In a few months (February 2009) there won't be any NTSC broadcasts in the USA, only ATSC will be available. In many other places, broadcasts are switching from PAL/SECAM to DVB-T.

Why BSD?

BSD systems are secure and stable. "Uptimes are measured in years". The occasional blue-screen, hang, hex-dump, hardware & software incompatibility, and virus infection is accepted as typical by a Windows-Vista user. Many companies don't want to base their consumer products on Microsoft because support for buggy systems and license fees eat into profits. Consumers have a choice and they won't buy a TV with a reputation that it periodically hangs and reboots.

BSD systems are developer friendly. Tools available on Linux are also available on BSD.

Many corporations find BSD a more 'business friendly' platform to take their product to market.

Philosophical Differences

There are fundamental philosophical differences in support for multimedia on Linux and BSD.

Linux has moved V4L support into the kernel. This certainly makes the kernel more complex, bloated, and prone to potential problems. Hundreds of devices, most of which are not currently in your system, are supported. When a hardware is no longer used, dead code will remain in the Linux kernel for years to come. New hardware will require newer kernels.

The BSD philosophy is that putting non-time critical code in the kernel only bloats the kernel. BSD seeks to protect the hardware by providing a level of abstraction between user programs and critical hardware. This is probably the main reason for BSD's vaunted stability.

Of course, if BSD doesn't support V4L, much work will have to be repeated in re-writing new hardware drivers. Most hardware which just 'plugs-n-plays' on Linux will never work on BSD. Bugs fixed in V4L will not be propagated to BSD.

There's similar project at: http://wiki.freebsd.org/HDTV Support for HDTV on FreeBSD is just starting out. John-Mark Gurney has added support an ATSC based card with work underway for a second. There is no known support for the DVB family. John-Mark Gurney has also written the beginning of a design document on how to provide generic multimedia support under FreeBSD.

Project Goal

This project will implement a V4L compatible API and device drivers for the BSD systems, enabling you to run Linux video applications on BSD. Our goal is to provide an emulation layer that would let us recompile the linux source code on BSD, and provide a sufficiently complete emulation of the Linux kernel APIs so that device drivers can be used without significant modifications to their source code.

Source for working device drivers, ports of Linux multimedia applications, along with notes on how to install various multimedia devices on BSD will be made available in this SourceForge repository. Project releases will have the FreeBSD copyright a simple, permissive, non-copyleft free software license, compatible with the GNU GPL.

Can it be done? Here's an example by Luigi Rizzo on Building Linux Device Drivers on FreeBSD for several webcams. Here's another example on porting a DVB-T television USB-Stick driver. (NOTE: the HW manufacturer has released a new revision of their DVB-T USB stick that is not supported by this driver. --- this is the reason this project is needed. If BSD had a central location providing HW drivers; updates, fixes, and new HW could be supported ).

The port available in: /usr/ports/devel/linux-kmod-compat claims that the "porting of a linux driver should be as simple as downloading the linux driver sources, writing a simple Makefile.kmod, and running "make -f Makefile.kld" to produce the driver.ko". Of course, current reality is not that simple --- not yet. In the words of Admiral Horatio Hornblower and Captain Jean-Luc Picard the goal of this project is to "Make it so".

Support this Project

Hardware manufacturers wanting to expand their customer base world-wide should consider donating hardware, specifications, and expertise to the Video-4-BSD project. Video-4-Linux has often been forced to valiantly create drivers via reverse engineering with USB and PCI bus sniffers. Some corporate legal departments are frightened by the GNU-GPL but have no problem with the FreeBSD license. By making hardware and software specifications available under the FreeBSD license, this project hopes to return/provide assistance to the Video-4-Linux project and a 'Thank You' for making it all possible.

OpenBSD -CURRENT has a video(4), a V4L compatibility layer... and uvideo(4) for newer UVC cameras.

If the layer you propose is incompatible, a lot of user land applications already written for Linux will go to waste.

I haven't read about your project in detail, but NTSC isn't entirely dead, it'll still be useful in rural areas.. and in Canada, it'll be around until at least 2011.

bktr(4) still had it's uses, your point about BSD not having things in kernel isn't entirely accurate either, OpenBSD for instance does not believe in kernel modules, while the functionality remains, it's not used by any kernel drivers. (I'm only aware of kqemu in ports that uses it..).

I'll read more about your project goals, but writing drivers for every tuner chipset sounds like a very daunting task...

Will the driver support *all* of the BSD derivatives? Without FreeBSD favouritism?

I haven't read about your project in detail, but NTSC isn't entirely dead, it'll still be useful in rural areas.. and in Canada, it'll be around until at least 2011.

NTSC will still be used for cable (at least until 2012), closed circuit TV, and internal hotel networks for years to come.

Quote:

your point about BSD not having things in kernel isn't entirely accurate either, OpenBSD for instance does not believe in kernel modules, while the functionality remains, it's not used by any kernel drivers. (I'm only aware of kqemu in ports that uses it..).

So porting V4L apps and drivers to OpenBSD is easy?

Quote:

I'll read more about your project goals, but writing drivers for every tuner chipset sounds like a very daunting task...

That's the whole point of the project -- the work has already been done for Video-4-Linux. We don't need to re-invent wheels.

Quote:

Will the driver support *all* of the BSD derivatives? Without FreeBSD favouritism?

Sounds like a good plan. I wonder about portability between the BSDs. So far we've just FreeBSD developers interested. Probably we'll need someone knowledgeable of OpenBSD device drivers with us on the team ( hint, hint,.. )

No drivers have no written to support such devices, porting them from Linux is a bad idea, GPL is only compatible in one direction.. can't have GPL code in a BSD project. (Though honestly, GPL proponents fail to understand the BSD licence and violate it often.).

video(4) was only recently developed, only uvideo(4) uses it... but, with that in tree, a motivated developer might write a driver for a ATSC/DVB tuner they own, it probably won't be a LKM though.

It's still early, but I can tell you.. not many will be interested in the concept of recompiling a Linux driver for usage on *BSD.

No drivers have no written to support such devices, porting them from Linux is a bad idea, GPL is only compatible in one direction.. can't have GPL code in a BSD project. (Though honestly, GPL proponents fail to understand the BSD licence and violate it often.).

Yes you have GPL code in a BSD project. Code licensed under the GNU GPL can be used in other projects, so long as they also are released under the same or a compatible license. We will be 'linking' to the Linux source and providing full source of all our wrappers which we'll release.

There are over 1700 'ports' in FreeBSD /usr/ports -- many are GPL'd. They are pulled in as source and built on FreeBSD. I don't see GNU ever suing FreeBSD. Linus Torvalds himself removed the “you may not distribute it for money” restrictions in 1992.

Quote:

Originally Posted by BSDfan666

video(4) was only recently developed, only uvideo(4) uses it... but, with that in tree, a motivated developer might write a driver for a ATSC/DVB tuner they own, it probably won't be a LKM though.

What about a developer motivated by money (from a corporation) that wants to deploy a multimedia/TV-tuner product built on a FreeBSD platform -- as long as source and modifications to all drivers are available it's OK.

The driver needs to be a LKM if it's going to be widely accepted in *BSD.

Quote:

Originally Posted by BSDfan666

It's still early, but I can tell you.. not many will be interested in the concept of recompiling a Linux driver for usage on *BSD.

I suppose the only people who would be interested are those who want to use new hardware; TV-Tuners, hot-pluggable USB devices, cameras, ... etc. in a *BSD environment.

Otherwise why bother with *BSD at all? Why not wipe the drive and replace it with a Linux distro which will run many devices that you need. --- But why bother with the trouble of Linux when most devices just run out-of-the-box on Windoze or a Mac?

cx88 provides drivers for TV/radio capture cards based on
the Conexant CX23880/1/2/3 series of chips. This port
includes the cx88 kernel drivers as well as a simple app
for HDTV capture. It requires multimedia/libtuner for
channel selection and peripheral configuration.

Not related to the Video for BSD project btw ... (This guy seems to produce less noise and more code).

I'd be interested in knowing how well it works ... I have a few (old) TV tuner cards, maybe one of them uses this chip ...

__________________
UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things.