TV-Out on a GeForce 2MX supported?

TV-Out on a GeForce 2MX supported?

[Nils Krafft]

Hello,

I have here a GeForce 2MX (NV10) with a Brooktree BT869 chip for the
TV-Out.

Is the TV-Out on this card supported by Nouveau? I read on the feature
matrix something that the TV-Out is only supported for some Chrontel
chips, furthermore

xrandr -q

shows me only the DVI connection (in fact it's VGA, not DVI), but not
the S-Video connection. If not supported, is this planned for future
versions?

I'm using the Nouveau X-server 1.0.1 and kernel 3.2.0 on Debian
Wheezy.


Thanks in advance for your help,
Nils

Re: TV-Out on a GeForce 2MX supported?

[Ilia Mirkin]

On Mon, Mar 3, 2014 at 5:41 PM, Nils Krafft <fehmarn-rund-6WyM7rXn5Gg@public.gmane.org> wrote:
> Hello,
>
> I have here a GeForce 2MX (NV10) with a Brooktree BT869 chip for the
> TV-Out.

http://nouveau.freedesktop.org/wiki/FeatureMatrix/

See note #4 -- nv0x-nv2x (nv17-nv19 excluded) need an external,
third-party manufactured TV encoder. Only some Chrontel branded chips
are currently supported.

> shows me only the DVI connection (in fact it's VGA, not DVI), but not
> the S-Video connection. If not supported, is this planned for future
> versions?

The relevant hardware is not easily available, nor is hardware to
consume s-video/composite connections. This sort of thing is probably
only going to be supported if you make it happen. If you're
interested, the relevant source file is
drivers/gpu/drm/nouveau/dispnv04/tvnv04.c, and you'd have to add
something in drivers/gpu/drm/i2c. BT* chips are usually easy to find
docs for, and some of the additional details can probably be worked
out from mmiotraces, assuming you can find a kernel that the blob
driver will load on.

  -ilia

Re: TV-Out on a GeForce 2MX supported?

[Dirk Thierbach]

On Wed, Mar 05, 2014 at 12:40:34AM -0500, Ilia Mirkin wrote:
> On Mon, Mar 3, 2014 at 5:41 PM, Nils Krafft <fehmarn-rund-6WyM7rXn5Gg@public.gmane.org> wrote:
> > I have here a GeForce 2MX (NV10) with a Brooktree BT869 chip for the
> > TV-Out.

You can try nvtv (http://sourceforge.net/projects/nv-tv-out/). It bypasses
X and modesetting and programs the Brooktree and CRTC directly. I've
no idea if it still work with modern X and/or nouveau. :-)

> > shows me only the DVI connection (in fact it's VGA, not DVI), but not
> > the S-Video connection. If not supported, is this planned for future
> > versions?

> The relevant hardware is not easily available, nor is hardware to
> consume s-video/composite connections. 

I still have some hardware for both, though I haven't used it for a long
time.

> This sort of thing is probably
> only going to be supported if you make it happen. If you're
> interested, the relevant source file is
> drivers/gpu/drm/nouveau/dispnv04/tvnv04.c, and you'd have to add
> something in drivers/gpu/drm/i2c. BT* chips are usually easy to find
> docs for, and some of the additional details can probably be worked
> out from mmiotraces, assuming you can find a kernel that the blob
> driver will load on.

It's much better to work from the datasheet instead of doing mmiotraces,
the blob only has a few modes built-in.

The BT is actually a very flexible chip, and supports a very wide range
of modes with different overscan amount, plus different filtering options.

It probably wouldn't be hard to just take a few modes from nvtv and
put them into nouveau, similar to the (very few) Chrontel modes. What's 
missing is some sort of infrastructure in X to say "look, on this hardware
there are these two functional blocks (CRTC + BT), I would like to program
with the following values, and I've specified the values in the config
file, or I'm a user space program and provide these values over some X
extension".

This is even more effort now that modesetting is in the kernel (back
when nvtv was written, it wasn't).

Without this, you are pretty much stuck with precalculated modes.
Which isn't optimal, because with small overscan the timing gets a bit
fickle, and with larger overscan you get the ugly border, and every
analog TV is different in that respect.

- Dirk

Re: TV-Out on a GeForce 2MX supported?

[Ilia Mirkin]

On Wed, Mar 5, 2014 at 6:06 AM, Dirk Thierbach <dthierbach-Mmb7MZpHnFY@public.gmane.org> wrote:
> On Wed, Mar 05, 2014 at 12:40:34AM -0500, Ilia Mirkin wrote:
>> On Mon, Mar 3, 2014 at 5:41 PM, Nils Krafft <fehmarn-rund-6WyM7rXn5Gg@public.gmane.org> wrote:
>> > I have here a GeForce 2MX (NV10) with a Brooktree BT869 chip for the
>> > TV-Out.
>
> You can try nvtv (http://sourceforge.net/projects/nv-tv-out/). It bypasses
> X and modesetting and programs the Brooktree and CRTC directly. I've
> no idea if it still work with modern X and/or nouveau. :-)
>
>> > shows me only the DVI connection (in fact it's VGA, not DVI), but not
>> > the S-Video connection. If not supported, is this planned for future
>> > versions?
>
>> The relevant hardware is not easily available, nor is hardware to
>> consume s-video/composite connections.
>
> I still have some hardware for both, though I haven't used it for a long
> time.
>
>> This sort of thing is probably
>> only going to be supported if you make it happen. If you're
>> interested, the relevant source file is
>> drivers/gpu/drm/nouveau/dispnv04/tvnv04.c, and you'd have to add
>> something in drivers/gpu/drm/i2c. BT* chips are usually easy to find
>> docs for, and some of the additional details can probably be worked
>> out from mmiotraces, assuming you can find a kernel that the blob
>> driver will load on.
>
> It's much better to work from the datasheet instead of doing mmiotraces,
> the blob only has a few modes built-in.
>
> The BT is actually a very flexible chip, and supports a very wide range
> of modes with different overscan amount, plus different filtering options.
>
> It probably wouldn't be hard to just take a few modes from nvtv and
> put them into nouveau, similar to the (very few) Chrontel modes. What's
> missing is some sort of infrastructure in X to say "look, on this hardware
> there are these two functional blocks (CRTC + BT), I would like to program
> with the following values, and I've specified the values in the config
> file, or I'm a user space program and provide these values over some X
> extension".
>
> This is even more effort now that modesetting is in the kernel (back
> when nvtv was written, it wasn't).
>
> Without this, you are pretty much stuck with precalculated modes.
> Which isn't optimal, because with small overscan the timing gets a bit
> fickle, and with larger overscan you get the ugly border, and every
> analog TV is different in that respect.

I actually checked this out last night, grabbed the BT869 datasheet.
Basically you'd have to implement something similar to the ch7006
driver (see drivers/gpu/drm/i2c), which provides an API for setting
modes (the BT869 appears to have 8 of them, of which I'm guessing only
4 are actually usable, probably the RGB ones). Then you'd need to work
out what the I2C index of it is, which you can tell by checking the
VBIOS. Of course, this all requires the relevant hardware.

The stuff about overscan/etc are exposed as KMS properties (which in
turn appear in xrandr) and not specific to the BT869. The i2c driver
is supposed to expose a ->mode_set() function, which takes a
drm_display_mode.

  -ilia

Re: TV-Out on a GeForce 2MX supported?

[Dirk Thierbach]

On Wed, Mar 05, 2014 at 12:46:04PM -0500, Ilia Mirkin wrote:
> I actually checked this out last night, grabbed the BT869 datasheet.
> Basically you'd have to implement something similar to the ch7006
> driver (see drivers/gpu/drm/i2c), which provides an API for setting
> modes (the BT869 appears to have 8 of them, of which I'm guessing only
> 4 are actually usable, probably the RGB ones). 

The 8 "modes" are just predefined sets of values, baked into the chip
for easier setup. There's basically an unlimited number of "modes",
with any resolution or overscan, subject to timing constraints.
Think modelines, but with more values and different registers.

BTW, the RGB modes only make sense if you have a special kind of 
connector. The PAL and NTSC modes are the ones that are normally used
on those cards. 

> The stuff about overscan/etc are exposed as KMS properties (which in
> turn appear in xrandr) and not specific to the BT869. 

The problem is that there's no good way to just say "I want this
overscan" and then get a valid set of register values, because of
the timing constraints. Nvtv includes a sort of "calculator" that
tries to calculate a collection of sets of sensible values as close
to a desired overscan as possible, but you still have to check (and
tweak, if necessary) every of those sets to see if it actually works.

> The i2c driver is supposed to expose a ->mode_set() function, which
> takes a drm_display_mode.

We had this discussion on the xorg mailing list back then, I think
even before there was kernel mode setting. In short, xrandr properties
and X-style modelines are just not enough to be able to program the
BT/CX chip sensibly. You need a different infrastructure.

As I said, as a workaround one can use a number of predefined modes
baked into the kernel. That's better than no support at all, but not as
good as being able to program the BT/CX chip freely.

And then there's the Philips TV encoder chip, which has a similar freedom
in programming.

Of course, given that analog TVs are dying out, the question is how
much effort one should put into this whole thing in the first place.

- Dirk

Re: TV-Out on a GeForce 2MX supported?

[Francisco Jerez]

[-- Attachment #1.1.1: Type: text/plain, Size: 3122 bytes --]

Dirk Thierbach <dthierbach-Mmb7MZpHnFY@public.gmane.org> writes:

>[...]
>> The stuff about overscan/etc are exposed as KMS properties (which in
>> turn appear in xrandr) and not specific to the BT869. 
>
> The problem is that there's no good way to just say "I want this
> overscan" and then get a valid set of register values, because of
> the timing constraints. Nvtv includes a sort of "calculator" that
> tries to calculate a collection of sets of sensible values as close
> to a desired overscan as possible, but you still have to check (and
> tweak, if necessary) every of those sets to see if it actually works.
>

It's been quite a while since the last time I messed about with this
code, but the TV encoders we already support (chrontel and nvidia's)
have similar limitations, and IIRC we solve it by doing two different
things:

1. We don't actually set the exact mode passed by the user.  Instead,
   the mode (both the CRTC mode and the final output mode) can be
   adjusted to the "closest" supported mode compatible with the
   hardware, given the specified properties.

2. For some properties (e.g. the TV standard) where making small
   adjustments to the "virtual" mode exposed to the user wouldn't work,
   (e.g. because the changes would involve changing the display
   width/height), we change the list of supported modes which is
   returned to userspace in response to a property change.

>> The i2c driver is supposed to expose a ->mode_set() function, which
>> takes a drm_display_mode.
>
> We had this discussion on the xorg mailing list back then, I think
> even before there was kernel mode setting. In short, xrandr properties
> and X-style modelines are just not enough to be able to program the
> BT/CX chip sensibly. You need a different infrastructure.
>
> As I said, as a workaround one can use a number of predefined modes
> baked into the kernel. That's better than no support at all, but not as
> good as being able to program the BT/CX chip freely.
>

The current model doesn't require the encoder driver to have a
predefined list of modes -- it's just highly recommended if you don't
want to force the user to input mode lines manually.  You just need some
means to compute the optimal timings algorithmically given the connector
properties and a rough description of the mode.  Sure, using a fixed
list of modes from which you pick the "closest" to the user's settings
might be the easiest way to achieve that on some chips [ch7006 does
precisely that IIRC], and that might be a slight underuse of the
flexibility of some hardware, but the API doesn't force you to do that.

> And then there's the Philips TV encoder chip, which has a similar freedom
> in programming.
>
> Of course, given that analog TVs are dying out, the question is how
> much effort one should put into this whole thing in the first place.
>
> - Dirk
>
>
> _______________________________________________
> Nouveau mailing list
> Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau

[-- Attachment #1.2: Type: application/pgp-signature, Size: 229 bytes --]

[-- Attachment #2: Type: text/plain, Size: 181 bytes --]

_______________________________________________
Nouveau mailing list
Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: TV-Out on a GeForce 2MX supported?

[Dirk Thierbach]

On Thu, Mar 06, 2014 at 12:00:28AM +0100, Francisco Jerez wrote:
> The current model doesn't require the encoder driver to have a
> predefined list of modes -- it's just highly recommended if you don't
> want to force the user to input mode lines manually.  

If there was a way to have the user input the equivalent of mode
lines for the BT chip, full support would be easy (and I would have
probably done it at some stage in the past). But the X infrastructure
just concerns itself with CRTC modelines (and later on added
xrandr properties), which are not enough.

> You just need some means to compute the optimal timings
> algorithmically given the connector properties and a rough
> description of the mode.

Which is the difficult part for the BT chip. While some of the timing
constraints are known, others are not. Also, there's no "optimal" solution,
what the calculation routine in nvtv does is to compute several
"close" solutions and let the user pick one. And sometimes they are
not even particularly close. Also, as I said, the solutions with very
little overscan sometimes don't give a stable image or no image at
all.

So calculating optimal timings in the kernel without user interaction
is not feasible. Unless you somehow discover the missing timing
constraints. Even the size of the internal FIFO is not known.

> Sure, using a fixed list of modes from which you pick the "closest"
> to the user's settings might be the easiest way to achieve that on
> some chips [ch7006 does precisely that IIRC],

The Chrontel chips only have a very limited number of modes in the
first place. But even then it makes sense to have more flexibiliy. For
example, you can take one of the 800x600 modes with almost no overscan
border, chop off the bottom and right and recenter shifting the sync
procesessing, and that gives you a nice 768x576 mode for watching
DVDs.

> and that might be a slight underuse of the
> flexibility of some hardware, but the API doesn't force you to do that.

Give me a way to pass a block of two dozen or so values to the chip in
addition to a CRTC modeline that is not checked for the usual constraints,
and give the user a way to specify these values in the config file or
let them choose one from a predefined list, and full support is easy.

- Dirk

Re: TV-Out on a GeForce 2MX supported?

[Nils Krafft]

Hi,

Ilia Mirkin <imirkin-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org> [Mi, 05.03.2014 12:46]:
> On Wed, Mar 5, 2014 at 6:06 AM, Dirk Thierbach <dthierbach-Mmb7MZpHnFY@public.gmane.org> wrote:
> > On Wed, Mar 05, 2014 at 12:40:34AM -0500, Ilia Mirkin wrote:
> >> On Mon, Mar 3, 2014 at 5:41 PM, Nils Krafft <fehmarn-rund-6WyM7rXn5Gg@public.gmane.org> wrote:
> >> > I have here a GeForce 2MX (NV10) with a Brooktree BT869 chip for the
> >> > TV-Out.
> >
> > You can try nvtv (http://sourceforge.net/projects/nv-tv-out/). It bypasses
> > X and modesetting and programs the Brooktree and CRTC directly. I've
> > no idea if it still work with modern X and/or nouveau. :-)
> >
> >> > shows me only the DVI connection (in fact it's VGA, not DVI), but not
> >> > the S-Video connection. If not supported, is this planned for future
> >> > versions?
> >
> >> The relevant hardware is not easily available, nor is hardware to
> >> consume s-video/composite connections.
> >
> > I still have some hardware for both, though I haven't used it for a long
> > time.
> >
> >> This sort of thing is probably
> >> only going to be supported if you make it happen. If you're
> >> interested, the relevant source file is
> >> drivers/gpu/drm/nouveau/dispnv04/tvnv04.c, and you'd have to add
> >> something in drivers/gpu/drm/i2c. BT* chips are usually easy to find
> >> docs for, and some of the additional details can probably be worked
> >> out from mmiotraces, assuming you can find a kernel that the blob
> >> driver will load on.
> >
> > It's much better to work from the datasheet instead of doing mmiotraces,
> > the blob only has a few modes built-in.
> >
> > The BT is actually a very flexible chip, and supports a very wide range
> > of modes with different overscan amount, plus different filtering options.
> >
> > It probably wouldn't be hard to just take a few modes from nvtv and
> > put them into nouveau, similar to the (very few) Chrontel modes. What's
> > missing is some sort of infrastructure in X to say "look, on this hardware
> > there are these two functional blocks (CRTC + BT), I would like to program
> > with the following values, and I've specified the values in the config
> > file, or I'm a user space program and provide these values over some X
> > extension".
> >
> > This is even more effort now that modesetting is in the kernel (back
> > when nvtv was written, it wasn't).
> >
> > Without this, you are pretty much stuck with precalculated modes.
> > Which isn't optimal, because with small overscan the timing gets a bit
> > fickle, and with larger overscan you get the ugly border, and every
> > analog TV is different in that respect.
> 
> I actually checked this out last night, grabbed the BT869 datasheet.
> Basically you'd have to implement something similar to the ch7006
> driver (see drivers/gpu/drm/i2c), which provides an API for setting
> modes (the BT869 appears to have 8 of them, of which I'm guessing only
> 4 are actually usable, probably the RGB ones). Then you'd need to work
> out what the I2C index of it is, which you can tell by checking the
> VBIOS. Of course, this all requires the relevant hardware.
> 
> The stuff about overscan/etc are exposed as KMS properties (which in
> turn appear in xrandr) and not specific to the BT869. The i2c driver
> is supposed to expose a ->mode_set() function, which takes a
> drm_display_mode.
> 
>   -ilia
> 

Meanwhile I fiddled about with nvtv and found out that it still works
fine. The trick is that I have to switch the X-server to the desired
TV-Out resolution before activating the TV-Out, otherwise the X-server
freezes.

Doing the TV-Out via xrandr and Xinerama would be much more
comfortable, but I understand that nowadays (with HDMI and such stuff)
S-Video is nearly a "dead horse", so it obviously does not make much
sense to spend great efforts here. But if anyone with sufficient
knowledge (i. e. not me...) has enough spare time and feels like doing
this, I would really appreciate it :-)

Thanks for your support and your work on Nouveau.


Regards,
Nils

Re: TV-Out on a GeForce 2MX supported?

[Ilia Mirkin]

On Wed, Mar 5, 2014 at 2:57 PM, Nils Krafft <fehmarn-rund-6WyM7rXn5Gg@public.gmane.org> wrote:
> Hi,
>
> Ilia Mirkin <imirkin-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org> [Mi, 05.03.2014 12:46]:
>> On Wed, Mar 5, 2014 at 6:06 AM, Dirk Thierbach <dthierbach-Mmb7MZpHnFY@public.gmane.org> wrote:
>> > On Wed, Mar 05, 2014 at 12:40:34AM -0500, Ilia Mirkin wrote:
>> >> On Mon, Mar 3, 2014 at 5:41 PM, Nils Krafft <fehmarn-rund-6WyM7rXn5Gg@public.gmane.org> wrote:
>> >> > I have here a GeForce 2MX (NV10) with a Brooktree BT869 chip for the
>> >> > TV-Out.
>> >
>> > You can try nvtv (http://sourceforge.net/projects/nv-tv-out/). It bypasses
>> > X and modesetting and programs the Brooktree and CRTC directly. I've
>> > no idea if it still work with modern X and/or nouveau. :-)
>> >
>> >> > shows me only the DVI connection (in fact it's VGA, not DVI), but not
>> >> > the S-Video connection. If not supported, is this planned for future
>> >> > versions?
>> >
>> >> The relevant hardware is not easily available, nor is hardware to
>> >> consume s-video/composite connections.
>> >
>> > I still have some hardware for both, though I haven't used it for a long
>> > time.
>> >
>> >> This sort of thing is probably
>> >> only going to be supported if you make it happen. If you're
>> >> interested, the relevant source file is
>> >> drivers/gpu/drm/nouveau/dispnv04/tvnv04.c, and you'd have to add
>> >> something in drivers/gpu/drm/i2c. BT* chips are usually easy to find
>> >> docs for, and some of the additional details can probably be worked
>> >> out from mmiotraces, assuming you can find a kernel that the blob
>> >> driver will load on.
>> >
>> > It's much better to work from the datasheet instead of doing mmiotraces,
>> > the blob only has a few modes built-in.
>> >
>> > The BT is actually a very flexible chip, and supports a very wide range
>> > of modes with different overscan amount, plus different filtering options.
>> >
>> > It probably wouldn't be hard to just take a few modes from nvtv and
>> > put them into nouveau, similar to the (very few) Chrontel modes. What's
>> > missing is some sort of infrastructure in X to say "look, on this hardware
>> > there are these two functional blocks (CRTC + BT), I would like to program
>> > with the following values, and I've specified the values in the config
>> > file, or I'm a user space program and provide these values over some X
>> > extension".
>> >
>> > This is even more effort now that modesetting is in the kernel (back
>> > when nvtv was written, it wasn't).
>> >
>> > Without this, you are pretty much stuck with precalculated modes.
>> > Which isn't optimal, because with small overscan the timing gets a bit
>> > fickle, and with larger overscan you get the ugly border, and every
>> > analog TV is different in that respect.
>>
>> I actually checked this out last night, grabbed the BT869 datasheet.
>> Basically you'd have to implement something similar to the ch7006
>> driver (see drivers/gpu/drm/i2c), which provides an API for setting
>> modes (the BT869 appears to have 8 of them, of which I'm guessing only
>> 4 are actually usable, probably the RGB ones). Then you'd need to work
>> out what the I2C index of it is, which you can tell by checking the
>> VBIOS. Of course, this all requires the relevant hardware.
>>
>> The stuff about overscan/etc are exposed as KMS properties (which in
>> turn appear in xrandr) and not specific to the BT869. The i2c driver
>> is supposed to expose a ->mode_set() function, which takes a
>> drm_display_mode.
>>
>>   -ilia
>>
>
> Meanwhile I fiddled about with nvtv and found out that it still works
> fine. The trick is that I have to switch the X-server to the desired
> TV-Out resolution before activating the TV-Out, otherwise the X-server
> freezes.

Great! I'll put that up as a workaround on the wiki, should be enough
to get people going.

>
> Doing the TV-Out via xrandr and Xinerama would be much more
> comfortable, but I understand that nowadays (with HDMI and such stuff)
> S-Video is nearly a "dead horse", so it obviously does not make much
> sense to spend great efforts here. But if anyone with sufficient
> knowledge (i. e. not me...) has enough spare time and feels like doing
> this, I would really appreciate it :-)

If you're willing to test stuff (i.e. compile nouveau modules, load
them, check that they work), I'll throw it on the todo list. The
problem with this hw is finding someone who can test. (But even if you
are willing, I don't want to provide false expectations -- it's
reasonably likely that no one will take this work on.)

Cheers,

  -ilia

Re: TV-Out on a GeForce 2MX supported?

[Nils Krafft]

Ilia Mirkin <imirkin-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org> [Mi, 05.03.2014 15:39]:
> On Wed, Mar 5, 2014 at 2:57 PM, Nils Krafft <fehmarn-rund-6WyM7rXn5Gg@public.gmane.org> wrote:
> > Hi,
> >
> > Ilia Mirkin <imirkin-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org> [Mi, 05.03.2014 12:46]:
> >> On Wed, Mar 5, 2014 at 6:06 AM, Dirk Thierbach <dthierbach-Mmb7MZpHnFY@public.gmane.org> wrote:
> >> > On Wed, Mar 05, 2014 at 12:40:34AM -0500, Ilia Mirkin wrote:
> >> >> On Mon, Mar 3, 2014 at 5:41 PM, Nils Krafft <fehmarn-rund-6WyM7rXn5Gg@public.gmane.org> wrote:
> >> >> > I have here a GeForce 2MX (NV10) with a Brooktree BT869 chip for the
> >> >> > TV-Out.
> >> >
> >> > You can try nvtv (http://sourceforge.net/projects/nv-tv-out/). It bypasses
> >> > X and modesetting and programs the Brooktree and CRTC directly. I've
> >> > no idea if it still work with modern X and/or nouveau. :-)
> >> >
> >> >> > shows me only the DVI connection (in fact it's VGA, not DVI), but not
> >> >> > the S-Video connection. If not supported, is this planned for future
> >> >> > versions?
> >> >
> >> >> The relevant hardware is not easily available, nor is hardware to
> >> >> consume s-video/composite connections.
> >> >
> >> > I still have some hardware for both, though I haven't used it for a long
> >> > time.
> >> >
> >> >> This sort of thing is probably
> >> >> only going to be supported if you make it happen. If you're
> >> >> interested, the relevant source file is
> >> >> drivers/gpu/drm/nouveau/dispnv04/tvnv04.c, and you'd have to add
> >> >> something in drivers/gpu/drm/i2c. BT* chips are usually easy to find
> >> >> docs for, and some of the additional details can probably be worked
> >> >> out from mmiotraces, assuming you can find a kernel that the blob
> >> >> driver will load on.
> >> >
> >> > It's much better to work from the datasheet instead of doing mmiotraces,
> >> > the blob only has a few modes built-in.
> >> >
> >> > The BT is actually a very flexible chip, and supports a very wide range
> >> > of modes with different overscan amount, plus different filtering options.
> >> >
> >> > It probably wouldn't be hard to just take a few modes from nvtv and
> >> > put them into nouveau, similar to the (very few) Chrontel modes. What's
> >> > missing is some sort of infrastructure in X to say "look, on this hardware
> >> > there are these two functional blocks (CRTC + BT), I would like to program
> >> > with the following values, and I've specified the values in the config
> >> > file, or I'm a user space program and provide these values over some X
> >> > extension".
> >> >
> >> > This is even more effort now that modesetting is in the kernel (back
> >> > when nvtv was written, it wasn't).
> >> >
> >> > Without this, you are pretty much stuck with precalculated modes.
> >> > Which isn't optimal, because with small overscan the timing gets a bit
> >> > fickle, and with larger overscan you get the ugly border, and every
> >> > analog TV is different in that respect.
> >>
> >> I actually checked this out last night, grabbed the BT869 datasheet.
> >> Basically you'd have to implement something similar to the ch7006
> >> driver (see drivers/gpu/drm/i2c), which provides an API for setting
> >> modes (the BT869 appears to have 8 of them, of which I'm guessing only
> >> 4 are actually usable, probably the RGB ones). Then you'd need to work
> >> out what the I2C index of it is, which you can tell by checking the
> >> VBIOS. Of course, this all requires the relevant hardware.
> >>
> >> The stuff about overscan/etc are exposed as KMS properties (which in
> >> turn appear in xrandr) and not specific to the BT869. The i2c driver
> >> is supposed to expose a ->mode_set() function, which takes a
> >> drm_display_mode.
> >>
> >>   -ilia
> >>
> >
> > Meanwhile I fiddled about with nvtv and found out that it still works
> > fine. The trick is that I have to switch the X-server to the desired
> > TV-Out resolution before activating the TV-Out, otherwise the X-server
> > freezes.
> 
> Great! I'll put that up as a workaround on the wiki, should be enough
> to get people going.
> 
> >
> > Doing the TV-Out via xrandr and Xinerama would be much more
> > comfortable, but I understand that nowadays (with HDMI and such stuff)
> > S-Video is nearly a "dead horse", so it obviously does not make much
> > sense to spend great efforts here. But if anyone with sufficient
> > knowledge (i. e. not me...) has enough spare time and feels like doing
> > this, I would really appreciate it :-)
> 
> If you're willing to test stuff (i.e. compile nouveau modules, load
> them, check that they work), I'll throw it on the todo list. The
> problem with this hw is finding someone who can test. (But even if you
> are willing, I don't want to provide false expectations -- it's
> reasonably likely that no one will take this work on.)
> 
> Cheers,
> 
>   -ilia

Yes, I am willing to do tests if someone wants to do that work, no
problem. And I fully understand that this has very low priority for
the developers...

Please keep me in Cc regarding this subject if possible, I'm not
subscribed.


Thanks,
Nils

Re: TV-Out on a GeForce 2MX supported?

[Dirk Thierbach]

> Meanwhile I fiddled about with nvtv and found out that it still works
> fine. The trick is that I have to switch the X-server to the desired
> TV-Out resolution before activating the TV-Out, otherwise the X-server
> freezes.

Hm, the freeze is new. :-) You can switch X modes from the command
line with -X, though, and from the GUI, too (if it still works).

> Doing the TV-Out via xrandr and Xinerama would be much more
> comfortable, 

You can use the second head, too, which is "sort of" Xinerama. Though nvtv
needs to do more initialization to do that, so it might clash with KMS.
You can also attach the video overlay hardware to the second head, if
you mainly want to watch videos on the TV.

And switching from the commandline isn't that much different from xrandr.

- Dirk