A recent attempt to push some V4L/DVB updates for inclusion in the 2.6.24 Linux kernel met with some resistance. Linus Torvalds summarized the problems affecting the em28xx video driver:
"I've talked to various people, and none of the main kernel people end up being at all interested in a kernel that has external dependencies on binary blobs for tuners.
"So right now it seems like while I would personally want to have more vendors supprt their own drivers, if that in this case means that we'd have to have user-space and unmaintainable binaries to tune the cards, everybody seems to hate that idea."
Linus added, "as such, the old and decrepit em28xx driver seems more useful to people, since at least it supports the limited set of hardware on its own."
Andrew Morton also explained, "until your attempt to get the userspace-driver work merged into the kernel is successful (and from my reading of last month's discussion it is nowhere near that), we should continue to maintain the present driver." He went on to add:
"Until your attempt to get the userspace-driver work merged into the kernel is successful (and from my reading of last month's discussion it is nowhere near that), we should continue to maintain the present driver.
"If you choose to not participate in that maintenance then others will need to do their best in this regard.
"What we should not and will not do is to permit the current driver to be held hostage to your attempt to force a controversial and apparently unwelcome change into the tree."
From: Mauro Carvalho Chehab <mchehab@...> Subject: [GIT PATCHES] V4L/DVB changes for 2.6.24 Date: Oct 10, 5:50 pm 2007 Linus, Please pull from: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git master We have 300+ patches this time, covering lots of drivers improvements and fixes. Also, there are several core changes: - Unified support for Hybrid tuners on both V4L and DVB core; - videobuf split into PCI DMA S/G specific and a generic module; - added a videobuf handler for drivers that need vmalloc'ed memory like USB devices). And some driver additions: - cx23885 driver; - ivtv framebuffer driver; - tcm825x driver. I still have two cx88-alsa patches pending, at devel tree. Those two are dependent from -ALSA merge. So, I should send you a pull request later, after being sure that you've already pulled from alsa. Cheers, Mauro. --- Documentation/dvb/faq.txt | 2 +- Documentation/video4linux/CARDLIST.bttv | 1 + Documentation/video4linux/CARDLIST.cx23885 | 5 + Documentation/video4linux/CARDLIST.saa7134 | 5 +- drivers/media/Kconfig | 70 +- drivers/media/common/Kconfig | 2 +- drivers/media/common/ir-functions.c | 1 - drivers/media/common/ir-keymaps.c | 62 +- drivers/media/common/saa7146_core.c | 34 +- drivers/media/common/saa7146_fops.c | 5 +- drivers/media/common/saa7146_i2c.c | 23 +- drivers/media/common/saa7146_vbi.c | 9 +- drivers/media/common/saa7146_video.c | 11 +- drivers/media/dvb/bt8xx/bt878.c | 1 - drivers/media/dvb/bt8xx/bt878.h | 7 +- drivers/media/dvb/bt8xx/dvb-bt8xx.c | 1 - drivers/media/dvb/cinergyT2/cinergyT2.c | 8 +- drivers/media/dvb/dvb-core/dmxdev.c | 1 - drivers/media/dvb/dvb-core/dvb_ca_en50221.c | 93 +- drivers/media/dvb/dvb-core/dvb_demux.c | 5 +- drivers/media/dvb/dvb-core/dvb_frontend.c | 125 ++- drivers/media/dvb/dvb-core/dvb_frontend.h | 13 +- drivers/media/dvb/dvb-core/dvb_net.c | 22 +- drivers/media/dvb/dvb-core/dvbdev.c | 41 +- drivers/media/dvb/dvb-usb/Kconfig | 2 + drivers/media/dvb/dvb-usb/dib0700.h | 5 +- drivers/media/dvb/dvb-usb/dib0700_core.c | 23 +- drivers/media/dvb/dvb-usb/dib0700_devices.c | 676 +++++++++- drivers/media/dvb/dvb-usb/dtt200u.c | 28 +- drivers/media/dvb/dvb-usb/dvb-usb-ids.h | 26 +- drivers/media/dvb/dvb-usb/dvb-usb-init.c | 2 +- drivers/media/dvb/dvb-usb/gp8psk-fe.c | 84 +- drivers/media/dvb/dvb-usb/gp8psk.c | 93 +- drivers/media/dvb/dvb-usb/gp8psk.h | 32 +- drivers/media/dvb/dvb-usb/vp7045.c | 2 +- drivers/media/dvb/frontends/Kconfig | 33 +- drivers/media/dvb/frontends/Makefile | 4 + drivers/media/dvb/frontends/bcm3510.c | 1 - drivers/media/dvb/frontends/cx22700.c | 1 - drivers/media/dvb/frontends/cx24110.c | 1 - drivers/media/dvb/frontends/cx24123.c | 1 - drivers/media/dvb/frontends/dib0070.c | 580 ++++++++ drivers/media/dvb/frontends/dib0070.h | 44 + drivers/media/dvb/frontends/dib3000mb.c | 1 - drivers/media/dvb/frontends/dib3000mc.c | 192 ++- drivers/media/dvb/frontends/dib7000m.c | 727 ++++++---- drivers/media/dvb/frontends/dib7000p.c | 908 ++++++++---- drivers/media/dvb/frontends/dib7000p.h | 14 +- drivers/media/dvb/frontends/dibx000_common.h | 57 +- drivers/media/dvb/frontends/dvb-pll.c | 147 ++- drivers/media/dvb/frontends/dvb_dummy_fe.c | 1 - drivers/media/dvb/frontends/isl6421.c | 1 - drivers/media/dvb/frontends/l64781.c | 1 - drivers/media/dvb/frontends/lgdt330x.c | 1 - drivers/media/dvb/frontends/lnbp21.c | 1 - drivers/media/dvb/frontends/mt2060.c | 1 - drivers/media/dvb/frontends/mt2131.c | 314 ++++ drivers/media/dvb/frontends/mt2131.h | 54 + drivers/media/dvb/frontends/mt2131_priv.h | 49 + drivers/media/dvb/frontends/mt2266.c | 287 ++++ drivers/media/dvb/frontends/mt2266.h | 37 + drivers/media/dvb/frontends/mt312.c | 1 - drivers/media/dvb/frontends/mt352.c | 1 - drivers/media/dvb/frontends/nxt200x.c | 1 - drivers/media/dvb/frontends/or51132.c | 1 - drivers/media/dvb/frontends/or51211.c | 1 - drivers/media/dvb/frontends/s5h1409.c | 729 ++++++++++ drivers/media/dvb/frontends/s5h1409.h | 73 + drivers/media/dvb/frontends/sp8870.c | 1 - drivers/media/dvb/frontends/sp887x.c | 1 - drivers/media/dvb/frontends/stv0297.c | 4 +- drivers/media/dvb/frontends/stv0299.c | 1 - drivers/media/dvb/frontends/tda10021.c | 4 +- drivers/media/dvb/frontends/tda10023.c | 10 +- drivers/media/dvb/frontends/tda1004x.c | 1 - drivers/media/dvb/frontends/tda10086.c | 1 - drivers/media/dvb/frontends/tda8083.c | 9 +- drivers/media/dvb/frontends/ves1820.c | 4 +- drivers/media/dvb/frontends/zl10353.c | 1 - drivers/media/dvb/ttpci/av7110.c | 3 +- drivers/media/dvb/ttpci/av7110_hw.c | 28 +- drivers/media/dvb/ttpci/av7110_ir.c | 3 +- drivers/media/dvb/ttpci/av7110_v4l.c | 6 +- drivers/media/dvb/ttpci/budget-av.c | 2 +- drivers/media/dvb/ttpci/budget-ci.c | 2 +- drivers/media/dvb/ttpci/budget-core.c | 1 - drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c | 1 - drivers/media/dvb/ttusb-dec/ttusb_dec.c | 1 - drivers/media/radio/Kconfig | 24 +- drivers/media/radio/radio-gemtek.c | 618 ++++++--- drivers/media/radio/radio-terratec.c | 2 +- drivers/media/video/Kconfig | 29 +- drivers/media/video/Makefile | 28 +- drivers/media/video/arv.c | 3 +- drivers/media/video/bt8xx/Kconfig | 2 +- drivers/media/video/bt8xx/bttv-cards.c | 38 +- drivers/media/video/bt8xx/bttv-driver.c | 31 +- drivers/media/video/bt8xx/bttv-gpio.c | 6 +- drivers/media/video/bt8xx/bttv-i2c.c | 1 - drivers/media/video/bt8xx/bttv-input.c | 1 - drivers/media/video/bt8xx/bttv-risc.c | 35 +- drivers/media/video/bt8xx/bttv-vbi.c | 6 +- drivers/media/video/bt8xx/bttv.h | 2 + drivers/media/video/bt8xx/bttvp.h | 2 +- drivers/media/video/btcx-risc.c | 1 - drivers/media/video/bw-qcam.c | 18 +- drivers/media/video/cafe_ccic.c | 21 +- drivers/media/video/compat_ioctl32.c | 5 + drivers/media/video/cpia.c | 1 - drivers/media/video/cpia2/cpia2_v4l.c | 1 - drivers/media/video/cx2341x.c | 19 +- drivers/media/video/cx23885/Kconfig | 20 + drivers/media/video/cx23885/Makefile | 9 + drivers/media/video/cx23885/cx23885-cards.c | 280 ++++ drivers/media/video/cx23885/cx23885-core.c | 1530 ++++++++++++++++++++ drivers/media/video/cx23885/cx23885-dvb.c | 213 +++ drivers/media/video/cx23885/cx23885-i2c.c | 382 +++++ drivers/media/video/cx23885/cx23885-reg.h | 431 ++++++ drivers/media/video/cx23885/cx23885.h | 301 ++++ drivers/media/video/cx25840/cx25840-audio.c | 75 +- drivers/media/video/cx25840/cx25840-core.c | 98 +- drivers/media/video/cx25840/cx25840-core.h | 6 +- drivers/media/video/cx88/Kconfig | 4 +- drivers/media/video/cx88/cx88-alsa.c | 315 ++-- drivers/media/video/cx88/cx88-blackbird.c | 31 +- drivers/media/video/cx88/cx88-cards.c | 219 +++- drivers/media/video/cx88/cx88-core.c | 222 +--- drivers/media/video/cx88/cx88-dvb.c | 25 +- drivers/media/video/cx88/cx88-i2c.c | 27 +- drivers/media/video/cx88/cx88-input.c | 20 +- drivers/media/video/cx88/cx88-mpeg.c | 142 +- drivers/media/video/cx88/cx88-reg.h | 35 + drivers/media/video/cx88/cx88-tvaudio.c | 22 +- drivers/media/video/cx88/cx88-vbi.c | 13 +- drivers/media/video/cx88/cx88-video.c | 169 +-- drivers/media/video/cx88/cx88-vp3054-i2c.c | 5 +- drivers/media/video/cx88/cx88.h | 39 +- drivers/media/video/dpc7146.c | 5 +- drivers/media/video/em28xx/em28xx-core.c | 1 - drivers/media/video/em28xx/em28xx-input.c | 1 - drivers/media/video/em28xx/em28xx-video.c | 6 +- drivers/media/video/et61x251/et61x251_core.c | 59 +- drivers/media/video/ir-kbd-i2c.c | 38 +- drivers/media/video/ivtv/Kconfig | 17 + drivers/media/video/ivtv/Makefile | 5 +- drivers/media/video/ivtv/ivtv-audio.c | 74 - drivers/media/video/ivtv/ivtv-cards.c | 84 +- drivers/media/video/ivtv/ivtv-cards.h | 67 +- drivers/media/video/ivtv/ivtv-controls.c | 16 +- drivers/media/video/ivtv/ivtv-controls.h | 5 + drivers/media/video/ivtv/ivtv-driver.c | 332 +++-- drivers/media/video/ivtv/ivtv-driver.h | 691 ++++------ drivers/media/video/ivtv/ivtv-fileops.c | 199 ++-- drivers/media/video/ivtv/ivtv-fileops.h | 5 + drivers/media/video/ivtv/ivtv-firmware.h | 5 + drivers/media/video/ivtv/ivtv-gpio.c | 24 - drivers/media/video/ivtv/ivtv-gpio.h | 7 +- drivers/media/video/ivtv/ivtv-i2c.c | 17 +- drivers/media/video/ivtv/ivtv-i2c.h | 5 + drivers/media/video/ivtv/ivtv-ioctl.c | 191 ++- drivers/media/video/ivtv/ivtv-ioctl.h | 5 + drivers/media/video/ivtv/ivtv-irq.c | 321 +++-- drivers/media/video/ivtv/ivtv-irq.h | 27 + drivers/media/video/ivtv/ivtv-mailbox.c | 6 +- drivers/media/video/ivtv/ivtv-mailbox.h | 8 + drivers/media/video/ivtv/ivtv-queue.c | 119 +- drivers/media/video/ivtv/ivtv-queue.h | 13 +- .../video/ivtv/{ivtv-video.c => ivtv-routing.c} | 90 +- .../video/ivtv/{ivtv-audio.h => ivtv-routing.h} | 12 +- drivers/media/video/ivtv/ivtv-streams.c | 131 +-- drivers/media/video/ivtv/ivtv-streams.h | 5 + drivers/media/video/ivtv/ivtv-udma.c | 46 +- drivers/media/video/ivtv/ivtv-udma.h | 5 + drivers/media/video/ivtv/ivtv-vbi.c | 283 ++-- drivers/media/video/ivtv/ivtv-vbi.h | 9 +- drivers/media/video/ivtv/ivtv-version.h | 7 +- drivers/media/video/ivtv/ivtv-video.h | 24 - drivers/media/video/ivtv/ivtv-yuv.c | 55 +- drivers/media/video/ivtv/ivtv-yuv.h | 21 + drivers/media/video/ivtv/ivtvfb.c | 1190 +++++++++++++++ drivers/media/video/msp3400-driver.c | 19 +- drivers/media/video/mt20xx.c | 311 +++-- drivers/media/video/mt20xx.h | 37 + drivers/media/video/mxb.c | 4 +- drivers/media/video/ov511.c | 81 +- drivers/media/video/ov7670.c | 1 - drivers/media/video/ovcamchip/ovcamchip_core.c | 1 - drivers/media/video/planb.c | 30 +- drivers/media/video/pvrusb2/pvrusb2-context.c | 6 +- drivers/media/video/pvrusb2/pvrusb2-debug.h | 53 +- drivers/media/video/pvrusb2/pvrusb2-debugifc.c | 16 +- drivers/media/video/pvrusb2/pvrusb2-hdw-internal.h | 1 + drivers/media/video/pvrusb2/pvrusb2-hdw.c | 310 ++++- drivers/media/video/pvrusb2/pvrusb2-hdw.h | 12 +- drivers/media/video/pvrusb2/pvrusb2-i2c-core.c | 63 +- drivers/media/video/pvrusb2/pvrusb2-main.c | 2 +- drivers/media/video/pvrusb2/pvrusb2-std.c | 8 +- drivers/media/video/pvrusb2/pvrusb2-sysfs.c | 216 ++-- drivers/media/video/pwc/pwc-ctrl.c | 2 +- drivers/media/video/pwc/pwc-if.c | 132 ++- drivers/media/video/saa6588.c | 1 + drivers/media/video/saa7127.c | 10 +- drivers/media/video/saa7134/Kconfig | 4 +- drivers/media/video/saa7134/saa7134-alsa.c | 3 +- drivers/media/video/saa7134/saa7134-cards.c | 57 +- drivers/media/video/saa7134/saa7134-core.c | 214 ++- drivers/media/video/saa7134/saa7134-dvb.c | 23 +- drivers/media/video/saa7134/saa7134-empress.c | 18 +- drivers/media/video/saa7134/saa7134-i2c.c | 1 - drivers/media/video/saa7134/saa7134-input.c | 1 - drivers/media/video/saa7134/saa7134-oss.c | 43 +- drivers/media/video/saa7134/saa7134-ts.c | 30 +- drivers/media/video/saa7134/saa7134-tvaudio.c | 5 +- drivers/media/video/saa7134/saa7134-vbi.c | 7 +- drivers/media/video/saa7134/saa7134-video.c | 210 ++-- drivers/media/video/saa7134/saa7134.h | 23 +- drivers/media/video/sn9c102/sn9c102_core.c | 113 +- drivers/media/video/stv680.c | 51 +- drivers/media/video/tcm825x.c | 928 ++++++++++++ drivers/media/video/tcm825x.h | 199 +++ drivers/media/video/tda8290.c | 517 ++++--- drivers/media/video/tda8290.h | 54 + drivers/media/video/tda9887.c | 62 +- drivers/media/video/tea5761.c | 187 ++- drivers/media/video/tea5761.h | 47 + drivers/media/video/tea5767.c | 203 ++- drivers/media/video/tea5767.h | 47 + drivers/media/video/tuner-core.c | 256 +++- drivers/media/video/tuner-driver.h | 44 +- drivers/media/video/tuner-i2c.h | 70 + drivers/media/video/tuner-simple.c | 397 ++++-- drivers/media/video/tuner-simple.h | 46 + drivers/media/video/tuner-types.c | 8 + drivers/media/video/tvaudio.c | 1 - drivers/media/video/tveeprom.c | 1 - drivers/media/video/tvmixer.c | 6 +- drivers/media/video/usbvision/usbvision-core.c | 1 - drivers/media/video/usbvision/usbvision-i2c.c | 4 +- drivers/media/video/usbvision/usbvision-video.c | 120 +- drivers/media/video/v4l1-compat.c | 1 - drivers/media/video/v4l2-common.c | 6 +- drivers/media/video/v4l2-int-device.c | 158 ++ drivers/media/video/video-buf.c | 1425 ------------------ drivers/media/video/videobuf-core.c | 1006 +++++++++++++ drivers/media/video/videobuf-dma-sg.c | 726 ++++++++++ .../video/{video-buf-dvb.c => videobuf-dvb.c} | 9 +- drivers/media/video/videobuf-vmalloc.c | 370 +++++ drivers/media/video/videodev.c | 39 +- drivers/media/video/vino.c | 1 - drivers/media/video/vivi.c | 185 +-- drivers/media/video/vp27smpx.c | 212 +++ drivers/media/video/w9968cf.c | 3 +- drivers/media/video/zc0301/zc0301_core.c | 3 +- drivers/media/video/zoran_card.c | 64 +- drivers/media/video/zoran_card.h | 8 + drivers/media/video/zoran_device.c | 19 +- drivers/media/video/zoran_driver.c | 31 +- drivers/media/video/zoran_procfs.c | 9 +- drivers/media/video/zr36016.c | 4 +- drivers/media/video/zr36050.c | 6 +- drivers/media/video/zr36060.c | 6 +- include/linux/i2c-id.h | 2 + include/{media => linux}/ivtv.h | 11 +- .../ivtv/ivtv-audio.h => include/linux/ivtvfb.h | 31 +- include/linux/videodev2.h | 7 +- include/media/cx2341x.h | 2 +- include/media/ir-common.h | 1 + include/media/saa7146.h | 1 - include/media/saa7146_vv.h | 2 +- include/media/tuner-types.h | 4 + include/media/tuner.h | 1 + include/media/v4l2-chip-ident.h | 3 + include/media/v4l2-dev.h | 16 +- include/media/v4l2-int-device.h | 278 ++++ include/media/{video-buf.h => videobuf-core.h} | 181 +-- include/media/videobuf-dma-sg.h | 122 ++ include/media/{video-buf-dvb.h => videobuf-dvb.h} | 0 include/media/videobuf-vmalloc.h | 41 + 278 files changed, 19304 insertions(+), 6634 deletions(-) create mode 100644 Documentation/video4linux/CARDLIST.cx23885 create mode 100644 drivers/media/dvb/frontends/dib0070.c create mode 100644 drivers/media/dvb/frontends/dib0070.h create mode 100644 drivers/media/dvb/frontends/mt2131.c create mode 100644 drivers/media/dvb/frontends/mt2131.h create mode 100644 drivers/media/dvb/frontends/mt2131_priv.h create mode 100644 drivers/media/dvb/frontends/mt2266.c create mode 100644 drivers/media/dvb/frontends/mt2266.h create mode 100644 drivers/media/dvb/frontends/s5h1409.c create mode 100644 drivers/media/dvb/frontends/s5h1409.h create mode 100644 drivers/media/video/cx23885/Kconfig create mode 100644 drivers/media/video/cx23885/Makefile create mode 100644 drivers/media/video/cx23885/cx23885-cards.c create mode 100644 drivers/media/video/cx23885/cx23885-core.c create mode 100644 drivers/media/video/cx23885/cx23885-dvb.c create mode 100644 drivers/media/video/cx23885/cx23885-i2c.c create mode 100644 drivers/media/video/cx23885/cx23885-reg.h create mode 100644 drivers/media/video/cx23885/cx23885.h delete mode 100644 drivers/media/video/ivtv/ivtv-audio.c rename drivers/media/video/ivtv/{ivtv-video.c => ivtv-routing.c} (59%) copy drivers/media/video/ivtv/{ivtv-audio.h => ivtv-routing.h} (80%) delete mode 100644 drivers/media/video/ivtv/ivtv-video.h create mode 100644 drivers/media/video/ivtv/ivtvfb.c create mode 100644 drivers/media/video/mt20xx.h create mode 100644 drivers/media/video/tcm825x.c create mode 100644 drivers/media/video/tcm825x.h create mode 100644 drivers/media/video/tda8290.h create mode 100644 drivers/media/video/tea5761.h create mode 100644 drivers/media/video/tea5767.h create mode 100644 drivers/media/video/tuner-i2c.h create mode 100644 drivers/media/video/tuner-simple.h create mode 100644 drivers/media/video/v4l2-int-device.c delete mode 100644 drivers/media/video/video-buf.c create mode 100644 drivers/media/video/videobuf-core.c create mode 100644 drivers/media/video/videobuf-dma-sg.c rename drivers/media/video/{video-buf-dvb.c => videobuf-dvb.c} (97%) create mode 100644 drivers/media/video/videobuf-vmalloc.c create mode 100644 drivers/media/video/vp27smpx.c rename include/{media => linux}/ivtv.h (93%) rename drivers/media/video/ivtv/ivtv-audio.h => include/linux/ivtvfb.h (56%) create mode 100644 include/media/v4l2-int-device.h rename include/media/{video-buf.h => videobuf-core.h} (56%) create mode 100644 include/media/videobuf-dma-sg.h rename include/media/{video-buf-dvb.h => videobuf-dvb.h} (100%) create mode 100644 include/media/videobuf-vmalloc.h Adrian Bunk (5): V4L/DVB (5940): Export v4l2_int_device_{, un}register V4L/DVB (5965): Frontend_ioctl(): fix check-after-use V4L/DVB (6009): Bt8xx: "extern inline" -> "static inline" V4L/DVB (6025): Net_ule(): fix check-after-use V4L/DVB (6122): ivtvfb: fix an obvious bug in ivtvfb_release_buffers() Alan Nisota (1): V4L/DVB (6037): Updated GenPix USB driver Andi Drebes (2): V4L/DVB (5941): Ttpci/budget-av.c: ARRAY_SIZE() V4L/DVB (5942): Usb/vp7045.c: ARRAY_SIZE() Andres Salomon (1): V4L/DVB (6235): cafe_ccic: default to allocating DMA buffers at probe time Brandon Philips (5): V4L/DVB (6273): V4L: vivi.c vidioc_try_fmt_cap() negotiate a valid field V4L/DVB (6274): V4L: vivi.c replace logic in vivi_poll with videobuf_poll_stream V4L/DVB (6275): V4L: vivi.c remove the "resource" locking V4L/DVB (6276): V4L: videobuf-core.c lock before streaming check V4L/DVB (6305): V4L: videobuf-core.c avoid NULL dereferences in videobuf-core Brett Warden (2): V4L/DVB (6238): bw-qcam: use data_reverse instead of manually poking the control register V4L/DVB (6250): bw-qcam use data_reverse instead of manually poking the control register fix Chaogui Zhang (1): V4L/DVB (6178): add IR remote support for FusionHDTV 5 RT Gold Christoph Hellwig (1): V4L/DVB (6279): en_50221: convert to kthread API Darren Salt (2): V4L/DVB (6039): Typo fix in Nova-TD description V4L/DVB (6040): Add IR support for Nova-T Stick Edgar Simo (2): V4L/DVB (6071): saa7134-dvb: add missing newline V4L/DVB (6072): saa7134: add DVB-T support for Avermedia Super 007 Eric Sandeen (1): V4L/DVB (6295): saa7134: add autodetection for KWorld ATSC-115 Hans Verkuil (63): V4L/DVB (5881): ivtv: init channel for NTSC_M_JP standard. V4L/DVB (5902): Add ivtv-fb framebuffer driver. V4L/DVB (5904): ivtv-fb: cleanups V4L/DVB (5905): ivtv-fb: Use proper ioctl value V4L/DVB (5906): ivtv-fb: replace HZ with msecs_to_jiffies V4L/DVB (5909): ivtv: update version to 1.1 to mark ivtv-fb support V4L/DVB (5910): ivtv-fb: improve debug message V4L/DVB (5919): ivtv: remove dead code V4L/DVB (5921): ivtv: add missing composite input line for ivtv_pci_pg600v2 V4L/DVB (5922): ivtv, cx25840: postpone fw load until first use V4L/DVB (5924): ivtv-fb: initializing the fb should trigger ivtv firmware load V4L/DVB (5927): ivtv: set correct crystal frequency of the GVMVPRX cards V4L/DVB (5928): tuner: fix TOP values for the Panasonic VP27 tuner. V4L/DVB (5929): Add vp27smpx driver V4L/DVB (5992): ivtv: show card name as well in the LOG_STATUS output. V4L/DVB (5993): cx25840: resetting also requires reloading the firmware V4L/DVB (5994): ivtv: make VIDIOC_INT_RESET support smarter. V4L/DVB (5995): ivtv: add AverMedia M116 V4L/DVB (5997): cx25840: fix audio mute handling and reporting V4L/DVB (5998): ivtv: no need to mute the audio input V4L/DVB (5999): cx25840: add radio support. V4L/DVB (6002): ivtv: remove unused struct field. V4L/DVB (6003): vp27smpx: correctly attribute the origin of the driver V4L/DVB (6043): ivtv: fix incorrect round-robin implementation V4L/DVB (6045): ivtv: fix handling of INITIALIZE_INPUT fw call V4L/DVB (6046): ivtv: always steal full frames if out of buffers. V4L/DVB (6047): ivtv: Fix scatter/gather DMA timeouts V4L/DVB (6048): ivtv: fix stop stream locking V4L/DVB (6049): ivtv: fix VBI reinsertion decoding V4L/DVB (6050): ivtv: retry/timer improvements V4L/DVB (6051): cx25840: make proper use of SOFT_RESET V4L/DVB (6053): ivtv: setup TV output standard on init to prevent flicker V4L/DVB (6054): ivtv: specify some stream sizes in kB instead of MB V4L/DVB (6055): ivtv: improve debug messages V4L/DVB (6056): ivtv: move serialization to the fileops level V4L/DVB (6057): ivtv-fb: remove unused header includes V4L/DVB (6058): ivtv: add support for highmem udma V4L/DVB (6059): ivtv: log stereo/bilingual audio modes V4L/DVB (6060): ivtv: fix IVTV_IOC_DMA_FRAME bug introduced by highmem bugfix V4L/DVB (6061): ivtv: add VIDIOC_OVERLAY V4L/DVB (6086): ivtv: fix output mode processing: UDMA_YUV wasn't cleared V4L/DVB (6087): ivtv: prevent changing VBI format while capture is in progress V4L/DVB (6088): cx2341x: some controls can't be changed while the device is busy V4L/DVB (6089): ivtv: log in status if framebuffer uses YUV instead of RGB V4L/DVB (6090): ivtv-fb: correct transparency bit reporting V4L/DVB (6091): ivtv: header cleanup V4L/DVB (6092): ivtv: more cleanups, merged ivtv-audio.c and ivtv-video.c into ivtv-routing.c V4L/DVB (6093): ivtv: reorganized and cleanup ivtv struct V4L/DVB (6094): ivtv: more ivtv-driver.h cleanups V4L/DVB (6096): ivtv: fix V4L2_ENC_CMD_STOP_AT_GOP_END support V4L/DVB (6097): ivtv: set correct pixel format and alpha properties V4L/DVB (6108): videodev2.h: add new pixel formats for the cx23415 OSD V4L/DVB (6109): ivtv: use new videodev2.h pixel formats V4L/DVB (6112): cx25840: use a workqueue to load the firmware V4L/DVB (6113): ivtv: udelay for the i2c bus was set too high V4L/DVB (6115): ivtv/ivtv-fb: improve locking to avoid initialization problems V4L/DVB (6116): ivtv: VBI cleanups and fixes V4L/DVB (6117): ivtv: finish VBI related cleanup V4L/DVB (6118): ivtv-fb: add missing FBIO_WAITFORVSYNC ioctl define V4L/DVB (6119): ivtvfb: renamed ivtv-fb to ivtvfb, move header to include/linux V4L/DVB (6120): ivtvfb: rename some missed ivtv-fb references to ivtvfb V4L/DVB (6121): ivtvfb: replace ivtv_fb prefix to ivtvfb V4L/DVB (6123): ivtv: move ivtv.h public header to include/linux Hans-J
From: Linus Torvalds <torvalds@...> Subject: Re: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24 Date: Oct 10, 7:42 pm 2007 On Thu, 11 Oct 2007, Markus Rechberger wrote: > > the chances of the em28xx are not accepted from my side since the latest code > which supports way more hardware is offtree for various reasons. Well, I've talked to various people, and none of the main kernel people end up being at all interested in a kernel that has external dependencies on binary blobs for tuners. So right now it seems like while I would personally want to have more vendors supprt their own drivers, if that in this case means that we'd have to have user-space and unmaintainable binaries to tune the cards, everybody seems to hate that idea. As such, the old and decrepit em28xx driver seems more useful to people, since at least it supports the limited set of hardware on its own. Linus -
From: Markus Rechberger <mrechberger@...> Subject: Re: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24 Date: Oct 11, 12:50 am 2007 On 10/11/07, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > > On Thu, 11 Oct 2007, Markus Rechberger wrote: > > > > the chances of the em28xx are not accepted from my side since the latest > code > > which supports way more hardware is offtree for various reasons. > > Well, I've talked to various people, and none of the main kernel people > end up being at all interested in a kernel that has external dependencies > on binary blobs for tuners. > the drivers are all opensource and the code is available. > So right now it seems like while I would personally want to have more > vendors supprt their own drivers, if that in this case means that we'd > have to have user-space and unmaintainable binaries to tune the cards, > everybody seems to hate that idea. > For me the reason is that some drivers in the kernel which that driver depends on are broken now. Those drivers got broken by several people who disagree with me. My conclusion after providing patches to fix those things is that I won't run after those people anymore. I'm not going to have further discussions with those people about it since there are enough other outstanding things to do with that driver. After 1 1/2 years I'm just fed up with it now and I want to continue to improve the driver. > As such, the old and decrepit em28xx driver seems more useful to people, > since at least it supports the limited set of hardware on its own. it does not since it's broken and feature limited. On the other side it requires a firmware from userspace too so I don't think it matters at all if the algorithm is done in kernelspace or userspace since it depends on such a blob (and I cannot get the source for that firmware, if someone's interested in that he has to disassemble the firmware). Markus -
From: Aurelien Jarno <aurelien@...> Subject: Re: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24 Date: Oct 11, 2:08 am 2007 Markus Rechberger a écrit : > On 10/11/07, Linus Torvalds <torvalds@linux-foundation.org> wrote: >> As such, the old and decrepit em28xx driver seems more useful to people, >> since at least it supports the limited set of hardware on its own. > > it does not since it's broken and feature limited. On the other side I have a device which works perfectly with it if you add the vendor and product ID to the list. I don't really call that broken. And it doesn't need a firmware. Please think that a lot of persons do not have enough knowledge to compile out of tree drivers, and that a lot more do not even know about this out of tree driver. > it requires a firmware from userspace too so I don't think it matters > at all if the algorithm is done in kernelspace or userspace since it > depends on such a blob (and I cannot get the source for that firmware, > if someone's interested in that he has to disassemble the firmware). > -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' aurel32@debian.org | aurelien@aurel32.net `- people.debian.org/~aurel32 | www.aurel32.net -
From: Markus Rechberger <mrechberger@...> Subject: Re: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24 Date: Oct 11, 2:31 am 2007 On 10/11/07, Aurelien Jarno <aurelien@aurel32.net> wrote: > Markus Rechberger a écrit : > > On 10/11/07, Linus Torvalds <torvalds@linux-foundation.org> wrote: > >> As such, the old and decrepit em28xx driver seems more useful to people, > >> since at least it supports the limited set of hardware on its own. > > > > it does not since it's broken and feature limited. On the other side > > I have a device which works perfectly with it if you add the vendor and > product ID to the list. I don't really call that broken. And it doesn't > need a firmware. > Aurelien, the device you're using is around 2 years old. You're one of the lucky ones, I have tonns of support mails in my mail account from people who own almost a similar device but with different videodecoders which are not fully supported in the kernel or which worked and got broken during the time. It took me around 4 hours to debug such an issue last years remotly with an enduser (which includes that noone cared to ask me if I'm fine with such an update, neither did someone ask people who own such devices that they should test the changes). Please also take other devices and upcoming devices into account, since i'm willing to spend that time and since I'm in contact with various companies who provide several components of those devices. > Please think that a lot of persons do not have enough knowledge to > compile out of tree drivers, and that a lot more do not even know about > this out of tree driver. > this is what all is about, the project does not depend on certain broken drivers anymore. And people who initially disagreed without having any solution nor contributed any code can continue to play their game without having an impact on that driver anymore. Markus -
From: Andrew Morton <akpm@...> Subject: Re: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24 Date: Oct 10, 7:36 pm 2007 On Thu, 11 Oct 2007 01:00:39 +0200 "Markus Rechberger" <mrechberger@gmail.com> wrote: Please don't send 900 line emails to which you have added only an additional paragraph. > > drivers/media/video/em28xx/em28xx-core.c | 1 - > > drivers/media/video/em28xx/em28xx-input.c | 1 - > > drivers/media/video/em28xx/em28xx-video.c | 6 +- > > not accepted Until your attempt to get the userspace-driver work merged into the kernel is successful (and from my reading of last month's discussion it is nowhere near that), we should continue to maintain the present driver. If you choose to not participate in that maintenance then others will need to do their best in this regard. What we should not and will not do is to permit the current driver to be held hostage to your attempt to force a controversial and apparently unwelcome change into the tree. -
From: Markus Rechberger <mrechberger@...> Subject: Re: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24 Date: Oct 11, 1:09 am 2007 On 10/11/07, Andrew Morton <akpm@linux-foundation.org> wrote: > On Thu, 11 Oct 2007 01:00:39 +0200 > "Markus Rechberger" <mrechberger@gmail.com> wrote: > > Please don't send 900 line emails to which you have added only an additional > paragraph. > > > > drivers/media/video/em28xx/em28xx-core.c | 1 - > > > drivers/media/video/em28xx/em28xx-input.c | 1 - > > > drivers/media/video/em28xx/em28xx-video.c | 6 +- > > > > not accepted > > Until your attempt to get the userspace-driver work merged into the kernel > is successful (and from my reading of last month's discussion it is nowhere > near that), we should continue to maintain the present driver. > > If you choose to not participate in that maintenance then others will need > to do their best in this regard. > > What we should not and will not do is to permit the current driver to be > held hostage to your attempt to force a controversial and apparently > unwelcome change into the tree. > It makes no sense to keep the kernel driver uptodate, it would make more sense to support the latest driver (which some people are supporting). I just had a look at the driver downloads it makes around 600 downloads for september for this driver. If someone's interested in those stats I can give access to it privatly. The current option for people who own such a device is to take the driver from mcentral.de. Markus -
From: Andrew Morton <akpm@...> Subject: Re: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24 Date: Oct 11, 1:32 am 2007 On Thu, 11 Oct 2007 07:09:47 +0200 "Markus Rechberger" <mrechberger@gmail.com> wrote: > On 10/11/07, Andrew Morton <akpm@linux-foundation.org> wrote: > > On Thu, 11 Oct 2007 01:00:39 +0200 > > "Markus Rechberger" <mrechberger@gmail.com> wrote: > > > > Please don't send 900 line emails to which you have added only an additional > > paragraph. > > > > > > drivers/media/video/em28xx/em28xx-core.c | 1 - > > > > drivers/media/video/em28xx/em28xx-input.c | 1 - > > > > drivers/media/video/em28xx/em28xx-video.c | 6 +- > > > > > > not accepted > > > > Until your attempt to get the userspace-driver work merged into the kernel > > is successful (and from my reading of last month's discussion it is nowhere > > near that), we should continue to maintain the present driver. > > > > If you choose to not participate in that maintenance then others will need > > to do their best in this regard. > > > > What we should not and will not do is to permit the current driver to be > > held hostage to your attempt to force a controversial and apparently > > unwelcome change into the tree. > > > > It makes no sense to keep the kernel driver uptodate, It makes heaps of sense to keep the in-tree driver up to date if the out-of-tree driver is unmergeable, which appears to be the case. > it would make > more sense to support the latest driver (which some people are > supporting). But that ignores all of last month's discussion and the various reservations which various people have expressed. Please take my advise, based upon my experience in kernel development: I don't expect that we'll be merging the mcentral.de driver in anything like its present form. So we must continue to maintain and evolve the kernel.org driver. > I just had a look at the driver downloads it makes around 600 > downloads for september for this driver. If someone's interested in > those stats I can give access to it privatly. > The current option for people who own such a device is to take the > driver from mcentral.de. Well that's a shame. But we have n,000 drivers in-tree which work OK without doing unusual and disturbing user/kernel splits. -
I've been using Markus' user
I've been using Markus' user space tuner perfectly and he's the only one I know working on this tuner (Xceive), so kernel maintainers are losing a great piece of work. So if "everybody seems to hate the idea" as Linus stated, I think that stay trapped in kernel space is a mistake because of the slow development and lack of interest. I mean, for years we've been waiting for a good cx88 support and now the Xceive tuner support. It can't be trown away this way.
Linux is taking a risk to not support a good set of devices because of these decisions. And hardware will be obsolete and nobody will cares... and Linux will stay where it's now... :(
Creative in a straight jacket
I am sure Linus has to reject a lot of working but wacky contributions. Part of contributing to the Linux kernel is using the existing device model. Richard Feynman once said, "Doing Physics is like being creative in a straight jacket." The same might also be said of device driver development.
"Richard Feynman once said,
"Richard Feynman once said, "Doing Physics is like being creative in a straight jacket." The same might also be said of device driver development."
This comparison is bad, because MANY revelations and insights happened because people did not think straight, but instead thought in new ways (lateral thinking) and applied these ideas, and tested them.
So just because one comparison is true for one case, this is no law.
And I think Linus should place a LOT of extra care for these things, Video Watching is _ONE_ great area where Linus really outshines windows!
Go use Windows...!
If you want insecure, non-maintainable, non-free, non-OSS, BLOBs and that type of software, then go use Windows or some other OS that's not free - it's really that simple! I hope that Linus follows OpenBSD's Theo de Raadt way of remaining Open Source.
None of the drivers which
None of the drivers which are in question are binary drivers. The drivers when compiled will contain the firmware that's all.
The code all together is around 15000 lines now, it's alot work.
An inkernel solution was provided earlier but it got denied without serious reasons. There's an email which claimed that I wrote that I won't allow any changes after the code is in .. this is absolutly bogus... I'm just waiting for more bogus comments just to protect several drivers which have been broken by the maintainer himself and which affect those em28xx drivers.
Markus
The reason your previous
The reason your previous solution got blocked was the fact that it made changes to unrelated code which couldn't easily be separated from it and which you weren't willing to attempt to separate. The discussion is at http://linuxtv.org/pipermail/linux-dvb/2007-May/018011.html for anyone who's interested - the diffstat shows the issue. The patchset appears to touch every DVB-T frontend and most or all of the drivers for digital cards.
The tuner driver in question
The tuner driver in question was implemented in various other drivers too. Most changes are a few liners and nothing else. If the i2c framework gets changed all drivers who use it have to be adapted too. Beside that the inkernel API is not supposed to be stable.
It's around 80 additional PCI and USB devices which are not supported due the problems.
At that stage there are also patches to fix bugs in several drivers which are now still not fixed in the mainline repository. Those drivers are pulled to userspace now and fixed in userspace.
The latest diffstat looks like following:
Kconfig | 2
Makefile | 2
userspace/Kconfig | 8
userspace/Makefile | 3
userspace/media-stub.c | 2166 ++++++++++++++++++++++++++++++++++++++++
userspace/media-stub.h | 503 +++++++++
video/em28xx/Kconfig | 28
video/em28xx/Makefile | 8
video/em28xx/em2880-dvb.c | 909 ++++++++++++++++
video/em28xx/em28xx-audio.c | 439 ++++++++
video/em28xx/em28xx-cards.c | 2038 ++++++++++++++++++++++++++++++++++++-
video/em28xx/em28xx-core.c | 805 +++++++++++---
video/em28xx/em28xx-i2c.c | 371 ++++++
video/em28xx/em28xx-input.c | 171 ++-
video/em28xx/em28xx-keymaps.c | 211 +++
video/em28xx/em28xx-keymaps.h | 15
video/em28xx/em28xx-video.c | 2270 +++++++++++++++++++++++++++++++++---------
video/em28xx/em28xx-webcam.c | 365 ++++++
video/em28xx/em28xx.h | 550 ++++++++--
19 files changed, 10022 insertions(+), 842 deletions(-)
Many of these blobs are for
Many of these blobs are for firmware that runs on the chips themselves to handle decoding the ATSC, QAM or other encoding and to perform things like filter out reflections and whatnot. Many companies will not give out that code and the card vendors themselves are unable to make the source code available. I have a pcHDTV card that requires this type of firmware.
I don't think it opens up any security holes, since these blobs do not run on the host processor.
More and more chips are designed this way, with processors and DSPs built into the chips. I recall Adaptec SCSI controllers requiring firmware for their chips, and I worked on an Ethernet controller that required firmware to enable the offloading features (i.e. packet parsing to figure out how to generate the checksums).
BLOBS like this will become more and more common, and there will be many cases where due to IP licensing, the source cannot be made available. For example, if Connexant bought a DSP core and firmware from a 3rd party for their chip then even they cannot release it. This happens more and more in the hardware world. For example, nVidia could not release details on their earlier nForce RAID/IDE support because they bought the internal logic for that from another company that wouldn't open it up.
Even my Epson scanner, which works well in Linux, requires that a BLOB be downloaded to it before it will operate.
If the hardware works with a certain BLOB, it will continue to work with that BLOB. The manufacturer may release later updates which improve functionality (which has happened with my pcHDTV card). It's separate from the OS so it should not matter.
"It's separate from the OS
"It's separate from the OS so it should not matter."
I agree totally.
I hope Linus reconsiders his position too.
The BLOB firmware model SUCKS
Any piece of hardware that requires you to D/L firmware EVERY GODDAMN TIME YOU WANT TO USE IT is broken by design.
That's what EEPROMs are for. That just means you have cheap-shit cut-rate hardware.
> Even my Epson scanner, which works well in Linux, requires that a BLOB be downloaded to it before it will operate.
Yeah, I have one of these pieces of shit too, and I have to wait 30 seconds for the download every time I turn it on. And if the download has a timing issue or something, the scanner shits the bed and has to be power cycled.
And I have to turn it on by plugging it in because not only was Epson too cheap to include an EEPROM, they were too cheap to include a POWER SWITCH, for god's sake.
You don't have to take this crap. Vote with your wallet. Last week I returned a Bluetooth keyboard that was DRM-locked to only two devices. If I wanted to connect to a 3rd device, I had to pay extra! And the best joke of all, it was called "The FREEDOM Universal keyboard"
Obviously you have not had
Obviously you have not had to deal with hardware design or have to provide updated firmware in the field. EEPROM can adds a noticeable expense. Also, by requiring eeprom it means that you have to write software to program that eeprom whenever the firmware is updated. Why add eeprom when the driver can just download it? Your statements make little sense.
I have also worked with chips where the firmware size is measured in megabytes and is also often updated with driver updates. Do you want to write a tool to keep programming the eeprom, or have to require the driver to check the onboard firmware version and program a new version when the driver is updated? You're back to the same thing now.
I also found the time to download the firmware to my scanner is minimal, since it happens as soon as I plug it in or power it on.
One other problem with
One other problem with requiring that a driver program the eeprom (or the user runs a program that does that) is that if it should fail you can basically brick the device. If there's a power failure at the wrong time, or the OS crashes, or the user kills the process (which might take a long time) then the device could be hosed. And storing two copies is not easy either. It's much easier to have a minimal firmware on the device and have it load the new firmware at runtime. That way, new features can be added with a new driver, or bugs can be fixed.
Also, some chips are not designed to load their firmware from an EEPROM and have the basic initialization code on the chip itself.
Re: Obviously you have not had
This is a good argument for exposing more of the foibles of the hardware to the OS driver. If you have to update the multi megabyte firmware every time you update the driver, then the driver should take some of the functionality of the firmware to reduce the complexity and maintenance required of it.
Arguably this should be the first thing you do when you start writing a firmware. Being able to update it in the field should be an essential part of managing the device.
Checking the version should be an essential part of loading and ensuring that the device is working properly. Having a simple version field allows you to automatically replace old, buggy firmwares with newer, better versions, and should the firmware API change for whatever reason, the driver will not innocently mangle the hardware.
IMHO, the firmware should be a simple piece of software doing nothing more than smoothing over some of the wrinkles of the hardware and providing a consistent, sensible interface. It should not run the entire show - that is the job of the host operating system and driver. If you need megabytes of firmware to do this, then the hardware probably should be re-designed.
You obviously have never
You obviously have never worked with real hardware or with hardware design.
Firmware is not always simple. I have worked on some pretty big projects where the networking chip that does routing, shaping, bridging, ACLs, policing, tunneling and a lot of other things, all on chip. The firmware is anything but trivial and there's no way to squeeze that functionality into a small size. Sure, it could all be done in an ASIC, but the design of that ASIC would be very expensive, and if a new feature is added later it means redesigning the ASIC, which often costs millions of dollars to do. If I can just modify the firmware and the driver to add a new feature, it's a hell of a lot faster and less expensive. Updating an ASIC can take many months, and even updating an FPGA can be quite time consuming, whereas updating the firmware and debugging that can be done in a matter of hours.
As devices add more and more features, it makes more sense to make it programmable and either embed a CPU core inside (like an ARM), or some other custom state machine or DSP. The code for these is often not trivial, for example there is a lot of DSP code involved in a voice card just to do echo cancellation or detecting various signals.
Why add EEPROM and require the driver to program it each time if you can load the firmware just as fast (or faster, since serial EEPROM can be slow).
As far as the tuner cards are concerned, there is a fair amount of DSP code in the BLOB for decoding ATSC, QAM, etc. which can be quite complicated, especially when trying to filter out multipath reflections or deal with equalization or interference. With my tuner card, for example, there have been numerous releases of the firmware where later versions have added new functionality such as QAM256 and improved reception. If this were hardwired into the chip, I'd be screwed.
I do not even believe the tuner chip is capable of having the firmware in EEPROM, and adding an eeprom for it to boot is pointless and just an added expense and complication. Why make the driver have to validate and program eeprom each time, when it is often simpler and faster to just load the firmware from the driver itself. Then you don't have to worry about eeprom going bad or bricking the hardware should the power go out in the middle of programming the EEPROM. Also, having the driver verify the EEPROM would take just as much, if not more time, than just uploading the firmware directly, especially with devices on the PCI bus.
I have dealt with some very complex devices. Some devices have simple firmware, others do not. If you only want simple firmware then buy only simple devices.
It's advantageous for hardware vendors to use downloadable firmware for that device. It allows for easy bug fixes with only a driver and/or blob update, it makes board layout simpler and cheaper, and saves in testing time.
You have not provided any valid argument as to why the firmware should be stored in EEPROM. The firmware is not part of the Linux kernel. It does not run on Linux, and hence there is no reason why it should be put in ROM. Furthermore, there are many cases where even if a vendor wanted to, they can't release the code that runs on the device because they have signed NDAs with the chip vendors, and even if they could provide the firmware, the tools to compile it are often not free and not trivial, such as DSP compilers.
Also, from experience, allowing customers in the field to update firmware is often problematic and can result in a bricked device if it isn't done right. If the power goes out and the firmware is more than just a loader for the real firmware, then your device is toast.
Devices have been using downloadable firmware for years. I recall old SCSI controllers supporting that, and I worked on an Ethernet card years ago that used this. Since it was mass produced and board space was at a premium, it was just easier to just upload a 2K blob for a programmable state machine to provide IPv4 and IPv6 checksum support. As it was, in the rush to get it out not all of the features worked in the first release, but a firmware update with the new driver enabled all of the functionality in a later release.
I think you missed the point.
I think the point was "Just tell us how the hardware works, and we'll code all those features ourself as part of the PC's OS."
You're still in the most of "hardware + firmware provides all the features at a high level to a host."
--
Program Intellivision and play Space Patrol!
who are we? there have been
who are we?
there have been previous attempts to get the driver which is in question in the code didn't get accepted for no real reason which would have enlightened people what's overall wrong with it, additionally RFCs are not answered properly and the comments which were made didn't address any issues with it.
The current patch works around those people now by fully addressing many more requirements without having to strip off features of the actual driver components which are not supported by the inkernel API.
it has a long history (last 2 years) and is not just an attempt which got developed during last week
> it is often simpler and
> it is often simpler and faster to just load the firmware from the driver itself.
Which is no problem if you provide the source to your firmware, so my driver isn't a BLOB.
But you won't. However, if you're going to put it in MY OS, it's not going to be a indecipherable untrustworthy binary pile.
> The firmware is not part of the Linux kernel. It does not run on Linux
Yes, it's part of the kernel if it's in an in-tree driver. And yes, I've seen wireless drivers where the bluetooth support was a binary BLOB that ran in the host OS. NO THANKS.
(I remember those old crap ADAPTEC SCSI adapters. Those were so horrible my company finally declared ADAPTEC products verboten. Holy crap. Not even ADAPTEC could keep track of the firmware revisions.)
source to your firmware
>> it is often simpler and faster to just load the firmware from the driver itself.
>Which is no problem if you provide the source to your firmware
Even having firmware source would solve nothing. Chip vendors use hardware for which no free compiler exists. So it could make Linux kernel dependent on closed, expensive 3rd party tools.
This is my experience from 3 year work on firmware (just the compiler itself costs Eur 5000 and it is even not sold to public).
> EEPROM can adds a
> EEPROM can adds a noticeable expense.
So you admit you're designing cheap shit.
> Also, by requiring eeprom it means that you have to write software to program that eeprom whenever the firmware is updated.
Oh darn. I do admit it's a pain to find a Windows box so I can run whatever brain damaged firmware upgrade utility, but I only do it once in a blue moon.
> Why add eeprom when the driver can just download it?
Because then people don't publish the source to their drivers. Which means I can't use their product with an open-source OS. Which means I can't buy their product.
If you're going to go the cheap route, then you need to provide the firmware source.
> I also found the time to download the firmware to my scanner is minimal, since it happens as soon as I plug it in or power it on.
Me too. When it works. But the other 25% of the time, I'm going "what the fuck is wrong with my scanner? I'm never buying an Epson product again!"
As opposed to my Xerox scanner which JUST WORKS because it doesn't screw around with that crap.
> So you admit you're
> So you admit you're designing cheap shit.
It would be a stupid business decision to add a lot of extra expense to a product just to satisfy a couple hard-nosed GPL fanatics, when adding the extra hardware can end up costing many thousands of dollars, since the manufacturing process now requires an extra step to program and test the flash, plus the expense of designing it into the board, writing the software to program it and adding it to the testplan. If a business wants to remain competitive, they will cut costs.
> Oh darn. I do admit it's a pain to find a Windows box so I can run whatever brain damaged firmware upgrade utility, but I only do it once in a blue moon.
Why not make it so you don't have to do it at all? If there's a bug in the current firmware, you don't want to ask all of your customers to run a program to reflash the device to fix it, since lets face it, a lot of users will get confused, or if it takes a long time to do (which can be the case), they just kill the task or turn the machine off and brick the device. Most users just want to plug a device in and have it work. Installation needs to be as simple as possible and require as few steps as possible.
> Because then people don't publish the source to their drivers. Which means I can't use their product with an open-source OS. Which means I can't buy their product.
That isn't a good reason. As I said, often the manufacturers can't publish the source or may not even have the source. And losing one customer because they didn't spend the thousands of dollars necessary to add the flash/eeprom is a good tradeoff. I've also worked on some where the binary doesn't really even have source, but was hand-crafted for that state machine.
> If you're going to go the cheap route, then you need to provide the firmware source.
No you don't, since it often won't do any good, and there is a high probability the source will be tied up with NDAs if it is even available at all, and even if it's available, it won't help without the tools to compile it, since GCC is likely not going to compile it, but some DSP compiler where the SDK costs many thousands of dollars with header files and whatnot that cannot be redistributed.
> Me too. When it works. But the other 25% of the time, I'm going "what the fuck is wrong with my scanner? I'm never buying an Epson product again!"
As opposed to my Xerox scanner which JUST WORKS because it doesn't screw around with that crap.
It sounds like you have a bad distro or your hotplug configuration is broken, or you just bought a really crappy scanner.
Also, lets face it, most hardware vendors could care less about Linux since it's a tiny fraction of their sales. By whining that they must make all the blob source available, you won't get very far.
In addition, different hardware vendors may use the same hardware but optimize their firmware differently to differentiate themselves, and you can be sure that they will not release their binary source.
I guess you should avoid RAID controllers, since any decent raid controller runs on-board closed-source firmware and might corrupt your data since you can't see the source, blob or flash based.
You should not use your keyboard, since the embedded keyboard controller in your PC (used to be an 8042 microcontroller) and controller inside the keyboard both run closed-source firmware and could steal your password.
Your mouse's firmware is closed source... must avoid it or it might broadcast all your mouse movements to the NSA.
Your BIOS firmware is probably closed source... I guess that should be avoided too.
Blob or not makes no difference. Your arguments are just plain silly.
+1 Linux needs to work with
+1
Linux needs to work with more hardware for more people, not less - blobs or no blobs (as long as they don't need to run in the host's cpu)
Redistribution license
The biggest issue I've heard others raise is the redistribution terms on blobs.
If the blob provider says "Redistribute it however much you like, yadda yadda, just as long as you acknowledge our copyright and don't change the contents" (kinda like the terms on many FSF text releases), I think many free software advocates wouldn't mind them so much. At that point it's little different from handing out ROM chips, except it's way less expensive and quite a bit faster.
But, the fact that the redistribution of the blob has restrictions is what tweaks many people.
Really, whether there's flash on the device or not, you still have to get a blob into the device to make it work. I can't think of any manufacturer that wants to, say, document how to program the stepper motor on a scanner to allow us to write our own scanner stack all the way down to the image sensor level, and I don't think anyone in the community wants to take on that problem anyway. They just want to scan photos of Junior for Aunt Millie. Whether the kernel loads the blob at boot time, or someone flashes a blob onto it at manufacturing time is a detail. Either way, the scanner is a black box with a standard interface.
The issue is, the terms on the blob typically limit redistribution. If the hardware is at all sane, it'll checksum and validate blobs and only accept "correct" blobs. That's what CPU microcode patches (which *are* blobs) do. They're effectively encrypted and signed so that only official blobs get loaded. If blob-makers took that step, they could say "Copy all you want, we don't care," and not worry too much that people are loading tweaked blobs onto their products.
I see it as being little different than a spec sheet that says "Write this sequence of numbers into these registers in this order to initialize the device." It just happens to be a longish sequence of writes.
How many of you have the source to the firmware on your HD? How many *want* that source? Why is the answer different for WiFi cards and scanners then?
--
Program Intellivision and play Space Patrol!
Hard Drive Firmware Also a Can of Worms
Who says you shouldn't care about your hard drive firmware? That can be problematic too!
I completely agree with this
I completely agree with this post. I also have quite a lot of experience with DVB hardware and software design and whether the purists like it or not, firmware BLOBs are a fact of life and are used for good reasons. For example, as was stated before many DVB-T tuners include DSP processors that handle much of the decoding, and improvements or new features, or even market-specific features are often implemented in firmware. Like it or not there may also be IPR reasons for not releasing firmware (and driver) source, not under the control of the manufacturer. We may not like it but that's the way of the world.
My company does a lot of DVB development on Linux. One of the reasons for this is because the hardware and driver support for DVB cards (both those with and without firmware BLOBs) is much better than in Linux than Windows. Most DVB cards work out of the box with Linux, apart from copying the firmware into the appropriate directory. Advanced features such as IP datacast are available using commodity hardware. If this changes and considerable hacking becomes necessary to use drivers, the arguments for using Linux become much weaker.
I understand why binary drivers and firmware blobs are unpopular with kernel developers and share many of the concerns. However I think there is little understanding of the business, commercial and legal reasons why this is sometimes necessary. I'm always disappointed at the abuse NVidia get despite their excellent support for Linux over the years and the fact that there are legal reasons meaning that they can't release their source code. The kernel DRM mechanism restricting the interfaces binary drivers can use holds Linux back in my organisation and I suspect in many others. I use the term DRM carefully; I'm not arguing that the individuals who choose to restrict access to those interfaces are acting outside their legal rights. I am arguing that their choice is not in Linux best interests.
The firmware of one of the
The firmware of one of the devices in question is a blob, but that's not the issue. The issue is that, if this gets merged, many of the drivers themselves will end up being blobs using a more extreme version of the method used by the Intel wireless blob - a daemon communicating with an in-kernel stub, with all the actual code in the daemon.
So there's no solution
So you think it's better to not having any support at all than to have at least some support? I mean, for instance, I have to use the closed-source nvidia proprietary binary driver. It's not the ideal, but it works. Are you saying that I shouldn't use it because it's binary and stick with the lack of support?
I think that a binary driver is better than no support at all. It's not ideal, but what in this world is ideal?
Don't use
Yes, don't use it. It will compromise your system, because it's in the kernel and can do anything. And there's no one who can review the sources. If you want to have secure and stable software, then it is impossible to use blobs.
Having no support is better than a blob.
Don't buy it...
> Having no support is better than a blob.
I agree, which is why I don't own an nVidia or ATI product.
You're limited
If you don't have a nvidia or ATI product, you surely are limited by not using the best video cards out there or you just need a simple 2D desktop... I like to play games and I like compiz fusion too, which makes me more productive (compiz fusion is a lot better than all window managers out there... there's a lot of possiblities with a composite window manager).
Saying "Having no support is better than a blob" is absurd... This way Linux will always be a "second place OS". People keep discussing if Linux is ready or not for the desktop and if Linux doesn't support devices, it won't be ready for those users who need this support.
Of course we all prefer a good GPL code, but if in the meantime it's not possible, let's use what at least exists *now*.
no!
Sorry, but I totally disagree. It is better to have a stable and secure system than a beautiful compromised system. If not, Linux would not be any better than Windows.
What does "ready for the desktop" mean in your opinion? Mostly, it is understood as adopting the Windows philosophy of how users interact with the system. This sucks.
If Linux honestly wants to be better, then it must not make a compromise to support manufacturers that care a shit about the GPL philosophy. They only provide blobs to be able to claim to support Linux. But they don't, they abuse it.
Ok
Ok, I, as you, like free software philosophy etc, but the problem is: how much time does it will take so companies decide to open their specs or code? If it would take years or decades, maybe I'll be dead when this happen and then it won't make sense since I would not be here anymore...
Of course, I hate those companies, but what can I do? I'm a victim of all this. There's no alternative to nvidia/ATI for example... even for software, I'm waiting many years for Sun to release a 64 bit Java plugin... and Adobe release a 64 bit flash plugin... I'm a victim of those companies...
To sum up: I can follow their rules or not. If not, I won't be able to view most of the content I want... so what's the meaning of using Linux, in the end? It's supposed to be an alternative operating system and should do the best it can to support many devices as possible. If not it will be useless for some purposes... and its adoption will be even slower...
now pull out your CPU which
now pull out your CPU which uses microcode for fixing some hardware bugs.
The drivers themself are opensource and drivers who are developed with that userspace framework have to be opensource unless someone rewrites the GPL code there.
It has been pointed out that it's possible to publish binary drivers using usbfs directly in userspace. usbfs is part of the kernel. UIO (userspace IO) as well.
BSD does tuning in userspace. And sample drivers can easily be reused with that mechanism.
Now stating out that there are drivers which have around 20.000-30.000 lines of code, I guess people would love to debug inkernel crashes instead of segfaulting drivers in userspace which keep the system consistent.
As for such large drivers, simply using the API of those drivers will decrease a hugh amount of time for the implementation as well.
Alot newer more advanced silicons use a firmware nowadays. In case of the tuner advanced calculations are done with that firmware on the device and that firmware has to be changed for DVB, analogue TV and radio (someone might have a look at the gnu radio project if further interested in software demodulation).
As for better hardware of course everyone is free to buy firmwareless devices but why do so many people choose devices for 50 bucks instead of the gold revision for 350 bucks... it's clear most customers are looking for the cheapest solutions.
"it's clear most customers
"it's clear most customers are looking for the cheapest solutions."
You get what you pay for. If using Linux means not being an idiot... Well... So be it.
Oh, but yes
I do (but I'm not the same poster as above).
We should not have hardware listed as "supported" under Linux if it isn't well supported, and binary blobs have a tendency to work less and less well over time.
If a user buys hardware that is listed as working under Linux and have these issues then that detracts from the value of the Linux platform for everyone.
There are lots and lots of hardware that's not supported under Linux and a few cards more or less isn't terribly important. You can't buy hardware that's not compatible with your computer and inconvenience other people to fix that. After all, Linux today supports more hardware than Windows does in total (although a lot of exotic platforms and historic stuff), and we want to keep it that way by having proper support and not half-baked.
Xceive
fraga@tux ~/src$ grep Xceive /usr/src/linux/Documentation/video4linux/CARDLIST.tuner
tuner=71 - Xceive xc3028
But the Xceive xc3028 support doesn't exist in the kernel... So let's just remove this entry because this tuner isn't supported...
How does that relate to the
How does that relate to the parent post?
"So you think it's better to
"So you think it's better to not having any support at all than to have at least some support?"
There are other DVB devices that already work great with the current kernel, no binary drivers, sometimes even no firmware. With video cards the situation is not exactly similar, since the Intel stuff isn't yet as fast as the nVidia cards with binary drivers.
People can always buy DVB devices with free kernelspace drivers and leave these em28xx devices for the Windows users. More binary userspace drivers would be bad for Linux, IMO Linus made the right decision here.
I'd rather take that risk
I'd rather take that risk than taking the risk of becoming dependent on proprietary software (which usually means becoming dependent on a specific vendor).
Xceive
I want to see how many years V4L is going to take to support Xceive tuners since they rejected Markus' work... I talked to Markus today and he will keep developing the user space tuner. Linux loses. BSD gains.