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.