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

  • From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Sat, 10 Dec 2005 15:02:20 +0100 CET

Stephan Assmus <superstippi@xxxxxx> wrote:
> > > thanks for the detailed email! Since drivers usually need to be
> > > recompiled for Haiku anyways, I see no technical reason to delay
> > > some of this until R2 if it can be done now (given you/we have
> > > enough time). The accelerant API would not care about new 
> > > exported
> > > calls, no?
> > Indeed: I was thinking about that too. Other things I'd like to add 
> > is
> > saturation/intensity controls for video overlay for example ;-)
> Most welcome. :-)

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.

> > I could do this:
> > -setup the scaled blit for current interface,
> > -also setup a new version for it for offscreen bitmaps.
> 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.

> > BTW: Anyone know if it should be working to get a connection for 
> > the
> > B_YCbCr422 colorspace? Currently I can only get RGB spaces going...
> > There's of course a (bigger) chance that this is because of my 
> > still
> > very limited knowledge about the node subject...
> 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.
I also have the stampTV sources over here, in case you need them :)

> > 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.

Bye,
   Axel.


Other related posts: