HW+ / DXR3 device driver for Linux

Hi,

On Wed, Sep 21, 2005 at 07:52:26PM -0400, Derrik Pates wrote:
> All:
> 
> I haven't submitted an updated patch against the recent em8300 sources
> to add support for RGB and YUV modes for the ADV717x video
> encoder-equipped boards. I can verify that with the component out cable
> available direct from Sigma Designs (see
> http://www.sigmadesigns.com/products/cables_accessories.htm)

You mean the cable with part number 22-000213-01? As far as I can see, 
it's not advertised to work with Hollywood Plus boards...


> and the
> patch, you can get YUV component out with no modifications to the board.
> RGB mode with a separate sync pin, however, would require board mods
> which I do not know how to do - I leave this to you, dear reader.

All that sounds nice! :-)


> Also note that progressive mode doesn't quite work as it should right at
> the moment - I'll have to look over the docs for the ADV717x encoder
> chips and see if I can determine why. And to the developers - the
> "->rgbmode" flag caused the wrong register bit to be flipped on the
> ADV717[01] encoders. This patch rips that out, and really completely
> supplants what it does, since it supports more than just RGB out.

I just had a look at the data-sheet for the adv7175a chip.

About bit M10, I read:
"
 Interlaced Mode Control (M10)
 This bit is used to set up the output to interlaced or non interlaced 
 mode. This mode is only relevant when the part is in composite video 
 mode.
"
If I understand it correctly, it seems to mean that progressive scan 
will only work for composite video, not for YUV or RGB...


Next, If I guess properly, the standard cable use the output of DAC B 
for composite video, the output of DAC C for chrominance, and the output 
of DAC D for luminance. If this is right, then it means that setting the 
MR37 bit would result to sending the composite video signal on the 
luminance pin of the s-video connector. Some people get cheap "s-video 
to RCA converters" that use the luma pin of the s-video connector as a 
composite video signal. If I am right, then with such a config, they 
would get real composite video out of their "converter"... Then it would 
probably be worth adding a now "composite video over s-video"... :-)
Is anyone able to check?


Cheers,

Nicolas

On Tue, Sep 27, 2005 at 01:54:31AM +0200, Nicolas Boullis wrote:
> You mean the cable with part number 22-000213-01? As far as I can see, 
> it's not advertised to work with Hollywood Plus boards...

That's the one. It's only not listed as working with the Hollywood+
boards because Sigma's drivers don't let you turn on component-out
modes on the ADV717x video encoders - I would imagine because not
every Hollywood+ board is outfitted with one (some have a BT865 encoder
chip instead). I have one connected from my Creative DXr3 board to my
HD set, so I can confirm that it really does work, with no modifications.

> I just had a look at the data-sheet for the adv7175a chip.
> 
> About bit M10, I read:
> "
>  Interlaced Mode Control (M10)
>  This bit is used to set up the output to interlaced or non interlaced 
>  mode. This mode is only relevant when the part is in composite video 
>  mode.
> "
> If I understand it correctly, it seems to mean that progressive scan 
> will only work for composite video, not for YUV or RGB...

I can't see how progressive scan would work via composite. I assumed that
was some sort of documentation error (wouldn't be the first time something
like that happened). At least, I've never heard of any TV set supporting
progressive over composite.

> Next, If I guess properly, the standard cable use the output of DAC B 
> for composite video, the output of DAC C for chrominance, and the output 
> of DAC D for luminance.

Based on my reading of the datasheets, and my looking at the traces on
my board, that's affirmative. I also tried using the restricted DAC output
modees with a previous iteration of this patch (back about v0.12.0 of the
em8300 drivers, I think), and that proved to be correct.

-- 
Derrik Pates
demon@...

Hi,

On Mon, Sep 26, 2005 at 10:40:44PM -0400, Derrik Pates wrote:
> On Tue, Sep 27, 2005 at 01:54:31AM +0200, Nicolas Boullis wrote:
> > You mean the cable with part number 22-000213-01? As far as I can see, 
> > it's not advertised to work with Hollywood Plus boards...
> 
> That's the one. It's only not listed as working with the Hollywood+
> boards because Sigma's drivers don't let you turn on component-out
> modes on the ADV717x video encoders - I would imagine because not
> every Hollywood+ board is outfitted with one (some have a BT865 encoder
> chip instead).

Your point about bt865 chips is good. DO you know for sure that bt865 
chips can't do YUV or RGB output?


> I have one connected from my Creative DXr3 board to my
> HD set, so I can confirm that it really does work, with no modifications.

That's good to know. :-)


> > I just had a look at the data-sheet for the adv7175a chip.
> > 
> > About bit M10, I read:
> > "
> >  Interlaced Mode Control (M10)
> >  This bit is used to set up the output to interlaced or non interlaced 
> >  mode. This mode is only relevant when the part is in composite video 
> >  mode.
> > "
> > If I understand it correctly, it seems to mean that progressive scan 
> > will only work for composite video, not for YUV or RGB...
> 
> I can't see how progressive scan would work via composite. I assumed that
> was some sort of documentation error (wouldn't be the first time something
> like that happened). At least, I've never heard of any TV set supporting
> progressive over composite.

To be honnest, I have no HD set, and I know close to nothing about 
progressive scan. Why would pogressive scan be more or less achievable 
with composite video than with s-video, yuv our rgb?


> > Next, If I guess properly, the standard cable use the output of DAC B 
> > for composite video, the output of DAC C for chrominance, and the output 
> > of DAC D for luminance.
> 
> Based on my reading of the datasheets, and my looking at the traces on
> my board, that's affirmative.

That's good news.


> I also tried using the restricted DAC output
> modees with a previous iteration of this patch (back about v0.12.0 of the
> em8300 drivers, I think), and that proved to be correct.

Sorry, I can't understand what you mean here.

Anyway, if that works, would you consider adding this "composite video 
over s-video" mode to your patch?


Cheers,

Nicolas

Hi!

On 9/27/05, Nicolas Boullis <nboullis@...> wrote:
>
> Hi,
>
> On Mon, Sep 26, 2005 at 10:40:44PM -0400, Derrik Pates wrote:
> > On Tue, Sep 27, 2005 at 01:54:31AM +0200, Nicolas Boullis wrote:
> > > You mean the cable with part number 22-000213-01? As far as I can see=
,
> > > it's not advertised to work with Hollywood Plus boards...
> >
> > That's the one. It's only not listed as working with the Hollywood+
> > boards because Sigma's drivers don't let you turn on component-out
> > modes on the ADV717x video encoders - I would imagine because not
> > every Hollywood+ board is outfitted with one (some have a BT865 encoder
> > chip instead).
>
> Your point about bt865 chips is good. DO you know for sure that bt865
> chips can't do YUV or RGB output?


No, the bt865 CAN do RGB, the problem is that Creative decided not to use
that function and a hardware hack is needed.
I have a page that explains that:
http://www.geocities.com/lfcorreia/dxr3-1.html

Luis Correia

On Wed, 2005-09-21 at 19:52 -0400, Derrik Pates wrote:

> I can verify that with the component out cable
> available direct from Sigma Designs (see
> http://www.sigmadesigns.com/products/cables_accessories.htm) and the
> patch, you can get YUV component out with no modifications to the board.

Mmm, very interesting.  Anybody know any other places (preferrably in
Europe, even better if in Finland) where to buy these?  IMO $28 (+
possibly VAT) is a bit steep for shipping & handling for such a little
$10 cable...

Hi,

On Thu, Sep 29, 2005 at 10:52:09PM +0300, Ville Skytt=C3=A4 wrote:
> On Wed, 2005-09-21 at 19:52 -0400, Derrik Pates wrote:
>=20
> > I can verify that with the component out cable
> > available direct from Sigma Designs (see
> > http://www.sigmadesigns.com/products/cables_accessories.htm) and the
> > patch, you can get YUV component out with no modifications to the boa=
rd.
>=20
> Mmm, very interesting.  Anybody know any other places (preferrably in
> Europe, even better if in Finland) where to buy these?  IMO $28 (+
> possibly VAT) is a bit steep for shipping & handling for such a little
> $10 cable...

I guess it might be easy (and hopefully cheaper) to build one for=20
yourself if you can solder.


Nicolas

Hi,

On Wed, Sep 28, 2005 at 12:59:01AM +0200, Nicolas Boullis wrote:
> 
> Anyway, if that works, would you consider adding this "composite video 
> over s-video" mode to your patch?

OK, I did it myself. Here is the resulting patch. I also made the choice 
to give names to the modes rather than use somewhat obscure numbers.
(Note that I did not update the doc...)

Please give it a try; all comments are welcome.


Cheers,

Nicolas

On Wed, Sep 28, 2005 at 10:08:24AM +0100, Luis Correia wrote:
> 
> No, the bt865 CAN do RGB, the problem is that Creative decided not to use
> that function and a hardware hack is needed.
> I have a page that explains that:
> http://www.geocities.com/lfcorreia/dxr3-1.html

You're quite right, and the bt865 already even supports that.
The bad news is that other modes supported with adv717x chips are not 
supported here.


Cheers,

Nicolas

Hmmmm... As usual, I forgot to attach the promised patch. Here it is.

On Tue, 2005-10-04 at 00:34 +0200, Nicolas Boullis wrote:
> On Thu, Sep 29, 2005 at 10:52:09PM +0300, Ville Skytt=C3=A4 wrote:
> >=20
> > Mmm, very interesting.  Anybody know any other places (preferrably in
> > Europe, even better if in Finland) where to buy these?  IMO $28 (+
> > possibly VAT) is a bit steep for shipping & handling for such a littl=
e
> > $10 cable...
>=20
> I guess it might be easy (and hopefully cheaper) to build one for=20
> yourself if you can solder.

Yep, I got that suggestion in PM too.  But the thing is that I really
suck in soldering, and that cable would potentially be used to connect
to a pretty expensive TV, so I'd feel more comfortable with just buying
one ;)

On Tue, Oct 04, 2005 at 08:40:57AM +0300, Ville Skyttä wrote:
> On Tue, 2005-10-04 at 00:34 +0200, Nicolas Boullis wrote:
> > I guess it might be easy (and hopefully cheaper) to build one for 
> > yourself if you can solder.
> 
> Yep, I got that suggestion in PM too.  But the thing is that I really
> suck in soldering, and that cable would potentially be used to connect
> to a pretty expensive TV, so I'd feel more comfortable with just buying
> one ;)

I thought I'd be able to build a cable - but I've found that the 7-pin
MiniDIN connector that's used to connect to the DXr3/H+ board is rather
hard to come by.

-- 
Derrik Pates
demon@...

On Thu, Oct 06, 2005 at 07:05:05AM -0400, Derrik Pates wrote:
> On Tue, Oct 04, 2005 at 08:40:57AM +0300, Ville Skytt=C3=A4 wrote:
> > On Tue, 2005-10-04 at 00:34 +0200, Nicolas Boullis wrote:
> > > I guess it might be easy (and hopefully cheaper) to build one for=20
> > > yourself if you can solder.
> >=20
> > Yep, I got that suggestion in PM too.  But the thing is that I really
> > suck in soldering, and that cable would potentially be used to connec=
t
> > to a pretty expensive TV, so I'd feel more comfortable with just buyi=
ng
> > one ;)
>=20
> I thought I'd be able to build a cable - but I've found that the 7-pin
> MiniDIN connector that's used to connect to the DXr3/H+ board is rather
> hard to come by.

Hmmm, that's bad news, as I was thinking about hacking by board to=20
connect the output of the 4th DAC to the 7th pin of the mini-DIN socket,=20
and then solder a 7-pin mini-DIN to SCART cable to get RGB playback...


Nicolas

On 10/8/05, Nicolas Boullis <nboullis@...> wrote:
>
> On Thu, Oct 06, 2005 at 07:05:05AM -0400, Derrik Pates wrote:
> > On Tue, Oct 04, 2005 at 08:40:57AM +0300, Ville Skytt=E4 wrote:
> > > On Tue, 2005-10-04 at 00:34 +0200, Nicolas Boullis wrote:
> > > > I guess it might be easy (and hopefully cheaper) to build one for
> > > > yourself if you can solder.
> > >
> > > Yep, I got that suggestion in PM too. But the thing is that I really
> > > suck in soldering, and that cable would potentially be used to connec=
t
> > > to a pretty expensive TV, so I'd feel more comfortable with just
> buying
> > > one ;)
> >
> > I thought I'd be able to build a cable - but I've found that the 7-pin
> > MiniDIN connector that's used to connect to the DXr3/H+ board is rather
> > hard to come by.
>
> Hmmm, that's bad news, as I was thinking about hacking by board to
> connect the output of the 4th DAC to the 7th pin of the mini-DIN socket,
> and then solder a 7-pin mini-DIN to SCART cable to get RGB playback...
>
>
> Nicolas


If you don't use the VGA passthrough, you can follow my hack and use the VG=
A
plug itself. But beware that the change is almost irreversible...

Luis

Hi,

would anyone please give this patch a try?


Nicolas

On Wed, 2005-10-19 at 01:39 +0200, Nicolas Boullis wrote:

> would anyone please give this patch a try?

I have an ADV7170 based card and I think I have one of those dummy
S-Video-to-composite cables around somewhere that don't really convert
from S-Video to composite (and so result in black and white in the TV at
least with some S-Video outs, not sure about the DXR3).

Does this patch address that in any way, and if yes, what would I set
output_mode to in order to get all the colors on the TV using the above
cable?  1?

Hi,

On Thu, Oct 20, 2005 at 08:50:53AM +0300, Ville Skytt=C3=A4 wrote:
> On Wed, 2005-10-19 at 01:39 +0200, Nicolas Boullis wrote:
>=20
> > would anyone please give this patch a try?
>=20
> I have an ADV7170 based card and I think I have one of those dummy
> S-Video-to-composite cables around somewhere that don't really convert
> from S-Video to composite (and so result in black and white in the TV a=
t
> least with some S-Video outs, not sure about the DXR3).
>=20
> Does this patch address that in any way, and if yes, what would I set
> output_mode to in order to get all the colors on the TV using the above
> cable?  1?

Yes, it does address this. I did not update the documentation, but names=20
are used instead of numeric values.
Your cable probably uses the luma pin as if it were video composite. So=20
you should probably use "output_mode=3Dcomposvideo" (as "COMPosite Over=20
SVIDEO"), or "output_mode=3Dpsvideo" (as "Pseudo S-VIDEO") if you want to=
=20
swith freely between (dirty) s-video and composite over s-video, or=20
"output_mode=3Dcomp+psvideo" if you also want to be able to use a "good"=20
H+/DXR3 -> composite cable.

By the way, I think that also it provides some "dirty" s-video signal,=20
"output_mode=3Dcomp+psvideo" might become the defaults as it is supposed=20
to work better for those who use such crappy S-Video-to-composite=20
cables.

Oh, and I also might drop the "progressive" modes if nobody tells me=20
that it brings any good.


Cheers,

Nicolas

On Fri, 2005-10-21 at 01:09 +0200, Nicolas Boullis wrote:
> Hi,
>=20
> On Thu, Oct 20, 2005 at 08:50:53AM +0300, Ville Skytt=C3=A4 wrote:
> > On Wed, 2005-10-19 at 01:39 +0200, Nicolas Boullis wrote:
> >=20
> > > would anyone please give this patch a try?
> >=20
> > I have an ADV7170 based card and I think I have one of those dummy
> > S-Video-to-composite cables around somewhere that don't really conver=
t
> > from S-Video to composite (and so result in black and white in the TV=
 at
> > least with some S-Video outs, not sure about the DXR3).
> >=20
> > Does this patch address that in any way, and if yes, what would I set
> > output_mode to in order to get all the colors on the TV using the abo=
ve
> > cable?  1?
>=20
> Yes, it does address this. I did not update the documentation, but name=
s=20
> are used instead of numeric values.

Ok.  I got around to test this, but only with a regular S-Video cable
for now, will keep an eye on a S-Video to composite cable and test with
it if I find it.  Basically, seems to work as usual with S-Video.

> By the way, I think that also it provides some "dirty" s-video signal,=20
> "output_mode=3Dcomp+psvideo" might become the defaults as it is suppose=
d=20
> to work better for those who use such crappy S-Video-to-composite=20
> cables.

Hm.  You probably already knew it, but the picture quality appears to be
significantly worse here when using the *psvideo modes compared to
*svideo.  Given that and my gut feeling that there's more people using
S-Video or "proper" S-Video-to-composite cables than the crappy ones,
I'd like to place my biased vote for keeping comp+svideo the default,
and prominently document other possibilities (including info about the
dummy cables).

Oh, and it could be nice to have the selected output mode displayed via
procfs.  I wonder if it'd make sense or be possible to switch between
the modes on the fly, without rmmod/insmod?

Hi,

On Sat, Oct 22, 2005 at 08:04:29PM +0300, Ville Skytt=C3=A4 wrote:
>=20
> Ok.  I got around to test this, but only with a regular S-Video cable
> for now, will keep an eye on a S-Video to composite cable and test with
> it if I find it.  Basically, seems to work as usual with S-Video.

OK.


> Hm.  You probably already knew it, but the picture quality appears to b=
e
> significantly worse here when using the *psvideo modes compared to
> *svideo.

Well, I did not notice any visible difference. It may be that the=20
behavior with such broken s-video signal is highly device-dependant, or=20
that my eyesight is not that good...


> Given that and my gut feeling that there's more people using
> S-Video or "proper" S-Video-to-composite cables than the crappy ones,
> I'd like to place my biased vote for keeping comp+svideo the default,
> and prominently document other possibilities (including info about the
> dummy cables).

OK, I'll follow your suggestion. But the documentation remains to be=20
updated/written... Would anyone volunteer?


> Oh, and it could be nice to have the selected output mode displayed via
> procfs.  I wonder if it'd make sense or be possible to switch between
> the modes on the fly, without rmmod/insmod?

Displaying the output mode via procfs (or sysfs) should be quite easy.=20
Switching on the fly should also be feasible, but is it really worth it?=20
I don't think that many people change their cabling that often...


Cheers,

Nicolas

On Sat, 2005-10-22 at 23:43 +0200, Nicolas Boullis wrote:
> On Sat, Oct 22, 2005 at 08:04:29PM +0300, Ville Skytt=C3=A4 wrote:
> >=20
> > Given that and my gut feeling that there's more people using
> > S-Video or "proper" S-Video-to-composite cables than the crappy ones,
> > I'd like to place my biased vote for keeping comp+svideo the default,
> > and prominently document other possibilities (including info about th=
e
> > dummy cables).
>=20
> OK, I'll follow your suggestion. But the documentation remains to be=20
> updated/written... Would anyone volunteer?

I think I could lend a hand there, but first it should be known which
parts of this patch will be committed...

> > Oh, and it could be nice to have the selected output mode displayed v=
ia
> > procfs.  I wonder if it'd make sense or be possible to switch between
> > the modes on the fly, without rmmod/insmod?
>=20
> Displaying the output mode via procfs (or sysfs) should be quite easy.=20
> Switching on the fly should also be feasible, but is it really worth it=
?=20
> I don't think that many people change their cabling that often...

I don't know, just asked because it crossed my mind at the time.

Hi,

On Wed, Oct 26, 2005 at 06:06:28PM +0300, Ville Skytt=C3=A4 wrote:
> On Sat, 2005-10-22 at 23:43 +0200, Nicolas Boullis wrote:
> > On Sat, Oct 22, 2005 at 08:04:29PM +0300, Ville Skytt=C3=A4 wrote:
> > >=20
> > > Given that and my gut feeling that there's more people using
> > > S-Video or "proper" S-Video-to-composite cables than the crappy one=
s,
> > > I'd like to place my biased vote for keeping comp+svideo the defaul=
t,
> > > and prominently document other possibilities (including info about =
the
> > > dummy cables).
> >=20
> > OK, I'll follow your suggestion. But the documentation remains to be=20
> > updated/written... Would anyone volunteer?
>=20
> I think I could lend a hand there, but first it should be known which
> parts of this patch will be committed...

I guess I will drop the "progressive" modes, as it seems that they do no=20
good. Apart from that, and the documentation, I think I will commit the=20
patch as is.


> > > Oh, and it could be nice to have the selected output mode displayed=
 via
> > > procfs.  I wonder if it'd make sense or be possible to switch betwe=
en
> > > the modes on the fly, without rmmod/insmod?
> >=20
> > Displaying the output mode via procfs (or sysfs) should be quite easy=
.=20
> > Switching on the fly should also be feasible, but is it really worth =
it?=20
> > I don't think that many people change their cabling that often...
>=20
> I don't know, just asked because it crossed my mind at the time.

I guess I'll try to implment it if someone asks for it with some=20
justification.


Cheers,

Nicolas

On Tue, 2005-11-01 at 01:07 +0100, Nicolas Boullis wrote:
> Hi,

Hi,

I found the crappy S-Video->composite cable I was talking about, and I
can confirm that the patch works so that with composvideo and *psvideo I
get colors on the TV with it.  Without the patch, things were black and
white.

> On Wed, Oct 26, 2005 at 06:06:28PM +0300, Ville Skytt=C3=A4 wrote:
> > On Sat, 2005-10-22 at 23:43 +0200, Nicolas Boullis wrote:
> >=20
> > > OK, I'll follow your suggestion. But the documentation remains to b=
e=20
> > > updated/written... Would anyone volunteer?
> >=20
> > I think I could lend a hand there, but first it should be known which
> > parts of this patch will be committed...
>=20
> I guess I will drop the "progressive" modes, as it seems that they do n=
o=20
> good. Apart from that, and the documentation, I think I will commit the=
=20
> patch as is.

Ok.  Feel free to commit, I'll follow up with some docs.

By the way, I re-checked the picture quality thing with *psvideo versus
svideo using a S-Video cable, and it's indeed quite a bit worse with
*psvideo.  A couple of pictures here, the psvideo one is from slightly
closer up than the other, and the camera appears to exaggerate the
difference somewhat, but it's definitely there (no other changes than
just the module parameter):
http://koti.welho.com/vskytta/tmp/svideo-with-comp+psvideo.jpg
http://koti.welho.com/vskytta/tmp/svideo-with-svideo.jpg