FreeLists / haiku-appserver / [haiku-appserver] Re: nVidia hardware known options for new features (R2?)

["Rudolf" <drivers.be-hold@xxxxxxxxxxxx>]

Hi,

Axel wrote:
> 
> Exactly :-)
> There is no particular need for a stable driver API either - the 
> current R5 API should stay supported as is, and we either extend it 
> (as 
> in optional extra hooks), or replace it (as in new engine interface 
> because the old one doesn't properly support multi-head, or 
> whatever).
> Especially if we go the extension way for now, it would almost take 
> no 
> time.
> I would also like to add proper TV-Out support to the API.

OK. I'll start experimenting then :)
About TVout: you did see a bit how it currently works for the Matrox 
driver I think. It's a bit extended, and also sits in the nvidia driver 
now. I do not really have plans to add more I must say. Did you have 
anything particular in mind? I like it simple ;-)
All fun aside: adding controls for position, size, flickerfilter etc is 
something I'd rather _not_ look into. The default settings should be 
precise enough for general use, video modes should not be messed with 
anyway, and TVout is going to be extinct soon I hope :-)
More output standards is also not on my personal wishlist: DVD's are 
only created for PAL and NTSC anyway.

What I do have on my TVout list is one thing ATM: field retrace sync: 
I'll add that as a tweak with a nv.setting option to enable it for now. 
At the least it should confirm my suspicions about how this works :)

> > Makes 100% sense. :-) I guess for the memory manager, we could 
> > start 
> > off 
> > from what is currently contained in the different drivers 
> > supporting 
> > overlay bitmaps, and see what is common among them to have an idea 
> > for 
> > possible constraints.
> 
> Sounds like a good starting point, yes.
Indeed. Of course I already know how that is however :) (looked at 4 
different manufacturors, and the Be interface as it was is sufficient 
in this respect. However, it's possible that for blitting there are 
diffs: this I need to look into more.

> > It is definitely supposed to work. I know that the code should be 
> > contained 
> > in the stampTV code, which was once available. I think I lost my 
> > copy. 
> > Maybe you can get it from somewhere.
> 
> Only the nodes taking part in such a negotiation should be able to 
> limit the options. Ie. if a node cannot do B_YCbCr422 that would be 
> understandable, but it's not a general problem.
OK, so I take it I need to look at the mediaplayer I am testing with to 
see if that uses nodes that cannot output decoded video in B_YCbCr422 
format. If these nodes are also used for Be's mediaplayer however, they 
can do it (or overlay wouldn't be used in practice).

I am playing around with Kevin's MK mediaplayer and his BeTVOut 
consumer node: both are BSD/MIT btw. (talked to him about this to be 
sure).

> I also have the stampTV sources over here, in case you need them :)
Sounds very interesting, I'd love to receive them ;-)
I would like to setup a node that tries both overlay and 2D 
scaled_filtered_blit for video output to make chances on successfully 
establishing a connection as big as can be.

> > > OTOH: I am getting more and more requests to 'take over' ATI dev. 
> > > ;
> > > -)
> > If Thomas can't maintain the driver because he has other stuff to 
> > do 
> > (did 
> > someone manage to contact him recently?), I guess the ATI driver 
> > would be 
> > in good hands if you took over. That is, if Thomas doesn't mind.
> 
> I tried to contact him recently, but I didn't get an answer back yet.

I was joking a bit of course. Anyway: if I really should look at ATI, 
then I am going to need a fair amount of cards to test with. Before I 
ever make a commit to that driver though, I need to first have a good 
grasp on it (Thomas has a different style from me in coding). And free 
time of course, which is limited ATM. :)

Best regards,

Rudolf.