[haiku-appserver] Re: nVidia hardware known options for new features (R2?)
- From: "Rudolf" <drivers.be-hold@xxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Sat, 10 Dec 2005 19:52:30 +0100 CET
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.
Other related posts:
