[haiku-development] Re: A tale of two accelerant API's

  • From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Fri, 1 Feb 2013 10:57:02 +0100 (CET)

On February 1, 2013 at 3:28 AM Alexander von Gluck IV <kallisti5@xxxxxxxxxxx>
wrote:
> I've branched a github repo to start toying with *real* mult-head stuff
> on the app server.

That would be really great to have.

> Here are my initial plans:
>    * We should try to support "old" accelerants as well as new ones

Definitely.

> My current plan goes as follows:
[...]
> Anyway, this stuff could turn into a mess reaaaal quick.
> (which is why i'm working on a github fork atm)
>
> Thoughts? Does this look like a viable move? (or is it overkill?)

Not overkill, but also not the direction I would have gone to :-)

I think it definitely makes sense to create a new accelerant API that not only
provides multi-head support, but also functions that do not work on the frame
buffer, but on any offscreen buffer, too. Plus compositing, plus ...
For this, I would introduce a new B_GET_ACCELERANT ioctl where you can specify
the version you want, and you also get a structure, not just a name which would
also allow for future extensions of both the reply and the request.
Anyway, I would not use AccelerantHWInterface for this any longer, but a new
class that only manages the new driver interface. AccelerantHWInterface will
just call B_GET_ACCELERANT at first, too, and if it succeeds, it will skip the
driver. The new HWInterface class will grab such drivers then in a second run.
It might also make sense to link the accelerants against the app_server in the
future, to be able to offer them support API functions instead of compiling the
common functions (like EDID and mode creation support) in every driver.

Bye,
   Axel.

Other related posts: