new userspace API approaches atomic *

[Dave Airlie]

> There are several problems with this:
>
> - I can't test other drivers
>
> - I don't have the knowledge or inclination to implement atomic semantics
>   for everyone's favorite hardware, and without that there's little
>   point in doing the work. Some of my initial code was layered on top of
>   drm_crtc_helper though, so it might be possible to use that as a basis
>   for an atomic helper, but there would actually be no benefit from
>   using it apart from allowing those drivers to respond to the atomic
>   ioctl. But we wouldn't use any of that w/ i915, so it would be better is
>   someone else does that part.

The "I can't test it" argument doesn't fly with me, you are creating a
new API that adds a useful feature, it should be possible to get a few
other driver maintainers interested, but also I'd hope that most of
the ideas for converting to a new API would be mechanical in a lot of
ways. Atomic semantics aren't hw specific from what i can see, if they
are then the API is obviously wrong.

> - Replacing all the legacy codepaths with new code in one go increases the
>   chance that we get a regression, and then we have no choice but to
>   back out the whole thing. Also it seems that no-one apart from Rob has
>   even looked at the code, so it seems likely that there would be heavy
>   opposition to replacing the current code with something new.

I never said one go, I said before pushing the new API. This means you
get everything internally converted in the drm/driver interface, drop
the old drm/driver interface, and the new userspace API. At least
regressions should be a lot more obvious and we can port a driver at a
time if needed. We can also block new drivers from using the old
interfaces from being merged.

> - These are the reasons I would like to merge the thing without touching
>   the legcay codepaths too much. Then each driver author could move their
>   code over the new APIs. I'm willing to help of course, but the driver
>   authors are in a much better position to make something that actually
>   works for their hardware.

Yup thats what you want, but you don't want to bring in the new API
before this happens, since only once you've ported a bunch of drivers
will you know the API actually works.

>> f) get b merged standalone, transition phase is fine, but every driver
>> needs to be ported before the API
>> goes in.
>
> Why? The current drivers are not using the same APIs internally anyway.
> i915 doesn't use drm_crtc_helper for example. You didn't demand that
> Daniel rewrite drm_crtc_helper to suit i915 and fix up all the other
> drivers, did you?
>

helpers are not APIs. The API from drm_crtc.c to driver is the main
modesetting API, for instance Daniel is trying to stop taking locks in
the drm_crtc side of things, to do this he is going and reimplementing
lots of bits in lots of drivers at the same time.

>
> Right, so either I rewrite the modeset and pageflip code for all drivers,
> or I wait until all the driver authors decide to help me. The first one
> will take approximately five years given that I don't know the hardware
> and I have other tasks on my plate, and based on the past interest the
> second one doesn't seem likely to happen anytime soon
>
> All this make me think I should just try to push it as an i915 private
> feature. Damn the other drivers. That should make the management happy too
> since everyone that needs atomic display updates on Linux will need to buy
> Intel hardware.
>
> Oh well, the world is supposedly ending in a few days anyway, so perhaps
> I can just relax and stop caring :)

Well start by converting Intel to a new internal API without the
external, kick a few driver authors to start porting other drivers to
the new internal API. The API seems like it should be pretty much hw
independent. But I expect getting other maintainers interested might
involve actually going out and actually writing crappy patches and
sending them to them to pick up. I can also help kick heads in the
right direction.

I just don't want to implement any userspace APIs on only one driver,
and this and atomic modeset are things that are definitely heading in
that direction.

Dave.