Hello
http://reel-multimedia.com/rmm-english/netceiver.html here's a good platform for future hdtv-vdr Are you agree ? :)
Igor
On 27 Jun 2007, at 20:51, Igor wrote:
Hello
http://reel-multimedia.com/rmm-english/netceiver.html here's a good platform for future hdtv-vdr Are you agree ? :)
Well, what's missing there is info about the "1x extra PCI slot for HD-Decoder-Card". Having a PCI decoder for mpeg2/4/h.264 would be fine, unles it's actually a mini-pci card that only works with reels netceiver external tuner hardware.
-- Torgeir Veimo torgeir@pobox.com
On Wed, Jun 27, 2007 at 09:17:03PM +0100, Torgeir Veimo wrote:
On 27 Jun 2007, at 20:51, Igor wrote:
Hello
http://reel-multimedia.com/rmm-english/netceiver.html here's a good platform for future hdtv-vdr Are you agree ? :)
Well, what's missing there is info about the "1x extra PCI slot for HD-Decoder-Card". Having a PCI decoder for mpeg2/4/h.264 would be fine, unles it's actually a mini-pci card that only works with reels netceiver external tuner hardware.
The HDTV decoder card in PCI format will be first used for the Reelbox Avantgarde (based on a Mini-ITX-PC). The usage in the NetCeiver itself in a PC-less combo is planned, but I don't think a vdr can run on that platform without serious restrictions. For example, the NetCeiver with its current firmware has no real DVB-API, as the CPU has nothing to do with the TS streaming, it only controls the tuners. The rest (filtering and network encapsulation) is done in the hardware. So it will be more a small STB application without bells and whistles,.
But the chances are high that the HD card (running with the Micronas DeCypher) will be seperately available. As the Reelbox uses vdr, Linux drivers for the HD card and the NetCeiver (a DVB-API emulation and a vdr plugin with more features) will be there from the start.
On 6/27/07, Georg Acher acher@in.tum.de wrote:
On Wed, Jun 27, 2007 at 09:17:03PM +0100, Torgeir Veimo wrote:
On 27 Jun 2007, at 20:51, Igor wrote:
Hello
http://reel-multimedia.com/rmm-english/netceiver.html here's a good platform for future hdtv-vdr Are you agree ? :)
Well, what's missing there is info about the "1x extra PCI slot for HD-Decoder-Card". Having a PCI decoder for mpeg2/4/h.264 would be fine, unles it's actually a mini-pci card that only works with reels netceiver external tuner hardware.
The HDTV decoder card in PCI format will be first used for the Reelbox Avantgarde (based on a Mini-ITX-PC). The usage in the NetCeiver itself in a PC-less combo is planned, but I don't think a vdr can run on that platform without serious restrictions. For example, the NetCeiver with its current firmware has no real DVB-API, as the CPU has nothing to do with the TS streaming, it only controls the tuners. The rest (filtering and network encapsulation) is done in the hardware. So it will be more a small STB application without bells and whistles,.
But the chances are high that the HD card (running with the Micronas DeCypher) will be seperately available. As the Reelbox uses vdr, Linux drivers for the HD card and the NetCeiver (a DVB-API emulation and a vdr plugin with more features) will be there from the start.
Is there any information regarding availability or pricing on the HDTV PCI card ? I have been waiting a long time for an HD MPEG-2/4 decoder with HDMI and this sounds promising :-)
Thanks, Brian
On Friday 29 June 2007 07:45, Jeremy Jones wrote:
On 6/27/07, Georg Acher acher@in.tum.de wrote:
On Wed, Jun 27, 2007 at 09:17:03PM +0100, Torgeir Veimo wrote:
On 27 Jun 2007, at 20:51, Igor wrote:
Hello
http://reel-multimedia.com/rmm-english/netceiver.html here's a good platform for future hdtv-vdr Are you agree ? :)
Well, what's missing there is info about the "1x extra PCI slot for HD-Decoder-Card". Having a PCI decoder for mpeg2/4/h.264 would be fine, unles it's actually a mini-pci card that only works with reels netceiver external tuner hardware.
The HDTV decoder card in PCI format will be first used for the Reelbox Avantgarde (based on a Mini-ITX-PC). The usage in the NetCeiver itself in a PC-less combo is planned, but I don't think a vdr can run on that platform without serious restrictions. For example, the NetCeiver with its current firmware has no real DVB-API, as the CPU has nothing to do with the TS streaming, it only controls the tuners. The rest (filtering and network encapsulation) is done in the hardware. So it will be more a small STB application without bells and whistles,.
But the chances are high that the HD card (running with the Micronas DeCypher) will be seperately available. As the Reelbox uses vdr, Linux drivers for the HD card and the NetCeiver (a DVB-API emulation and a vdr plugin with more features) will be there from the start.
Is there any information regarding availability or pricing on the HDTV PCI card ? I have been waiting a long time for an HD MPEG-2/4 decoder with HDMI and this sounds promising :-)
Thanks, Brian
See http://www.vdr-portal.de/board/thread.php?threadid=45922 . I'm waiting for it, but no info is available for some time. Maybe someone has any news?
Regards, Ales
On Thu, Jun 28, 2007 at 10:45:12PM -0700, Jeremy Jones wrote:
Is there any information regarding availability or pricing on the HDTV PCI card ? I have been waiting a long time for an HD MPEG-2/4 decoder with HDMI and this sounds promising :-)
Availability not earlier than August/September, the price isn't fixed yet.
On 29 Jun 2007, at 10:35, Georg Acher wrote:
On Thu, Jun 28, 2007 at 10:45:12PM -0700, Jeremy Jones wrote:
Is there any information regarding availability or pricing on the HDTV PCI card ? I have been waiting a long time for an HD MPEG-2/4 decoder with HDMI and this sounds promising :-)
Availability not earlier than August/September, the price isn't fixed yet.
There is other hardware that does mpeg2/4/h.264 decoding, the lacking piece is always proper open source drivers.
Will this hardware have open source drivers / open specifications?
On Fri, Jun 29, 2007 at 10:47:58AM +0100, Torgeir Veimo wrote:
There is other hardware that does mpeg2/4/h.264 decoding, the lacking piece is always proper open source drivers.
Will this hardware have open source drivers / open specifications?
With a few exceptions (eg the driver for the HDMI chip) it will be open source. Actually, there's a Linux running on the card...
On 29 Jun 2007, at 10:51, Georg Acher wrote:
With a few exceptions (eg the driver for the HDMI chip) it will be open source. Actually, there's a Linux running on the card...
Ok. Does the card have only HDMI output, or also other, eg. component or DVI? Would it be possible to use it without using the HDMI output in that case?
On 29 Jun 2007, at 10:51, Georg Acher wrote:
On Fri, Jun 29, 2007 at 10:47:58AM +0100, Torgeir Veimo wrote:
There is other hardware that does mpeg2/4/h.264 decoding, the lacking piece is always proper open source drivers.
Will this hardware have open source drivers / open specifications?
With a few exceptions (eg the driver for the HDMI chip) it will be open source. Actually, there's a Linux running on the card...
Is this the card in question? http://www.directupload.net/images/ 070503/CjsyApL2.jpg
On Fri, Jun 29, 2007 at 12:13:53PM +0100, Torgeir Veimo wrote:
Is this the card in question? http://www.directupload.net/images/070503/CjsyApL2.jpg
It is.
On 6/29/07, Torgeir Veimo torgeir@pobox.com wrote:
On 29 Jun 2007, at 10:35, Georg Acher wrote:
On Thu, Jun 28, 2007 at 10:45:12PM -0700, Jeremy Jones wrote:
Is there any information regarding availability or pricing on the HDTV PCI card ? I have been waiting a long time for an HD MPEG-2/4 decoder with HDMI and this sounds promising :-)
Availability not earlier than August/September, the price isn't fixed yet.
There is other hardware that does mpeg2/4/h.264 decoding, the lacking piece is always proper open source drivers.
Do you have any links/info for such cards ?
Will this hardware have open source drivers / open specifications?
I checked out the latest Reelbox testing svn code and browsed the code to see if it supports this device. I didn't look too thoroughly but it appears the reelbox-0.9.0 plugin does support it. It looks like communication to the kernel space driver is done through shared memory and I did see some kernel space code to create this shared memory device (/dev/hdshmem). I'm sure there is a closed source firmware or kernel module that is also used but since Reelbox is based on vdr this shouldn't be too much of a problem.
Brian
On Fri, Jun 29, 2007 at 08:21:45AM -0700, Jeremy Jones wrote:
I checked out the latest Reelbox testing svn code and browsed the code to see if it supports this device. I didn't look too thoroughly but it appears the reelbox-0.9.0 plugin does support it. It looks like communication to the kernel space driver is done through shared memory and I did see some kernel space code to create this shared memory device (/dev/hdshmem). I'm sure there is a closed source firmware or kernel module that is also used but since Reelbox is based on vdr this shouldn't be too much of a problem.
Actually there's not much closed source that affects the usage. On the PC side there's none, on the card side it's only the driver for the HDMI-chip in the kernel (otherwise Silicon Image would shoot us) and of course the firmwares for the internal audio/video-coprocessors (delivered by Micronas).
The Linux on the card is a busybox-based MIPS-Linux. In the card itself the video stuff is done over a modified V4L2. We choose not to expose this API into the PC, as it would require too much kernel hacking. Instead there's only the shared memory abstraction with very little kernel code and a FIFO-channel implementation on top of it. The video player just uses this comunication and streams raw TS over such a channel. As there is also a IP network connection over the shm, you can telnet into the card, mount NFS or stream directly from an application running on the MIPS (with a little overhead, but it's good enough for >5MB/s).
On 29 Jun 2007, at 17:24, Georg Acher wrote:
Actually there's not much closed source that affects the usage. On the PC side there's none, on the card side it's only the driver for the HDMI-chip in the kernel (otherwise Silicon Image would shoot us) and of course the firmwares for the internal audio/video-coprocessors (delivered by Micronas).
What's important for me (and I assume a lot of others), is that it decodes any potentially codec in use for dvb-s/c/t and hd-dvd/ bluetooth (mpeg2/4, h.264 and vc-1), and that it allows output in 480i/p, 720p, 1080i/p, both in 48fps, 50fps and 60fps. If it does all this and provides a judder free, tearing free picture, and can reclock it's output to match the input stream rate, then I'm pretty sure we have a winner at hand. And I would be glad to pay £200 for such a solution if it does all of the above and works with open source software.
I guess I have to wait to see what becomes available...
Georg Acher wrote:
On Fri, Jun 29, 2007 at 08:21:45AM -0700, Jeremy Jones wrote:
I checked out the latest Reelbox testing svn code and browsed the code to see if it supports this device. I didn't look too thoroughly but it appears the reelbox-0.9.0 plugin does support it. It looks like communication to the kernel space driver is done through shared memory and I did see some kernel space code to create this shared memory device (/dev/hdshmem). I'm sure there is a closed source firmware or kernel module that is also used but since Reelbox is based on vdr this shouldn't be too much of a problem.
Actually there's not much closed source that affects the usage. On the PC side there's none,
That is great :)
on the card side it's only the driver for the HDMI-chip in the kernel (otherwise Silicon Image would shoot us) and of course the firmwares for the internal audio/video-coprocessors (delivered by Micronas).
Well, dvb-ttpci microcode is completely closed, so it is no better in this regard. I don't think having non-free microcode is going to be a problem.
On Friday 29 June 2007 18:24, Georg Acher wrote:
On Fri, Jun 29, 2007 at 08:21:45AM -0700, Jeremy Jones wrote:
I checked out the latest Reelbox testing svn code and browsed the code to see if it supports this device. I didn't look too thoroughly but it appears the reelbox-0.9.0 plugin does support it. It looks like communication to the kernel space driver is done through shared memory and I did see some kernel space code to create this shared memory device (/dev/hdshmem). I'm sure there is a closed source firmware or kernel module that is also used but since Reelbox is based on vdr this shouldn't be too much of a problem.
Actually there's not much closed source that affects the usage. On the PC side there's none, on the card side it's only the driver for the HDMI-chip in the kernel
Damm, that's the nvidia way.
They decide on which kernel it runs. If I need for some other device a different kernel which they don't / won't support, I'm left alone.
To my opinion that is a nogo way. I doubt if that's compatible with GPL.
(otherwise Silicon Image would shoot us) and of course the firmwares for the internal audio/video-coprocessors (delivered by Micronas).
Stefan Lucke wrote:
On Friday 29 June 2007 18:24, Georg Acher wrote:
On Fri, Jun 29, 2007 at 08:21:45AM -0700, Jeremy Jones wrote:
I checked out the latest Reelbox testing svn code and browsed the code to see if it supports this device. I didn't look too thoroughly but it appears the reelbox-0.9.0 plugin does support it. It looks like communication to the kernel space driver is done through shared memory and I did see some kernel space code to create this shared memory device (/dev/hdshmem). I'm sure there is a closed source firmware or kernel module that is also used but since Reelbox is based on vdr this shouldn't be too much of a problem.
Actually there's not much closed source that affects the usage. On the PC side there's none, on the card side it's only the driver for the HDMI-chip in the kernel
Damm, that's the nvidia way.
They decide on which kernel it runs. If I need for some other device a different kernel which they don't / won't support, I'm left alone.
If I understood correctly, you only need proprietary parts for the kernel that runs *in* the card. The kernel running on your actual system does not need proprietary parts, leaving you free to use a different kernel.
To my opinion that is a nogo way. I doubt if that's compatible with GPL.
(otherwise Silicon Image would shoot us) and of course the firmwares for the internal audio/video-coprocessors (delivered by Micronas).
On 30 Jun 2007, at 12:17, Anssi Hannula wrote:
If I understood correctly, you only need proprietary parts for the kernel that runs *in* the card. The kernel running on your actual system does not need proprietary parts, leaving you free to use a different kernel.
The binary provision for drivers is a bit vague at best When some parts of the kernel becomes gpl3, which it might, distributing binary drivers for the kernel will no longer be allowed.
Sigma Designs work around this by having their binary parts running as user space programs.
I demand that Torgeir Veimo may or may not have written...
[snip]
When some parts of the kernel becomes gpl3, which it might,
That can't usefully happen so long as there are GPLv2-only components: there would be no common licence for the whole kernel, which would make it undistributable without splitting it up. Also, I don't believe that code which isn't licensed under GPLv2 will be accepted anyway...
[snip]
Anssi Hannula anssi.hannula@gmail.com wrote:
If I understood correctly, you only need proprietary parts for the kernel that runs *in* the card. The kernel running on your actual system does not need proprietary parts, leaving you free to use a different kernel.
yes, but as there is linux also running "on" the card the GPL applies there as well. what if i want to change that?
clemens
On Sat, Jun 30, 2007 at 01:29:23PM +0200, Clemens Kirchgatterer wrote:
Anssi Hannula anssi.hannula@gmail.com wrote:
If I understood correctly, you only need proprietary parts for the kernel that runs *in* the card. The kernel running on your actual system does not need proprietary parts, leaving you free to use a different kernel.
yes, but as there is linux also running "on" the card the GPL applies there as well. what if i want to change that?
Then you are loosing the HDMI output capability...
I'm also unhappy with that issue and I don't understand why it has to be a kernel module at all. But for now it's built that way.
Stefan Lucke stefan@lucke.in-berlin.de wrote:
They decide on which kernel it runs. If I need for some other device a different kernel which they don't / won't support, I'm left alone.
that's exactly what the GPL tries to prevent.
To my opinion that is a nogo way. I doubt if that's compatible with GPL.
i agree, binary only kernel modules do violate the GPL. unfortunatly many vendors get away with it.
best regards ... clemens
On Sat, Jun 30, 2007 at 01:05:18PM +0200, Stefan Lucke wrote:
Actually there's not much closed source that affects the usage. On the PC side there's none, on the card side it's only the driver for the HDMI-chip in the kernel
Damm, that's the nvidia way.
They decide on which kernel it runs. If I need for some other device a different kernel which they don't / won't support, I'm left alone.
It does not affect the kernel of the host system, so don't overreact...
To my opinion that is a nogo way.
Your opinion... From the outside it's easy to say that everything must be open source...
As a small hardware manufacturer you have three possibilities:
1) Don't use a HDMI transmitter and ignore the market demand. 2) Use a HDMI transmitter, care about the NDA and deliver binary modules for controlling it. 3) Use a HDMI transmitter, publish the controlling code and pay a contract penalty of a few million $.
On 30 Jun 2007, at 14:44, Georg Acher wrote:
As a small hardware manufacturer you have three possibilities:
- Don't use a HDMI transmitter and ignore the market demand.
- Use a HDMI transmitter, care about the NDA and deliver binary
modules for controlling it. 3) Use a HDMI transmitter, publish the controlling code and pay a contract penalty of a few million $.
4) put the HDMI code in user space.
Georg Acher acher@in.tum.de wrote:
- Don't use a HDMI transmitter and ignore the market demand.
the market never "demanded" an encrypted data stream on the HDMI cable, and it is clearly the only reason they are picky about their secrets within that driver. THEY want their chips be supported in linux because that means they get an stable and well performing OS at zero cost for their embedded designes what makes these chips sell better. hardware venders should start to obey to the rules of the game, when they want our money.
- Use a HDMI transmitter, care about the NDA and deliver binary
modules for controlling it.
why not use [Free|Net|Open]BSD on the card? that whould not mean the consumer has any advantage but at least no license violation happens.
best regards ... clemens
On Sat, Jun 30, 2007 at 08:29:19PM +0200, Clemens Kirchgatterer wrote:
Georg Acher acher@in.tum.de wrote:
- Don't use a HDMI transmitter and ignore the market demand.
the market never "demanded" an encrypted data stream on the HDMI cable,
From a technical view this is right, but with just a component output you
can't sell a HDTV decoder card nowadays. And HDMI is not only about encryption but also contains audio encapsulation. And that is an argument for HDMI vs. DVI... HDCP on a open Linux system is useless anyway.
and it is clearly the only reason they are picky about their secrets within that driver. THEY want their chips be supported in linux
The driver contains not much more than you would get with I2C-snooping. But if you want to buy the chip, you need to sign the NDA first...
because that means they get an stable and well performing OS at zero cost for their embedded designes what makes these chips sell better.
So what? Wasn't it idea of free Software to get it without paying for it? Or is there a newly inserted paragraph about hardware vendors to pay something if they use free SW?
hardware venders should start to obey to the rules of the game, when they want our money.
Overall, all this (IMO useless) discussion is only about the HDMI driver part which is currently (accidently) implemented in the kernel. I can't see that it's getting any "better" from an OSS standpoint when it's a closed-source user space program. Get real...
The usual practical "anti-binary" arguments for a PC platform (new mainboard requires new kernel) don't count here, it's an embedded system. You can't simply switch the kernel anyway, as it has many additions for the V4L-stuff.
- Use a HDMI transmitter, care about the NDA and deliver binary
modules for controlling it.
why not use [Free|Net|Open]BSD on the card? that whould not mean the consumer has any advantage but at least no license violation happens.
Well, you don't have to buy the card if you would wake up in cold sweat every once in a while because of the small binary-only part in the kernel.
But IMO you can wait until the end of time for a full open source HDTV card with HDMI output. If you have the time... ;-)
Georg Acher schrieb [ ... snip ... ]
Well, you don't have to buy the card if you would wake up in cold sweat every once in a while because of the small binary-only part in the kernel.
But IMO you can wait until the end of time for a full open source HDTV card with HDMI output. If you have the time... ;-)
Agreed on all your points. In the end the "firmware" of this card is more open then the one of the Nowadays common FF cards - so what ? I'm caring only for two things at the moment:
1.) That the card comes and can also be bought 2.) That the card fits into my budget (That i can and want to pay it)
To my understanding its just about feeding the stream into the card.
Another thing: Will it have a proper framebuffer ? I mean the main problem of the current FF cards is that you can't do a lot of things because of the very limited OSD. ScumVM etc pp would be a really nice thing.
Just my two cents - Steffen
On Sun, Jul 01, 2007 at 11:34:14AM +0200, Steffen Barszus wrote:
Another thing: Will it have a proper framebuffer ? I mean the main problem of the current FF cards is that you can't do a lot of things because of the very limited OSD. ScumVM etc pp would be a really nice thing.
The OSD framebuffer (RGBA) is accessible over PCI, but I don't know if acceleration functions will work outside the embedded system. We are planing to write a small fb-driver (shouldn't be that hard, as a direct mmap() already works).
Georg Acher acher@in.tum.de wrote:
From a technical view this is right, but with just a component output you can't sell a HDTV decoder card nowadays. And HDMI is not only about encryption but also contains audio encapsulation. And that is an argument for HDMI vs. DVI...
true.
HDCP on a open Linux system is useless anyway.
hdcp is useless on any system. it is the same with every single DRM scheme out there, it only limits the legal ownders in what they can do with what they bought. but this is even more off topic.
because that means they get an stable and well performing OS at zero cost for their embedded designes what makes these chips sell better.
So what? Wasn't it idea of free Software to get it without paying for it?
no. and i'm a little bit shocked to read this from you. i hope this is just an unlucky wording.
Or is there a newly inserted paragraph about hardware vendors to pay something if they use free SW?
sarcasm does not help here either.
free software does not care about how practical or profitable it is for you to fulfill your distribution-license requirements.
Overall, all this (IMO useless) discussion is only about the HDMI driver part which is currently (accidently) implemented in the kernel. I can't see that it's getting any "better" from an OSS standpoint when it's a closed-source user space program. Get real...
that's your opinion.
The usual practical "anti-binary" arguments for a PC platform (new mainboard requires new kernel) don't count here, it's an embedded system. You can't simply switch the kernel anyway, as it has many additions for the V4L-stuff.
what if i wan't to put additional faetures into the card? what if i want to fix a bug in the firmware? benefit from performance improvments in later kernel releases?
it is not you who has to decide what i do with my hardware. THAT is the whole point of free software. get real.
[..]
many people don't care about their freedom as users. either because they don't have the knowledege to fiddle with the software themselfs or they rather have binary drivers for their expensive / high performance video card than free drivers for a cheep one. fine. but at least vendors MUST respect the will of the countless developers who release their work under the license of their choice for a reason.
best regards ... clemens
On Sun, Jul 01, 2007 at 12:33:39PM +0200, Clemens Kirchgatterer wrote:
because that means they get an stable and well performing OS at zero cost for their embedded designes what makes these chips sell better.
So what? Wasn't it idea of free Software to get it without paying for it?
no. and i'm a little bit shocked to read this from you. i hope this is just an unlucky wording.
No, it's not. Free is free, you can't make differences between hardware vendors using Linux as a basis for their HW and SW vendors using Linux as an OS for their SW. And that's exactly the intention of your wording ("zero cost").
Or is there a newly inserted paragraph about hardware vendors to pay something if they use free SW?
sarcasm does not help here either.
Oh, it helps a lot to tolerate opinions from people who don't know what's behind selling hardware with chips from others. There are things you can't change, eg. NDAs.
free software does not care about how practical or profitable it is for you to fulfill your distribution-license requirements.
Until now, there's AFAIK no legal decision that you are not allowed to include binary only modules in the kernel. If it gets that far, we will put in user space. No real gain, but if it helps...
The usual practical "anti-binary" arguments for a PC platform (new mainboard requires new kernel) don't count here, it's an embedded system. You can't simply switch the kernel anyway, as it has many additions for the V4L-stuff.
what if i wan't to put additional faetures into the card? what if i want to fix a bug in the firmware? benefit from performance improvments in later kernel releases?
IMO a theoretical question. This is not file server. It's a video decoding card. Most of the important stuff is done in the (closed) co-processors anyway. If you want it to be a file server, you don't need the HDMI output.
it is not you who has to decide what i do with my hardware. THAT is the whole point of free software. get real.
Don't buy it and wait for a card with better Linux support.
I'm beginning to understand why big consumer hardware vendors won't do Linux support at all, if they get always this friendly reception...
[..]
many people don't care about their freedom as users. either because they don't have the knowledege to fiddle with the software themselfs or they rather have binary drivers for their expensive / high performance video card than free drivers for a cheep one. fine. but at least vendors MUST respect the will of the countless developers who release their work under the license of their choice for a reason.
Apropos "developers": How much do YOU already have developed for the Linux kernel, DVB-API or vdr? I've made the experience that the loudest people in this GPL issue have the least contributions...
But it's getting tedious. Take it or leave it, that's all I can say.
I demand that Georg Acher may or may not have written...
On Sun, Jul 01, 2007 at 12:33:39PM +0200, Clemens Kirchgatterer wrote:
[snip]
Until now, there's AFAIK no legal decision that you are not allowed to include binary only modules in the kernel. If it gets that far, we will put in user space. No real gain, but if it helps...
As things stand, ISTM that if you distribute, you'll be in clear licence-violation territory in the view of at least some of the copyright holders.
The usual practical "anti-binary" arguments for a PC platform (new mainboard requires new kernel) don't count here, it's an embedded system. You can't simply switch the kernel anyway, as it has many additions for the V4L-stuff.
what if i wan't to put additional faetures into the card? what if i want to fix a bug in the firmware? benefit from performance improvments in later kernel releases?
IMO a theoretical question. This is not file server. It's a video decoding card.
That doesn't matter. It's still Linux-based and you still need to release the modified sources (I'd say enough to allow the building of a complete filesystem image for the device).
And anyway, I think that the kernel-upgrade and bug-fix points are valid... and it'd probably help if you get as many of your changes upstream as you reasonably can (if you haven't already started on this). For a start, that's likely to make it easier for *you* to switch to a newer kernel :-)
Most of the important stuff is done in the (closed) co-processors anyway. If you want it to be a file server, you don't need the HDMI output.
No argument there.
[snip]
On Sun, Jul 01, 2007 at 02:33:21PM +0100, Darren Salt wrote:
That doesn't matter. It's still Linux-based and you still need to release the modified sources (I'd say enough to allow the building of a complete filesystem image for the device).
To make it clear: This whole argument is *ONLY* about the HDMI chip driver, which is the only closed source part in the kernel. This part is *not* a modification of some existing code. You can build the whole image without it (or maybe with a dummy module) from source, and all the video decoding and analog output will still work, but you lose and HDMI/DVI output.
Maybe there will be a better solution later, but for the moment that's it. There are enough real challenges in the project than thinking about how that module can be put into user space...
I demand that Georg Acher may or may not have written...
On Sun, Jul 01, 2007 at 02:33:21PM +0100, Darren Salt wrote:
That doesn't matter. It's still Linux-based and you still need to release the modified sources (I'd say enough to allow the building of a complete filesystem image for the device).
To make it clear: This whole argument is *ONLY* about the HDMI chip driver, which is the only closed source part in the kernel. This part is *not* a modification of some existing code.
That part may not be, but "you can't simply switch the kernel anyway, as it has many additions for the V4L-stuff." That (to me) says 'modified kernel source'...
[snip]
On Sun, Jul 01, 2007 at 03:55:04PM +0100, Darren Salt wrote:
I demand that Georg Acher may or may not have written...
On Sun, Jul 01, 2007 at 02:33:21PM +0100, Darren Salt wrote:
That doesn't matter. It's still Linux-based and you still need to release the modified sources (I'd say enough to allow the building of a complete filesystem image for the device).
To make it clear: This whole argument is *ONLY* about the HDMI chip driver, which is the only closed source part in the kernel. This part is *not* a modification of some existing code.
That part may not be, but "you can't simply switch the kernel anyway, as it has many additions for the V4L-stuff." That (to me) says 'modified kernel source'...
But that's included as source and released by Micronas as GPL. What I meant with "you can't simply" was that you need to do the all the diff'ing and porting the additions to a newer kernel version, which will not be actively supported. You can do it but I doubt the gain and RMM will stick to the "official" kernel version provided by Micronas anyway.
Georg Acher acher@in.tum.de wrote:
No, it's not. Free is free, you can't make differences between hardware vendors using Linux as a basis for their HW and SW vendors using Linux as an OS for their SW. And that's exactly the intention of your wording ("zero cost").
strange interpretation of my words. where did i say, that there is any difference from SW to HW vedors? "zero cost" implied, that some vendors just try to get a free ride. otherwise there was no need for
Oh, it helps a lot to tolerate opinions from people who don't know what's behind selling hardware with chips from others. There are things you can't change, eg. NDAs.
you can't change the GPL either.
free software does not care about how practical or profitable it is for you to fulfill your distribution-license requirements.
Until now, there's AFAIK no legal decision that you are not allowed to include binary only modules in the kernel. If it gets that far, we will put in user space. No real gain, but if it helps...
you are nitpicking. if you have read the kernel license and you understood its intention you can not think binary modules would not violate it. the GPL was never really challenged in court (at least to my knownledge), does that mean it's invalid? the FSF itself clearly stated, that binray only modules violate the GPL, who would know better?
[..]
it is not you who has to decide what i do with my hardware. THAT is the whole point of free software. get real.
Don't buy it and wait for a card with better Linux support.
I'm beginning to understand why big consumer hardware vendors won't do Linux support at all, if they get always this friendly reception...
the usual ranting.
what does linux support have to do with wether you obey a certain license or not? we are talking about the os "on" a pci card here. you decided to use free software for your benefit, to make the card cheaper or better or whatever. cool, no problem. what? you signed a NDA that does not allow you distribute the os in the first place? your bad.
if it is so easy for you to change the offending software part, why not from the beginning? your product specs sound really good and the fact that there is linux running on top of the hardware seems to make it a nice toy, at least at a first glance. the firmware of the ttpci cards are a good example of why i would love to have a more open firmware on it. how long did it take until it was stable? too long. 4MB ram support could only be added by someone with access to the source code. did it help anybody to keep the source locked up? did it prevent sc? no.
so i'm all for a DVB/video card that does not have these limitations. people like to tinker with their harware. even if it's not me personally who does something unusual with that thing, someone will. the pure possiblillity of beeing "hackable" adds value to it. the linux kernel, being monolithic, can be a showstopper if it can not be changed/upgraded.
many people don't care about their freedom as users. either because they don't have the knowledege to fiddle with the software themselfs or they rather have binary drivers for their expensive / high performance video card than free drivers for a cheep one. fine. but at least vendors MUST respect the will of the countless developers who release their work under the license of their choice for a reason.
Apropos "developers": How much do YOU already have developed for the Linux kernel, DVB-API or vdr? I've made the experience that the loudest people in this GPL issue have the least contributions...
regardless of wether this has something to do with the validity of my arguments or not: i never contributet patches to the linux kernel directly only some bugreports and patch-tests. i released one small plugin and once or twice sent patches for vdr, but they got rejected AFAICR, nevermind. besides from some small libraries and rather useless tools from my early days i hope that i can convince my employer to release my main project of the last 3 years under GPL3 [would be hopefully rather useful for STB vendors or even xbmc]. nevertheless i doubt i'm one of the loudest who endorses free software either. but i truly believe that the one and only reason, why GNU/Linux is what it is because of the GPL. otherwise it would be at best as "untot" as the BSDs.
But it's getting tedious. Take it or leave it, that's all I can say.
a decision i will make when time has come depending on the circumstances.
best regards ... clemens
On Sun, Jul 01, 2007 at 06:47:18PM +0200, Clemens Kirchgatterer wrote:
or better or whatever. cool, no problem. what? you signed a NDA that does not allow you distribute the os in the first place? your bad.
Once again, and now in capitals.
IT'S ONLY THE HDMI DRIVER. THE REST OF THE KERNEL IS GPL AND YOU CAN FIDDLE WITH IT AS YOU LIKE.
You won't find any HDMI chip without NDA for the forseeable future. No NDA, no chips, no HDMI. So there's simply no choice at all and analog inputs are slowly dying. A card without HDMI is already dead in the market.
If that security-by-obscurity is reasonable due to possible bus snooping, hacking, whatever: Surely not. Logitech also didn't gave me a datasheet for their Quickcam, so I reverse-engineered in in a few days with an USB analyzer. But this is not the point. If the vendor has the choice to sell cards or pay a multi million penalty, all these theoretical ideas get unimportant and the vendor cares about each single letter in the NDA.
On 01.07.2007 19:40, Georg Acher wrote:
On Sun, Jul 01, 2007 at 06:47:18PM +0200, Clemens Kirchgatterer wrote:
or better or whatever. cool, no problem. what? you signed a NDA that does not allow you distribute the os in the first place? your bad.
Once again, and now in capitals.
IT'S ONLY THE HDMI DRIVER. THE REST OF THE KERNEL IS GPL AND YOU CAN FIDDLE WITH IT AS YOU LIKE.
You won't find any HDMI chip without NDA for the forseeable future. No NDA, no chips, no HDMI. So there's simply no choice at all and analog inputs are slowly dying. A card without HDMI is already dead in the market.
If only the hardware vendors where as "united" as the movie-industry.
The result would have been a clear "F*ck You".
But with all that backstabing from the left/right/up/down/center, the only looser is the group between their chairs. (The consumer).
It's the same with the current PNR and SWIFT data-transfers to the USA.
If the EU would be united and say "F*ck You" the USA could happily close their borders. But i'd say the backlash from the economy would open up the borders faster than you can say 'Bad Idea'.
According to Wikipedia (sorry german) http://de.wikipedia.org/wiki/Liste_der_L%C3%A4nder_nach_Bruttoinlandsprodukt the EU (in total) has a greater "gross domestic product" than the USA! And the EU has more citizens (about 300M USA, about 492M EU).
But in all those cases the unity lacks and the "Power Player" wins. I'd say: Murphy's law proven right again.
Bis denn
On Sun, Jul 01, 2007 at 08:43:04PM +0200, Matthias Schniedermeyer wrote:
If only the hardware vendors where as "united" as the movie-industry.
HDCP was invented by Intel, Silicon Image holds a lot of patents on DVI and HDMI. As long as they can sell chips and licenses, they don't care about the consumer, looks quite united to me ;-)
In principle, HDMI is not that bad (ok, the mechanical part is ugly...). In contrast to DVI, it allows to encapsulate audio and additional information, which makes it much more universal. Unfortunately it is quite expensive to get into the club (and buy chips) and the legal stuff is -er- demanding...
And quite frankly, the "dumb" consumer doesn't care about HDCP and its implications. Compared to DRM on music, HDCP is invisible to him, he has no visible disadvantage. So all the boycott stuff is for freaks only. The consumer buys a display with HDMI and it just works (with or without HDCP). BTW: HDMI doesn't mean you have to enable HDCP.
But you can't tell the consumer "sorry, we think that HDMI is bad/crap/useless anyway, so we have only analog output". He will look for another product with a plug in the right form factor. And nobody spends a few hundred thousand $ on HW development just for a freak product...
I demand that Georg Acher may or may not have written...
[snip]
And quite frankly, the "dumb" consumer doesn't care about HDCP and its implications. Compared to DRM on music, HDCP is invisible to him, he has no visible disadvantage.
That's as may be... however, it does seem to be ignoring those of us who happen to want video output in a window (as I do now with vdr & gxine). If there's any taintware involved in that, I for one don't want it.
(And I couldn't care less about it right now, at least for my own use - there's no terrestrial HD broadcasting here and there won't be until 2012 at the earliest, that being when analogue transmission is switched off.)
So all the boycott stuff is for freaks only.
Right... so consumers are either dumb or freaks... remember that you're one too :-þ
[snip]
Georg Acher wrote:
And quite frankly, the "dumb" consumer doesn't care about HDCP and its implications. Compared to DRM on music, HDCP is invisible to him, he has no visible disadvantage. So all the boycott stuff is for freaks only. The consumer buys a display with HDMI and it just works (with or without HDCP). BTW: HDMI doesn't mean you have to enable HDCP.
I cannot let this pass.
They don't know they need to care, but they will, down the line after their money has been taken.
I own a sony HD projector that is not permitted to display HD content! this will happen to a lot more people and they will care. Especially when the next DRM protocol comes along. Its already happening to both protocols and DRM standards. I noticed that on the xine mailing list there was a request to encode wma content because their phone only supported that. With the rapidly growing green awareness there is the potential for a backlash against manufacturers that force consumers to dump working kit just because the hardware doesn't talk the same protocol. open standards are the only way to prevent that kind of waste and frustration. The problem with all DRM (and to some degree the rapidly changing protocols) is that the problems appear long after the initial purchase. They control the interface between equipment or media and as such it costs significant resources to fix, repair, replace or bypass etc and then only if its legal and purchasable.
Simon
Simon schrieb:
Georg Acher wrote:
And quite frankly, the "dumb" consumer doesn't care about HDCP and its implications. Compared to DRM on music, HDCP is invisible to him, he has no visible disadvantage. So all the boycott stuff is for freaks only. The consumer buys a display with HDMI and it just works (with or without HDCP). BTW: HDMI doesn't mean you have to enable HDCP.
I cannot let this pass.
They don't know they need to care, but they will, down the line after their money has been taken.
That may be or they just recognize that this "computerstuff" again just not works as advertized and they will buy it again the next time. The "freaks" trying to fix their stuff as good as possible after having prayed why they should not have bought it in the first place.
I own a sony HD projector that is not permitted to display HD content! this will happen to a lot more people and they will care. Especially when the next DRM protocol comes along. Its already happening to both protocols and DRM standards. I noticed that on the xine mailing list there was a request to encode wma content because their phone only supported that. With the rapidly growing green awareness there is the potential for a backlash against manufacturers that force consumers to dump working kit just because the hardware doesn't talk the same protocol. open standards are the only way to prevent that kind of waste and frustration. The problem with all DRM (and to some degree the rapidly changing protocols) is that the problems appear long after the initial purchase. They control the interface between equipment or media and as such it costs significant resources to fix, repair, replace or bypass etc and then only if its legal and purchasable.
And you really think somebody will recognize that ? Its again just that computer stuff that does not work as advertised ... I really hope you are right and people are understanding what open standards and open protocols are good for.
On 01.07.2007 21:10, Georg Acher wrote:
On Sun, Jul 01, 2007 at 08:43:04PM +0200, Matthias Schniedermeyer wrote:
If only the hardware vendors where as "united" as the movie-industry.
HDCP was invented by Intel, Silicon Image holds a lot of patents on DVI and HDMI. As long as they can sell chips and licenses, they don't care about the consumer, looks quite united to me ;-)
That's the "back-stabbing"-part i meant.
You can be certain that there is someone to pick up a knife laying around.
Here is another example of such a "knife" thing from today: http://hardware.slashdot.org/hardware/07/07/01/0221213.shtml
They invented it because they think that someone will want it (and most probably someone will), just the same as Intel/Silicon Image.
Another word would be: "anticipatory obedience" ("vorauseilender Gehorsam" (translated by dict.leo.org))
Bis denn
Georg Acher acher@in.tum.de wrote:
On Sun, Jul 01, 2007 at 06:47:18PM +0200, Clemens Kirchgatterer wrote:
or better or whatever. cool, no problem. what? you signed a NDA that does not allow you distribute the os in the first place? your bad.
Once again, and now in capitals.
IT'S ONLY THE HDMI DRIVER. THE REST OF THE KERNEL IS GPL AND YOU CAN FIDDLE WITH IT AS YOU LIKE.
maybe i should just shut up and let you believe whatever you want and this is clearly my last mail to this thread. i guess others or even you are already bored to death by this topic anyway. but its summer slump, so who cares.
i tried to explain multiple times why a binary module is not compatible with the gpl and why it is not relevant in any way that one can recompile or upgrade the kernel "sacrificing a fundamental feature of the hardware (speak HDMI)".
maybe i'm just not capable to make myself clear and/or find the right words so let me quote mr. linus torvalds stating (many times) that binary kernel modules are "by default" a derived work of the kernel and thus must be licensed (at least additionally) under gpl:
[..] In the binary kernel module case, a bug in the code corrupts random data structures, or accesses kernel internals without holding the proper locks, or does a million other things wrong, because a kernel module is very intimately linked with the kernel.
A kernel module is not a separate work, and can in no way be seen as "part of the hardware". It's very much a part of the kernel. And the kernel developers require that such code be GPLd so that it can be fixed, or, if there's a valid argument that it's not a derived work and not GPLd, then the kernel developers who have to support the end result mess most definitely do need to know about the taint. [..]
so what is a "valid argument" that a module is NOT a "derived work"?
[..]
Similarly, historically there was a much stronger argument for things like AFS and some of the binary drivers (long forgotten now) for having been developed totally independently of Linux: they literally were developed before Linux even existed, by people who had zero knowledge of Linux. That tends to strengthen the argument that they clearly aren't derived.
In contrast, these days it would be hard to argue that a new driver or filesystem was developed without any thought of Linux. I think the NVidia people can probably reasonably honestly say that the code they ported had no Linux origin. But quite frankly, I'd be less inclined to believe that for some other projects out there.
Linus
best regards ... clemens
To sum it up:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0312.0/0670.html Please resume this discussion in private mail.
EOT
Thorsten
On 29 Jun 2007, at 16:21, Jeremy Jones wrote:
On 6/29/07, Torgeir Veimo torgeir@pobox.com wrote:
On 29 Jun 2007, at 10:35, Georg Acher wrote:
On Thu, Jun 28, 2007 at 10:45:12PM -0700, Jeremy Jones wrote:
Is there any information regarding availability or pricing on the HDTV PCI card ? I have been waiting a long time for an HD MPEG-2/4 decoder with HDMI and this sounds promising :-)
Availability not earlier than August/September, the price isn't fixed yet.
There is other hardware that does mpeg2/4/h.264 decoding, the lacking piece is always proper open source drivers.
Do you have any links/info for such cards ?
Well, the new generation of graphics card from nvidia and ati/amd does h.264 decoding in hardware and have HDMI output. There's just no OS drivers for them.
-
Ales Jurik -
Anssi Hannula -
Clemens Kirchgatterer -
Darren Salt -
Georg Acher -
Igor -
Jeremy Jones -
Matthias Schniedermeyer -
Simon -
Stefan Lucke -
Steffen Barszus -
Thorsten Schnebeck -
Torgeir Veimo