From mgoldberg@sdesigns.com Mon, 16 Aug 1999 19:43:52 -0700
Date: Mon, 16 Aug 1999 19:43:52 -0700
From: Marshall Goldberg mgoldberg@sdesigns.com
Subject: [Livid-dev] Sigma Designs- How can we help?
Hello, I'm Marshall Goldberg, the Director of Marketing for Sigma
Designs. We make a DVD playback chip/card that some of you use, called
the Hollywood Plus. Many of you on this list have already conversed with
me via e-mail.
We would very much like to support Linux. We've been working very hard
to release a next-generation chip which will be Linux-compatible, it's
now taped out, and we'll have boards in 30 days or so.
But, I think you guys know that we're in a sticky situation, because of
a thing called the CSS. We signed a contract to become CSS licensees. We
cannot give away the source code, or "hints" or even crackable software.
Besides that, what would be the benefit? The purpose of CSS is to
prevent pirates from copying the digital contents of movies. Hollywood
is very paranoid of that, and, were CSS to be cracked, there is a good
chance that it would be the end of DVD. As it were, the original lack of
CSS encryption delayed the launch of DVD itself by over eighteen months.
What would be the good of DVD with no new titles?
So, it looks to us like the only solution will be a compiled driver,
with a thoroughly documented API. It doesn't seem as though we could
release complete chip documentation and source code, and then a
separate, compiled driver that supports DVD. It would reveal so much
about the inner workings of the chip, that it would become easier to
hack CSS, which we aren't allowed to reveal.
You see? We're between a rock and a hard place. We want to win the
support of the Linux community. We want to make killer products that you
really love. But we cannot make that product on your terms, and, my
opinion is that making the product the way we're being asked would
jeopardize DVD itself, which is bad for business and would really tick
me off, as a DVD fan.
What do you think about that? Is there a way we can gain the support and
enthusiasm of the Linux community, in light of the fact that we are
prohibited from revealing the details of CSS?
Marshall Goldberg
---------------------
Director of Product Marketing
Sigma Designs, Inc.
e-mail: mgoldberg@sdesigns.com
From pvolcko@concentric.net Mon, 16 Aug 1999 23:29:26 -0400 (EDT)
Date: Mon, 16 Aug 1999 23:29:26 -0400 (EDT)
From: pvolcko@concentric.net pvolcko@concentric.net
Subject: [Livid-dev] Sigma Designs- How can we help?
> Hello, I'm Marshall Goldberg, the Director of Marketing for Sigma
> Designs. We make a DVD playback chip/card that some of you use, called
> the Hollywood Plus. Many of you on this list have already conversed with
> me via e-mail.
Hey Marshall, glad to see you're involved with all this. You were of
great help to me a few months ago and hope that you'll be able to work
with us now. As you well know there is a lot of support and demand for a
good dvd product for linux (software or hardware based). Sigma has been
at the head of computer based dvd solutions for a while now and it would
be good to see you guys continue in that vane.
> You see? We're between a rock and a hard place. We want to win the
> support of the Linux community. We want to make killer products that you
> really love. But we cannot make that product on your terms, and, my
> opinion is that making the product the way we're being asked would
> jeopardize DVD itself, which is bad for business and would really tick
> me off, as a DVD fan.
>
> What do you think about that? Is there a way we can gain the support and
> enthusiasm of the Linux community, in light of the fact that we are
> prohibited from revealing the details of CSS?
Well I've been working with a group of people including Michael
Ignaszewski (hope I spelled that right) to try and create a Decoder API
specification and hopefully some library code to go along with it.
Hopefully that effort will bring a good solution to the CSS issues for
both corporate interests as well as development community interests.
First, I'm not familiar with the terms of a CSS license, so please step in
and correct anything here.
There is a body of public knowledge already out there with regard to CSS,
specifically the methods for establishing the authentication and secure
channel between the drive and the decoding device. Putting the
dissassembled CSS code that is floating around now (it can be used to fake
either end of a CSS authentication series) aside, the method and highlevel
process for establishing that authenticated session has been known for
awhile, thanks in large part to Andrew Veliath' work over at RPI.
From a programming standpoint, that high level series of steps taken to
establish the secure session between drive and decoder is all thats needed
to be known. Those steps are translatable to IOCTL functions in the linux
world and source code need not be rleased for them, they are part of the
loadable binary kernel module (the driver) for the card. The interface is
all that is needed to be know, and that can be even further simplified by
having the IOCTL's called from within an API, so that structures passed
into the IOCTLs are "hidden" from view.
All decryption happens in the hardware so there is no reason for concern
there. That means, even with kernel source code modifications to "trap"
data flowing from drive to card, the data is never accessable in an
unencrypted state. Assuming a passhtrough mechanism is being used in this
new chipset there isn't even a way (outside of analog recording devices)
to get at the output signal.
With these three points it seems that by releasing a binary only driver
(loadable kernel module) and binary API/Library (hopefully according to
the spec established in the group I mentioned before) with documented
interface, there will be little problem with CSS licensing issues.
Anything that would be "released" into public knowledge would be stuff
already known. If the CSS licensing is anything like the standard
DVD-Spec licensing, then since the information is already out there you
would be in the clear.
As a final point, all that need be revealed in the interface is what is
revealed in the Microsoft CSS support built into DirectShow. See the
pages at:
http://www.microsoft.com/directx/dxm/help/ds/ref/
propset_DVD_Copy_Protection.htm#AM_PROPERTY_DVDCOPY_
and
http://www.microsoft.com/directx/dxm/help/ds/ref/iface/IKsPropertySet.htm
For a description of the interface.
Another example can be found at the convergence decoder card API pages:
Decoder_CSS // (action{param1},data1)
// execute 1 to 4 once, then 5 to 8 for each track
// returns 0 on success, <0 on error
// -1: timeout reading data from card
// -2: data pointer not initialized
// -3: invalid action number
// Disk key:
// action=1 -> retreive drive challenge (10 byte) from card
// action=2 -> post drive response (5 byte) to card
// action=3 -> post card challenge (10 byte) and retreive card
response (5 byte)
// action=4 -> post disk key (2048 byte) into the card
// Title key:
// action=5 -> retreive title challenge (10 byte) from card
// action=6 -> post title response (5 byte) to card
// action=7 -> post card challenge (10 byte) and retreive card
response (5 byte)
// action=8 -> post encrypted title key (5 byte) into the card
// Standalone DVD drive:
// action=9 -> post disk key (2064 byte) into the card
} Decoder_Command;
This is a simplified interface described in:
http://www.linuxdvd.org/dvd/api/cvdvtypes.h
This is all the information that would be needed to utilize the card's CSS
features. Getting the keys from the drive and passing the decoder's keys
back to the drive would be up to the programmer and at that point Sigma is
out of the liability picture. In order for anyone to put a player
application out there (a minimal form of which is needed in order to set
up the card for a CSS session and play an encrypted DVD, unencrypted isn't
really an issue), they would need to get DVD Forum licensing and approval
anyway (to get the IFO specs at the very least).
What's your/Sigma's response to that line of thinking? What issues remain
to be mulled over that I didn't touch on?
Again, I'm glad to see Sigma Designs taking an active role in trying to
cater to the linux community. Merely showing up on this list has won
Sigma many points with developers, to be sure.
Paul Volcko
LSDVD Project
From lloyd@gin.martiniracing.net Tue, 17 Aug 1999 05:35:55 -0700
Date: Tue, 17 Aug 1999 05:35:55 -0700
From: Lloyd lloyd@gin.martiniracing.net
Subject: [Livid-dev] Sigma Designs- How can we help?
One potential solution would be to do something similiar to what Matrox
has done with the specs for their g200 and g400 cards. I am
unfortunately not a coder, but I will try to relay what I understand as
best I can.
I believe that they released the specs for most of the card except for
the Warp engine (which is the equivalent of the CSS stuff in the sense
that Matrox considers it highly confidential). With the warp engine,
they released binary-only microcode to control it.
As I mentioned earlier though, I dont know what Im talking about, so you
might want to check
http://glx.on.openprojects.net/ for better information.
Im sure their are purists who dont like it, but this way alot of it can
be open source except for the really sticky stuff, which is still
acceptable to any rational person on either side of the wall.
-lloyd
Marshall Goldberg wrote:
>
> Hello, I'm Marshall Goldberg, the Director of Marketing for Sigma
> Designs. We make a DVD playback chip/card that some of you use, called
> the Hollywood Plus. Many of you on this list have already conversed with
> me via e-mail.
>
> We would very much like to support Linux. We've been working very hard
> to release a next-generation chip which will be Linux-compatible, it's
> now taped out, and we'll have boards in 30 days or so.
>
> But, I think you guys know that we're in a sticky situation, because of
> a thing called the CSS. We signed a contract to become CSS licensees. We
> cannot give away the source code, or "hints" or even crackable software.
> Besides that, what would be the benefit? The purpose of CSS is to
> prevent pirates from copying the digital contents of movies. Hollywood
> is very paranoid of that, and, were CSS to be cracked, there is a good
> chance that it would be the end of DVD. As it were, the original lack of
> CSS encryption delayed the launch of DVD itself by over eighteen months.
> What would be the good of DVD with no new titles?
>
> So, it looks to us like the only solution will be a compiled driver,
> with a thoroughly documented API. It doesn't seem as though we could
> release complete chip documentation and source code, and then a
> separate, compiled driver that supports DVD. It would reveal so much
> about the inner workings of the chip, that it would become easier to
> hack CSS, which we aren't allowed to reveal.
>
> You see? We're between a rock and a hard place. We want to win the
> support of the Linux community. We want to make killer products that you
> really love. But we cannot make that product on your terms, and, my
> opinion is that making the product the way we're being asked would
> jeopardize DVD itself, which is bad for business and would really tick
> me off, as a DVD fan.
>
> What do you think about that? Is there a way we can gain the support and
> enthusiasm of the Linux community, in light of the fact that we are
> prohibited from revealing the details of CSS?
>
> Marshall Goldberg
> ---------------------
> Director of Product Marketing
> Sigma Designs, Inc.
> e-mail: mgoldberg@sdesigns.com
>
> _______________________________________________
> Livid-dev maillist - Livid-dev@livid.on.openprojects.net
> http://livid.on.openprojects.net/mailman/listinfo/livid-dev
--
-lloyd
From pvolcko@concentric.net Tue, 17 Aug 1999 09:36:31 -0400 (EDT)
Date: Tue, 17 Aug 1999 09:36:31 -0400 (EDT)
From: pvolcko@concentric.net pvolcko@concentric.net
Subject: [Livid-dev] Sigma Designs- How can we help?
> One potential solution would be to do something similiar to what
Matrox
> has done with the specs for their g200 and g400 cards. I am
> unfortunately not a coder, but I will try to relay what I understand as
> best I can.
>
> I believe that they released the specs for most of the card except for
> the Warp engine (which is the equivalent of the CSS stuff in the sense
> that Matrox considers it highly confidential). With the warp engine,
> they released binary-only microcode to control it.
>
> As I mentioned earlier though, I dont know what Im talking about, so you
> might want to check
> http://glx.on.openprojects.net/ for better information.
>
> Im sure their are purists who dont like it, but this way alot of it can
> be open source except for the really sticky stuff, which is still
> acceptable to any rational person on either side of the wall.
>
> -lloyd
>
This is a good point and something that might not have come through on my
previous message.
Open sourcing as much as possible is almost always the way to go. Sigma
can still keep control over what goes into the "official" source/driver.
And you gain a lot of programming talent, bug testers, and other resources
that would have been impossible to utilize any other way.
I understand, though, that many companies (not just Sigma) have
complicated legal issues and restrictions that prohibit source code
releases. While I'm in favor of open sourcing where possible, I don't
want to see important improvements to the linux OS (or any other) simply
not get brought in because source code isn't available for a particular
product.
And as the message quoted below makes clear, it is possible to provide
source code and programming specs to a large portion of the decoder card
functionality. Those companies that release such information will be "in
good standing" with the developer community and will get support from them
and through word-of-mouth advertising. Those companies that don't, even
if they have a superior product technically, will end up losing out on
(god I hate marketting terms) mind-share amoung linux users (and will
most likely end up with a inbox full of flame mail, unfortunately).
Sigma has a great chance right now to get their products in the hands of
linux users and developers, and working under the linux OS. Yes, Matrox
has an addon board and they released spec information, but that dvd
solution is somewhat limited in that one has to have a Matrox G200 (or
400?) to utilize it. Sigma offers a standalone soultion that is likely to
have a larger potential market. As such it is well positioned to make the
right choice and get drivers (hopefully at least partially open) and a
solid API/Library and/or spec information into the hards of the linux
community when the new cards are ready to ship.
Paul Volcko
LSDVD
From mgoldberg@sdesigns.com Tue, 17 Aug 1999 08:55:28 -0700
Date: Tue, 17 Aug 1999 08:55:28 -0700
From: Marshall Goldberg mgoldberg@sdesigns.com
Subject: [Livid-dev] Sigma Designs- How can we help?
Thanks, everyone, for such thought-provoking answers.
I'd like to try to proceed here. We'll have to wait for our upcoming EM 8400
decoder chip, however, in order to support Linux. New boards with this chip
will be availble in about 2 months, and I will seed the boards to a few
dozen Linux developers. Unfortunately, however, the Hollywood Plus is not a
suitable platform for Linux, because it decodes and decrypts audio in
software. We designed the EM 8400 with Linux in mind.
But I do think that those of you in favor of cracking the CSS are doing the
world a great disservice, and I wish you would stop. It's like writing a
virus. It doesn't "free" anybody. It stops Hollywood from releasing new
movies on DVD. Yes, I understand why open source code is so great, but I
like buying DVD's, too. I don't want to play a role in bringing about the
end of DVD.
Besides, hardware is never truly open source. Our decoder chips, for
instance, use downloadable microcode. But, oddly, the Linux world doesn't
seem to care about that. Nobody ever wants to hack your microcode, and it's
somehow assumed that we'll be around to take care of it.
It's looking as though we will have to keep at least some of our libraries
compiled. I wish there was more enthusiasm to support this. We will probably
segment the compiled libraries so that they wouldn't be used for MPEG
playback, only for encrypted DVD playback.
I'd like to move forward next with a constructive look at our EM 9010 analog
overlay chip, and how it can can be applied for video-in-a-window use under
any Linux GUI. I'll write about it in a few days.
Marshall Goldberg
Sigma Designs
From aholtzma@ess4.engr.UVic.CA Tue, 17 Aug 1999 09:17:54 -0700
Date: Tue, 17 Aug 1999 09:17:54 -0700
From: Aaron Holtzman aholtzma@ess4.engr.UVic.CA
Subject: [Livid-dev] Sigma Designs- How can we help?
> But I do think that those of you in favor of cracking the CSS are doing the
> world a great disservice, and I wish you would stop. It's like writing a
> virus. It doesn't "free" anybody. It stops Hollywood from releasing new
> movies on DVD. Yes, I understand why open source code is so great, but I
> like buying DVD's, too. I don't want to play a role in bringing about the
> end of DVD.
Let me just make some quick commentary here. CSS does _not_ prevent
piracy. It only prevents mom and pop from dumping a dvd to their 20 gig
hard drive. CSS does this job quite well. Our efforts here will have
negligible impact on its effectiveness in this regard.
cheers,
aaron
From andreas@andreas.org 17 Aug 1999 19:11:12 +0000
Date: 17 Aug 1999 19:11:12 +0000
From: Andreas Bogk andreas@andreas.org
Subject: [Livid-dev] Sigma Designs- How can we help?
"Marshall Goldberg" <mgoldberg@sdesigns.com> writes:
> Besides, hardware is never truly open source. Our decoder chips, for
> instance, use downloadable microcode. But, oddly, the Linux world doesn't
> seem to care about that. Nobody ever wants to hack your microcode, and it's
> somehow assumed that we'll be around to take care of it.
Today it isn't. This might change. But the strongest motivation for
open source drivers today is that they allow you freedom in the choice
of platforms. With an open source driver, I can decide _not_ to use
the x86 processor architecture, or might even venture to port the
driver to another OS like FreeBSD. I'm writing this very mail on a
Macintosh running Linux.
Hacking your microcode _is_ interesting. But freedom of choice in OS
and architecture is _way_ more important, and we applaud your move to
support that, and delay pestering you or other manufacturers for the
microcode sources when there's a real need for it besides satisfying
our curiosity.
> It's looking as though we will have to keep at least some of our libraries
> compiled. I wish there was more enthusiasm to support this. We will probably
> segment the compiled libraries so that they wouldn't be used for MPEG
> playback, only for encrypted DVD playback.
I'm in a position here which is close to yours. We had to sign all
that paperwork to get access to the DVD standards as well. So I
understand your point of view. But you could make a lot of people
happy if you provide a way for users of alternate free operating
systems and alternate platforms to get access to a binary for their
respective platform, e.g., by having a developer for a respective
platform sign an NDA and sending them the sources.
Andreas
--
"We show that all proposed quantum bit commitment schemes are insecure because
the sender, Alice, can almost always cheat successfully by using an
Einstein-Podolsky-Rosen type of attack and delaying her measurement until she
opens her commitment." ( http://xxx.lanl.gov/abs/quant-ph/9603004 )
From derek@spider.com Tue, 17 Aug 1999 19:28:19 +0100
Date: Tue, 17 Aug 1999 19:28:19 +0100
From: Derek Fawcus derek@spider.com
Subject: [Livid-dev] Sigma Designs- How can we help?
On Tue, Aug 17, 1999 at 08:55:28AM -0700, Marshall Goldberg wrote:
>
> Unfortunately, however, the Hollywood Plus is not a suitable platform
> for Linux, because it decodes and decrypts audio in software. We designed
> the EM 8400 with Linux in mind.
On the issue of audio, I'm quite happy to use an external AC3 decoder
and amp/speakers. These generally have a digital input of some sort, and
as such, one would only need to extract the AC3 stream to feed through the
external interface. If the only audio on a particular DVD was actually
MPEG, then sure decoding the audio would be needed.
> It stops Hollywood from releasing new movies on DVD.
This has been my only concern wrt the reverse engineering of CSS. At
the moment only the authentication has been figured out, the decryption
is still to be done.
Now my opinion is that the CSS scheme is nothing to do with piracy, more
to do with control of the market. I can see why studios and distributers
want this control, and frankly I'm not bothered either way. It may be
that if they loose this perceived control, that they will give up on DVD.
My motivation for being involved in this is simply that I wish to be able
to build up a high quality DVD & DVB configuration. For this it basically
at the moment means using computer equipment (projection monitors etc), and
a robust set of application (under a robust OS). Unfortunatly Win 95 just
doesn't cut it as far a platforms go, so that means using a Unix system.
The lack of support for the Unix/X11 based systems is the reason why this
developemnt work is occuring. I'd be quite happy to purchase a system that
supported the type of configuration I'm interested in - if it was available.
> Nobody ever wants to hack your microcode, and it's somehow assumed that
> we'll be around to take care of it.
That's 'cause it's thought of as part of the h/w. As long as the API
and/or documentation to use the h/w (together with it's microcode) is
available, then there is no need or other motivation to hack at the
microcode.
> We will probably segment the compiled libraries so that they wouldn't
> be used for MPEG playback, only for encrypted DVD playback.
Would you be willing to expand upon the reason for the above? As I
said, I'm interested in DVB & DVD. For this having a h/w MPEG playback
capability is a big plus. If the h/w one buys for DVD can't be used for
plain MPEG playback, then things get a bit silly.
If your reasoning is that you don't want to make things too easy for
people doing software CSS of encrypted DVD's, then could you simply
prevent the playback of unencryoted VOB streams but allow the playback
of simply MPEG transport/program streams.
Hmm also this would prevent people from watching any unencrypted DVD's,
such as the "Trainspotting" DVD which I have. I don't know what % of
DVD's are released unencypted but I'd say there are a fair number, any
system which prevents them from being watched will have problems in the
market. (There could also be legal issues if they are not clearly marked
as such).
> I'd like to move forward next with a constructive look at our EM 9010 analog
> overlay chip, and how it can can be applied for video-in-a-window use under
> any Linux GUI. I'll write about it in a few days.
Hmm, this would be a completly seperate device using a pass through
cable like used on say the Voodoo cards - but with selectable areas
overlaid - sort of like the use of the blanking signal on SCART?
I know that there is work going on to allow video in a window within
the XFree86 development, however this is more geared towards device
where the video passes through the same set of chips as for graphics.
Irrespective - the Xv extension gives an API for this sort of thing
under X11 and I think it would be useful if it was possible to have
that API being used for this.
DF
--
Derek Fawcus derek@spider.com
Spider Software Ltd. +44 (0) 131 475 7034
From pvolcko@concentric.net Tue, 17 Aug 1999 17:50:16 -0400 (EDT)
Date: Tue, 17 Aug 1999 17:50:16 -0400 (EDT)
From: pvolcko@concentric.net pvolcko@concentric.net
Subject: [Livid-dev] Sigma Designs- How can we help?
> > We will probably segment the compiled libraries so that they wouldn't
> > be used for MPEG playback, only for encrypted DVD playback.
>
> Would you be willing to expand upon the reason for the above? As I
> said, I'm interested in DVB & DVD. For this having a h/w MPEG playback
> capability is a big plus. If the h/w one buys for DVD can't be used for
> plain MPEG playback, then things get a bit silly.
>
> If your reasoning is that you don't want to make things too easy for
> people doing software CSS of encrypted DVD's, then could you simply
> prevent the playback of unencryoted VOB streams but allow the playback
> of simply MPEG transport/program streams.
>
> Hmm also this would prevent people from watching any unencrypted DVD's,
> such as the "Trainspotting" DVD which I have. I don't know what % of
> DVD's are released unencypted but I'd say there are a fair number, any
> system which prevents them from being watched will have problems in the
> market. (There could also be legal issues if they are not clearly marked
> as such).
My reading of his statement was that the library might be broken up into a
open sourced or otherwise made freely available lib for straight MPEG1/2
display and there would a closed, possibly signed NDA access only, lib for
DVD playback with all included CSS functionality and AC-3 playback, etc.
The first would be used for mpeg-1/2 file playback where the second would
be used for both encrypted and unencrypted DVD playback.
You're right though, some more explaination would help to clear this up.
:)
> > I'd like to move forward next with a constructive look at our EM 9010 analog
> > overlay chip, and how it can can be applied for video-in-a-window use under
> > any Linux GUI. I'll write about it in a few days.
>
> Hmm, this would be a completly seperate device using a pass through
> cable like used on say the Voodoo cards - but with selectable areas
> overlaid - sort of like the use of the blanking signal on SCART?
If this is the same chip used on the hollywood+ then it is a chroma key
based analog overlay (via passhthrough).
> I know that there is work going on to allow video in a window within
> the XFree86 development, however this is more geared towards device
> where the video passes through the same set of chips as for graphics.
> Irrespective - the Xv extension gives an API for this sort of thing
> under X11 and I think it would be useful if it was possible to have
> that API being used for this.
Under X I think that this could be very easily done with nothing more than
a window with the chroma key background color placed at the same place the
DVD overlay is expecting it to be. No framebuffer access or anything like
that. Very easy to implement. Just requires a few API functions to set
the position and the size and the chroma key color (and tolerances) to the
overlay chip.
Where does macrovision get implemented in the decoder card, Marshall? The
overlay chip or in a seperate S-VideoTV out chip that does all the refresh
rate and interlacing stuff as well?
Paul Volcko
LSDVD
From mgoldberg@sdesigns.com Mon, 23 Aug 1999 18:51:30 -0700
Date: Mon, 23 Aug 1999 18:51:30 -0700
From: Marshall Goldberg mgoldberg@sdesigns.com
Subject: [Livid-dev] Sigma Designs- How can we help?
>> On the issue of audio, I'm quite happy to use an external AC3
decoder
and amp/speakers. These generally have a digital input of some sort,
and
as such, one would only need to extract the AC3 stream to feed through
the
external interface. If the only audio on a particular DVD was actually
MPEG, then sure decoding the audio would be needed. <<
Yes, right, but that AC-3 is encrypted. There's the rub.
>> Now my opinion is that the CSS scheme is nothing to do with piracy,
more
to do with control of the market. <<
In Asia, piracy is really rampant, and by cracking CSS, you can make
digital copies of the original MPEG source. If you encode MPEG video
from the analog output of a DVD, there's a generational copy loss.
>> My motivation for being involved in this is simply that I wish to be
able
to build up a high quality DVD & DVB configuration. <<
Yes, this is the kind of thing we want to help support. The idea is
that, yes, our API can support both functions. And, while we *MAY*
release the source of the driver for supporting the DVB playback, we
won't release the part which handles DVD. So this is where we talk about
library segmentation. Even though some functions are basically
identical, if our driver is opening up an encrypted VOB, then this will
be done with non-open source code.
> Nobody ever wants to hack your microcode, and it's somehow assumed
that
> we'll be around to take care of it.
> That's 'cause it's thought of as part of the h/w. As long as the
API
and/or documentation to use the h/w (together with it's microcode) is
available, then there is no need or other motivation to hack at the
microcode. <
Well understood, but our driver does things which you would think the
chip does, like it parses MPEG data for a variety of reasons, it handles
seeking, it reduces the data for fast and backwards play, and so forth.
You'd think this was something the hardware does, but it doesn't.
> We will probably segment the compiled libraries so that they wouldn't
> be used for MPEG playback, only for encrypted DVD playback.
> Would you be willing to expand upon the reason for the above? <
I think I did expand on this. By "segmented" I mean that the complete
driver can do everything you'd want, but the parts that deal with
handling encrypted DVD's would be "closed" as per our licensing
agreements.
> I'd like to move forward next with a constructive look at our EM 9010
analog
> overlay chip, and how it can can be applied for video-in-a-window use
under
> any Linux GUI. I'll write about it in a few days.
> Hmm, this would be a completly seperate device using a pass through
cable like used on say the Voodoo cards - but with selectable areas
overlaid - sort of like the use of the blanking signal on SCART? <
Yes, the analog overlay is a whole new ball-game, that's why we'll need
some help. We'll release some specs on the part one of these days...
Marshall Goldberg
From mgoldberg@sdesigns.com Mon, 23 Aug 1999 18:57:15 -0700
Date: Mon, 23 Aug 1999 18:57:15 -0700
From: Marshall Goldberg mgoldberg@sdesigns.com
Subject: [Livid-dev] Sigma Designs- How can we help?
Andreas Bogk (andreas@andreas.org) writes:
> But the strongest motivation for open source drivers today is that
they allow you freedom in the choice of platforms. <
I hope we can eventually support all of these, I just don't know right
now.
>>But you could make a lot of people
happy if you provide a way for users of alternate free operating
systems and alternate platforms to get access to a binary for their
respective platform, e.g., by having a developer for a respective
platform sign an NDA and sending them the sources. <<
I'm afraid that's not viable. The license we have for DVD is extremely
restrictive, and we can only let employees view the CSS code, and only a
select few employees can access that code, and they had to sign specific
documents. I've never seen anything like it. This is not something we're
trying to keep away from the Linux world. We want to give the Linux
world something that makes everybody (well, lots of people) very happy.
We just have a lot of limitations to deal with. But, we have a lot of
smart engineers, and they're good at figuring things out, so hopefully
this will be one of these things.
I'm not trying to get flamed, I'm just trying to figure out how to make
a good product.
Marshall Goldberg
Sigma Designs
From masoto@uniandes.edu.co 24 Aug 1999 14:46:43 -0500
Date: 24 Aug 1999 14:46:43 -0500
From: Martin Soto masoto@uniandes.edu.co
Subject: [Livid-dev] Sigma Designs- How can we help?
Hello all:
I sent a personal mail to Marshall Goldberg yesterday, touching some
of the topics that are being discussed here in the list. Although
Marshall actually answered me very promptly and kindly, it seems to me
that participating in this thread may turn out to be much more
productive than holding a personal conversation with him. So, I'll
briefly tell everybody what our short conversation was about, and
we'll see if with the help of the group we can find a viable solution.
I own a Creative DXR3 decoder card (whose chipset is made by Sigma
Designs, and is the same used by Sigma's Hollywood+ card). As far as
I understand, the card does the MPEG2 decoding in hardware, while
other DVD issues, like CSS decoding, are handled by the driver
software. Since I suppose many people here own DXR3 or Hollywood+
cards, I think it would be interesting to have support for the really
excellent MPEG2 decoder in those cards, even if we don't have initial
support for the full DVD thing. Marshall's answer raises some issues
that are basically the same ones he mention in his latest message to
the list.
Marshall Goldberg <mgoldberg@sdesigns.com> writes:
>> On the issue of audio, I'm quite happy to use an external AC3
> decoder
> and amp/speakers. These generally have a digital input of some sort,
> and
> as such, one would only need to extract the AC3 stream to feed through
> the
> external interface. If the only audio on a particular DVD was actually
> MPEG, then sure decoding the audio would be needed. <<
>
> Yes, right, but that AC-3 is encrypted. There's the rub.
Ok, that's certainly a problem. However, can't the digital interface
in the card be used without CSS? That would be useful for non
encrypted AC3 streams (not very common nowadays, but possible).
Another possibility would be a sound (ALSA or the like) driver that
gets five PCM channels and encodes them into an AC3 stream. Very nice
for gaming, for example.
Additionally, the stereo DA converter in the card can be supported as
a standard sound device. I have it connected to one of the inputs in
my amplifier, so this would be nice for playing MP3 files or any
other similar sound formats.
> >> My motivation for being involved in this is simply that I wish to be
> able
> to build up a high quality DVD & DVB configuration. <<
>
> Yes, this is the kind of thing we want to help support. The idea is
> that, yes, our API can support both functions. And, while we *MAY*
> release the source of the driver for supporting the DVB playback, we
> won't release the part which handles DVD. So this is where we talk about
> library segmentation. Even though some functions are basically
> identical, if our driver is opening up an encrypted VOB, then this will
> be done with non-open source code.
Library segmentation can be a good idea IMO. Is there any reason why
this scheme is viable for the new Sigma chipset and not viable for
the existing one?
I wonder if it would be possible to find a scheme where the non-DVD
code is developed by the community in an open source fashion, while
Sigma or other interested party, provides the DVD specific portions.
I don't know whether this is possible given the strict DVD licensing
conditions, but it may be an interesting compromise between open
source and the usual DVD secrecy.
Best regards,
M. S.
------------
Martin A. Soto J. Profesor
Departamento de Ingenieria de Sistemas y Computacion
Universidad de los Andes masoto@uniandes.edu.co
From pvolcko@concentric.net Tue, 24 Aug 1999 17:04:45 -0400 (EDT)
Date: Tue, 24 Aug 1999 17:04:45 -0400 (EDT)
From: pvolcko@concentric.net pvolcko@concentric.net
Subject: [Livid-dev] Sigma Designs- How can we help?
The LSDVD project that I'm involved with is in a unique situation that has
some of these issues involved. I'll tell you with what we know and have
come up with and maybe go on with some other issues that are related.
> Ok, that's certainly a problem. However, can't the digital interface
> in the card be used without CSS? That would be useful for non
> encrypted AC3 streams (not very common nowadays, but possible).
> Another possibility would be a sound (ALSA or the like) driver that
> gets five PCM channels and encodes them into an AC3 stream. Very nice
> for gaming, for example.
>
> Additionally, the stereo DA converter in the card can be supported as
> a standard sound device. I have it connected to one of the inputs in
> my amplifier, so this would be nice for playing MP3 files or any
> other similar sound formats.
This is a good idea. The CSS is in software for the HW+ and DXR3, as well
as AC3 decoding, so making a driver for PCM and SPDIF output ports as well
as TV OUT and MPEG2 decoding shouldn't really be an issue. These cards
can be used in other ways than simply as a DVD decoder.
> Library segmentation can be a good idea IMO. Is there any reason why
> this scheme is viable for the new Sigma chipset and not viable for
> the existing one?
This is a *very* good question. I expect it will come down to how much
man power that Sigma currently has to actually make and support these
split libraries over many cards, but it is still a very good question.
> I wonder if it would be possible to find a scheme where the non-DVD
> code is developed by the community in an open source fashion, while
> Sigma or other interested party, provides the DVD specific portions.
> I don't know whether this is possible given the strict DVD licensing
> conditions, but it may be an interesting compromise between open
> source and the usual DVD secrecy.
Heres where LSDVD's history with these issues can be useful.
For those that don't know, LSDVD is a program being developed that will
play DVDs. Not just act as a front end for dumping VOB data to a card.
This will support interactive DVD menus, provide a full interface similar
to current windows offerings, read and use IFO files, and offer all the
current abilities of the windows players.
We happen to have access to DVD specs. This allows us to develop.
The license for the specs prohibits disclosure of the spec in any way,
though. So open source is out for the parts that are DVD specific. This
is roughly 805 of the code in the project. Note that for the purposes of
theis dicussing LSDVD does not do software decoding of data. We can
assume it relies on hardware decoding (not necessarily the case in reality
however).
So, as far as open sourcing goes, here is what we would be able to make
available:
- Interface to the DVD-navigation functions. Similar to the interface
published on linuxtv.org's pages and that published by Microsoft in the
DirectShow documentation.
- All code for the GUI elements and "application" logic, such as
configuration file handling and device configuration. This last part
would be nothing more that calls to an already (presumably) open device
driver or Decoder API.
- The Decoder API, this is a project currently underway that will allow a
programmer to access and use decoder hardware and software codecs as if
they were the same thing, most likely behind a library of functions of
some sort. LSDVD plans is heavily supporting this project and plans full
involvement to the end.
Adn thats it. The interface definition won't be any code, just some
documentationa nd maybe a header file for use in programming. The GUI and
application logic will be about 10% of the total code, and even smaller
part in functionality terms. The Decoder API will likely only be around
10% of the codebase as well.
This isn't because we don't want to release code. When I got involved
with the project some 4-5 months ago the intentions were to open source
the whole thing. But it was soon realized that there were a myriad of
licensing issues and restrictions. In order to make such an application
(or a driver that provides the functionality) the source has to be largely
closed. The portions that would be open sourcable, in the case of a sigma
designs driver that provided a navigation level interface (much more than
what most would consider a driver, but for the sake of arguemnt) the only
part that they would be able to opne source would be the code dealing
directly with the card. Even things such as buffering and vob stream
decoding would likely be close source since this would reveal aspects of
the DVD spec.
Now if we also consider software codecs things look a little brighter
"kinda". Someone who developed an Dolby Digital AC-3 codec implementation
would be able to open source it and distribute it freely only after
getting a $10,000 implementation license from Dolby. I know everyone is
saying, what about AC3DEC from Aaron Holtzman? Well, I've read through
the licensing agreements that Dolby has and their patents and I'm fairly
certain that Aaron is walking on very thin ice with this. As it is a work
in progress and the license he put on it (GPL) has terms stating that the
code isn't necessarilyfit for any specific purpose, he may have a little
leeway. But his design intent and purpose was to make an Dolby Digital
AC-3 decoder. This is what Dolby's lawyers would be concerned with, GPL
or not. Also consider that use of an open sourced implementation in a
distributed software application that performs AC-3 audio output (no
matter the number of output channels) will require additional licensing.
The MPEG-2 codec is better still. There is no implementation license for
it. This means that anyone can create and freely distribute a MPEG-2
decoder implementation as such. But once someone uses it in a software
decoding/playback mechanism and distributes that publicly, then it is in
violation of MPEGLA licensing terms and a royalty based license would need
to be acquired.
When LSDVD is made available, again assuming hardware decoding only, it
is hoped that it will be freely available and distributable and that it
will have support for the new Sigma designs chipset (EM8400) and the
convergence card and any others that we can make arrangments with or have
drivers available (Livid driver support is slated as well). But it is
more than likely going to be a binary and minimal open source
distribution only. People will be able to, for instance, take the front
end GUI code and port it to different GUI toolkits and GUI frameworks
(GTK, Qt, WINGs, whatever). They would also be able to take binary
object/library that is the rest of the app and create an entire new
application for it (embedded web/java app, for example). This would be
the extent of it though.
We encourage companies to open source their card drivers and to keep the
driver functionality to a minimum. There is no need, for example, for
Sigma Designs to create a driver that provides up to Annex J interface
support. Then we have people making programs that have to support
specific annex J implementations (assuming other card vendors do this same
high level driver too). It also totally circumvents the utility of the
Decoder API and all the benefits it will provide.
But, at the same time, it is obvious that some companies, such as Creaitve
labs with their DXR2, are in tough contracts and NDAs that prohibit open
sourcing.
Do we want to see these card vendors and other DVD related software
vendors not release on Linux simply because we demand open source and will
stand by that demand? Or do we want the support and are willing to
relinquish most if not all of the driver source code and application
source code to get it? Keep in mind, as NDAs and restrictions are lifted
(they will be eventually, they always are), that the code can then be
freed up to the public and we get that open source that we want.
Do we want support now, or do we want it when (1, 2, 5, 10 years down the
line) organizations like the DVD-Forum come around to the idea of open
standards? Would you support and use LSDVD or something else released in
the same way as described above?
Paul Volcko
LSDVD
From mgoldberg@sdesigns.com Tue, 24 Aug 1999 14:27:02 -0700
Date: Tue, 24 Aug 1999 14:27:02 -0700
From: Marshall Goldberg mgoldberg@sdesigns.com
Subject: [Livid-dev] Sigma Designs- How can we help?
pvolcko wrote:
>>- Interface to the DVD-navigation functions. Similar to the interface
published on linuxtv.org's pages and that published by Microsoft in the
DirectShow documentation.
- All code for the GUI elements and "application" logic, such as
configuration file handling and device configuration. This last part
would be nothing more that calls to an already (presumably) open device
driver or Decoder API.
- The Decoder API, this is a project currently underway that will allow
a
programmer to access and use decoder hardware and software codecs as if
they were the same thing, most likely behind a library of functions of
some sort. LSDVD plans is heavily supporting this project and plans
full
involvement to the end. <<
This is exactly what we provide in MS Windows, albeit in object code.
So, of course we support this kind of a product. In fact, we do more in
Windows, because we also include the DVD player application, so that our
customers aren't required to write their own players (or download
something of the net) just to use the card. I suspect we'll have to
provide more support for our analog overlay technology, in order to make
it portable to the many flavors of GUI's that live in Linux.
So, for instance, there is an API call you can make to "Display Menu" or
"Display Title Menu," and another call you can make to get a list of the
menu items, to scroll up/down/left/right through the menus and select an
item, get a list of available sub-titles, get a list of available sound
tracks, set sub-title or sound track, and so forth. But you can't get
"inside" of that navigator API.
Example: DVD's from Paramount offer Dolby ProLogic (PCM) and Dolby
Digital (AC-3) audio tracks, and they default to ProLogic (it sounds
better on a non-AC-3 system). Since I always use Dolby Digital, I'd like
my player to always search for an AC-3 track, and automatically select
that track if it's available. The API would let you do that.
Example 2: Most DVD's force you to watch a copyright screen. When the
copyright screen is displayed, the navigator refuses to let you fast
play or jump to the next chapter. The API would not let you write a
program to circumvent this, but you might, after displaying this menu,
write a feature that automatically jumps to a "bookmark" location you
saved from a previous viewing.
My confusion, I think, comes from other developers who are insistent
that our product will be completely useless if we cannot release all of
the source to the device driver. If our Linux product is "useless"
without a release of all source code, and our licenses prevent us from
doing so, then there's not much point in getting on the Linux bandwagon.
Marshall Goldberg
---------------------
Director of Product Marketing
Sigma Designs, Inc.
355 Fairview Way
Milpitas, CA 95035-3024
e-mail: mgoldberg@sdesigns.com
From pvolcko@concentric.net Tue, 24 Aug 1999 18:49:13 -0400 (EDT)
Date: Tue, 24 Aug 1999 18:49:13 -0400 (EDT)
From: pvolcko@concentric.net pvolcko@concentric.net
Subject: [Livid-dev] Sigma Designs- How can we help?
> This is exactly what we provide in MS Windows, albeit in object code.
> So, of course we support this kind of a product. In fact, we do more in
> Windows, because we also include the DVD player application, so that our
> customers aren't required to write their own players (or download
> something of the net) just to use the card. I suspect we'll have to
> provide more support for our analog overlay technology, in order to make
> it portable to the many flavors of GUI's that live in Linux.
>
> So, for instance, there is an API call you can make to "Display Menu" or
> "Display Title Menu," and another call you can make to get a list of the
> menu items, to scroll up/down/left/right through the menus and select an
> item, get a list of available sub-titles, get a list of available sound
> tracks, set sub-title or sound track, and so forth. But you can't get
> "inside" of that navigator API.
>
> Example: DVD's from Paramount offer Dolby ProLogic (PCM) and Dolby
> Digital (AC-3) audio tracks, and they default to ProLogic (it sounds
> better on a non-AC-3 system). Since I always use Dolby Digital, I'd like
> my player to always search for an AC-3 track, and automatically select
> that track if it's available. The API would let you do that.
>
> Example 2: Most DVD's force you to watch a copyright screen. When the
> copyright screen is displayed, the navigator refuses to let you fast
> play or jump to the next chapter. The API would not let you write a
> program to circumvent this, but you might, after displaying this menu,
> write a feature that automatically jumps to a "bookmark" location you
> saved from a previous viewing.
>
> My confusion, I think, comes from other developers who are insistent
> that our product will be completely useless if we cannot release all of
> the source to the device driver. If our Linux product is "useless"
> without a release of all source code, and our licenses prevent us from
> doing so, then there's not much point in getting on the Linux bandwagon.
It depends. If you release binary only object files (the API) and a
loadable binary module for the linux kernel (the driver) and provide
interface documentation to both, then I think that provides all the
"tools" that developers will need.
- With the driver interface people can utilize the card in the various
ways it might not have originally been intended, for instance:
- using the PCM audio output as a second "sound card" of sorts.
- using the TV out capability to display MPEG-1 and MPEG-2 files
through something besides the supplied player application (if there
is one).
- using the SPDIF output for AC-3 decoding/encoding projects or as a
completely different kind of digital output (school projects for
robotic control, etc)
- building support for other applications to use embedded MPEG-2 video
It would also allow:
- Supporting the card in the Decoder API, without any Sigma Designs
help/involvement if needed.
- Supporting the card in a future open source DVD-Video API,
implementing the functionality of the suppied API, but in open source
when the licensing/NDA environment makes it possible.
- Situations, like the LSDVD project, to support the decoder card in
their application while using their own DVD-Video engine.
- With the API interface:
- People can write DVD-Video support into other applications utilizing
the card (buth only that card).
- play a variety of data formats:
- VOB
- MPEG-1
- MPEG-2
- AC-3
- PCM
- whatever else the card/API supports
I think that releasing the driver and API as seperate things is a
reasonable solution, as long as documentation of the interface and perhaps
special programming information for use with the driver is supplied. A
source code driver would be better, but if NDA/licensing makes that a
non-option that I see this as the next best thing.
I said above that the Decoder API could be made to support the new card as
long as driver interface information were made available, without Sigma
Design's help or involvement. This is not how it should be. Preferably
there would be involvement from Sigma Designs. Michael is already working
with us to get a specification worked up. Hopefully this will continue.
But if it can't or Sigma Designs doesn't see an "official" point in
participating, then this driver interface information is absolutely
necessary.
As for the player application... Well, I'm of course biased since that's
what I'm involved with making in LSDVD. :)
Paul Volcko
LSDVD
From masoto@uniandes.edu.co 24 Aug 1999 18:41:52 -0500
Date: 24 Aug 1999 18:41:52 -0500
From: Martin Soto masoto@uniandes.edu.co
Subject: [Livid-dev] Sigma Designs- How can we help?
Marshall Goldberg <mgoldberg@sdesigns.com> writes:
> My confusion, I think, comes from other developers who are insistent
> that our product will be completely useless if we cannot release all of
> the source to the device driver. If our Linux product is "useless"
> without a release of all source code, and our licenses prevent us from
> doing so, then there's not much point in getting on the Linux bandwagon.
Well at least in my case, I have to say that although I appreciate
open source and would like to encourage it whenever possible, I
clearly understand that the DVD licensing conditions are quite
restrictive and that other solutions must be worked out. I would
summarize my proposal to Sigma (and any other interested parties) as
follows:
- Sigma releases the specs for those components of the cards that can
be supported openly *without compromising the confidentiality of the
DVD Specification*. The MPEG decoder and the sound output
interfaces seem to be amongst these components.
- A group of open source developers works on developing drivers for
these components. I personally volunteer for coordinating the
effort, at least regarding DXR3/H+ cards.
- The open sourced code is released with a license *that allows it to
be linked with certain kinds of closed source code*. The purpose
would be to allow the open source driver to interoperate with a CSS
implementation or any other DVD specific modules necessary for a
complete DVD implementation. The LSDVD Project (by the way, Paul,
thanks for the explanation), Sigma Designs or any other DVD licensee
would be able to provide these modules if the necessary security
conditions are met.
IMO, doing things this way will satisfy must open source fans. I only
hope they are workable for DVD licensees as well.
Regards,
M. S.
------------
Martin A. Soto J. Profesor
Departamento de Ingenieria de Sistemas y Computacion
Universidad de los Andes masoto@uniandes.edu.co
From mgoldberg@sdesigns.com Wed, 25 Aug 1999 13:13:28 -0700
Date: Wed, 25 Aug 1999 13:13:28 -0700
From: Marshall Goldberg mgoldberg@sdesigns.com
Subject: [Livid-dev] Sigma Designs- Old chip, new chip
The first thing we will do is support the new EM 8400 chip. That much is
for sure. This is a process of engineering. There are "unknowns" in
engineering, so we can't commit to everything. We have no commitment
right now to supporting the EM 8300 chip under Linux, and all
indications at the moment are that we won't, because the new chip is the
"latest and greatest," and, geez, it's not like we charge a lot of money
for the boards.
As I said, we'll surely support and publish an API. Maybe it will be a
"standard" API, in that it will be the same as other decoders, and maybe
it won't. That is kind of unknown, and that's why we collaborate over
the Internet like this, to find out what everybody wants.
But, the design goal is not to produce a monolithic driver/application
which is only for DVD playback. We also have a lot of experience in
MPEG-1 and MPEG-2 playback, which I can see that many readers on this
list are unaware of.
For example, in the Windows world, we have sold about 42,000 decoders to
two large brokerage firms, and they are used for playing IP Multicast
MPEG on the brokers' desktops. We sold about 9,000 boards to Wall-Mart
stores, where they are used in interactive kiosks in the TV department.
Hughes Network Systems uses our boards for IP Multicast-over-satellite
solutions.
We have very good relationships with most video server companies, who
have developed client software (Windows browser plug-ins, mostly) for
their video servers. This includes the Oracle Video Server, the SGI
MediaBase, Microsoft NetShow Theater, VSoft VideoClick, FVC.COM VCache
and VCaster, InfoValue QuickVideo, and on and on. So we also have a lot
of support for MPEG-2 over IP and over ATM. And this is all for
deployments we've made in various ways. That's what we spend a lot of
time doing.
So, you see, we have a wider design goal than simply supporting
DVD-Video playback, and this requires a lot of robustness and a
documented, published API.
There are lots of developer opportunities here in the wide-open world of
Linux, I'd say.
Food for thought,
Marshall Goldberg
Sigma Designs
From mgoldberg@sdesigns.com Wed, 25 Aug 1999 13:23:07 -0700
Date: Wed, 25 Aug 1999 13:23:07 -0700
From: Marshall Goldberg mgoldberg@sdesigns.com
Subject: [Livid-dev] Sigma Designs- How can we help?
>> Where does Macrovision get implemented in the decoder card, Marshall?
The
overlay chip or in a separate S-VideoTV out chip that does all the
refresh
rate and interlacing stuff as well? <<
Macrovision is enabled by the TV encoder chip, which on our boards is an
Analog Devices 727x-series part.
Marshall
From aholtzma@ess4.engr.UVic.CA Wed, 25 Aug 1999 20:36:43 -0700
Date: Wed, 25 Aug 1999 20:36:43 -0700
From: Aaron Holtzman aholtzma@ess4.engr.UVic.CA
Subject: [Livid-dev] Sigma Designs- How can we help?
Here's my crazy idea for the day. Perhaps a hypothetical established
company in the DVD business could put forth a proposal to the DVD-forum
to loosen licensing restrictions on the DVD-Specs. In this manner we
could permit open-source navigation implementations. I'm not exactly
sure what they're trying to protect here...DVD technology isn't exactly
rocket science. I guess it's more of a control thing. Anyways, it can't
hurt to ask :)
cheers,
aaron
From lom@orion.imp Wed, 25 Aug 1999 23:04:34 +0200 (CEST)
Date: Wed, 25 Aug 1999 23:04:34 +0200 (CEST)
From: lom@orion.imp lom@orion.imp
Subject: [Livid-dev] Sigma Designs- How can we help?
Just a note:
If the you must make binary only drivers you will have to keep up with all
Linux versions, that could be _very_ much work. Lots of people run linux
verisons like 2.2.11-ac3 with SMP enabled for an example. The driver must
be in at least two version for each linux version SMP and non SMP..
The linux people does NOT consider internal backwards compability when
doing changes in the kernel. Please look at Linus Torvals notes on binary
only kernel-drivers ( http://lwn.net/1999/0211/a/lt-afs.html and
http://lwn.net/1999/0211/a/lt-binary.html ).
> My confusion, I think, comes from other developers who are insistent
> that our product will be completely useless if we cannot release all of
> the source to the device driver. If our Linux product is "useless"
> without a release of all source code, and our licenses prevent us from
> doing so, then there's not much point in getting on the Linux bandwagon.
>
> Marshall Goldberg
> ---------------------
> Director of Product Marketing
> Sigma Designs, Inc.
> 355 Fairview Way
> Milpitas, CA 95035-3024
> e-mail: mgoldberg@sdesigns.com
>
>
> _______________________________________________
> Livid-dev maillist - Livid-dev@livid.on.openprojects.net
> http://livid.on.openprojects.net/mailman/listinfo/livid-dev
>
From pvolcko@concentric.net Wed, 25 Aug 1999 17:59:30 -0400 (EDT)
Date: Wed, 25 Aug 1999 17:59:30 -0400 (EDT)
From: pvolcko@concentric.net pvolcko@concentric.net
Subject: [Livid-dev] Sigma Designs- How can we help?
What about that company though? Unless the had some real pull in the
industry, they threaten their relationship with the DVD Forum by setting
forth the proposal, potentially.
On Wed, 25 Aug 1999, Aaron Holtzman wrote:
> Here's my crazy idea for the day. Perhaps a hypothetical established
> company in the DVD business could put forth a proposal to the DVD-forum
> to loosen licensing restrictions on the DVD-Specs. In this manner we
> could permit open-source navigation implementations. I'm not exactly
> sure what they're trying to protect here...DVD technology isn't exactly
> rocket science. I guess it's more of a control thing. Anyways, it can't
> hurt to ask :)
>
> cheers,
> aaron
>
>
> _______________________________________________
> Livid-dev maillist - Livid-dev@livid.on.openprojects.net
> http://livid.on.openprojects.net/mailman/listinfo/livid-dev
>
From derek@spider.com Thu, 26 Aug 1999 10:25:19 +0100
Date: Thu, 26 Aug 1999 10:25:19 +0100
From: Derek Fawcus derek@spider.com
Subject: [Livid-dev] Sigma Designs- How can we help?
On Wed, Aug 25, 1999 at 11:04:34PM +0200, lom@orion.imp wrote:
>
> Just a note:
>
> If the you must make binary only drivers you will have to keep up with all
> Linux versions, that could be _very_ much work. Lots of people run linux
> verisons like 2.2.11-ac3 with SMP enabled for an example. The driver must
> be in at least two version for each linux version SMP and non SMP..
> The linux people does NOT consider internal backwards compability when
> doing changes in the kernel. Please look at Linus Torvals notes on binary
> only kernel-drivers ( http://lwn.net/1999/0211/a/lt-afs.html and
> http://lwn.net/1999/0211/a/lt-binary.html ).
I don't see that this will cause a problem. Most of the things that they
will wish to keep secret should be at the application level. Any drivers
are going to be fairly simple and so there shouldn't be an issue with making
them open source. Since the binaries he's talking about distributing are
application level libraries, and since binary compatibility in user mode
_is_ maintained between kernel versions, all should be ok.
DF
>
>
> > My confusion, I think, comes from other developers who are insistent
> > that our product will be completely useless if we cannot release all of
> > the source to the device driver. If our Linux product is "useless"
> > without a release of all source code, and our licenses prevent us from
> > doing so, then there's not much point in getting on the Linux bandwagon.
> >
> > Marshall Goldberg
> > ---------------------
> > Director of Product Marketing
> > Sigma Designs, Inc.
> > 355 Fairview Way
> > Milpitas, CA 95035-3024
> > e-mail: mgoldberg@sdesigns.com
> >
> >
> > _______________________________________________
> > Livid-dev maillist - Livid-dev@livid.on.openprojects.net
> > http://livid.on.openprojects.net/mailman/listinfo/livid-dev
> >
>
--
Derek Fawcus derek@spider.com
Spider Software Ltd. +44 (0) 131 475 7034