Re: new userspace API approaches atomic *

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Fri, Dec 14, 2012 at 07:13:33AM +1000, Dave Airlie wrote:
> So this is a how to get new features pronouncement,
> 
> >From what I can see people would like to have atomic interfaces for
> pageflip and modesetting merged,
> 
> Now how I think developing and merging these will work (i.e. do it
> this way or don't bother)
> 
> a) get an API you are happy with working, it doesn't need to be perfect
> 
> b) rework the internal drm core/driver APIs for all drivers to allow
> this new interface to be used. Remove
> the old internal apis and create an interface layer between the old
> userspace interface and the new API.

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.

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

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

> c) throw away (a)
> 
> d) reimplement a userspace API on top of the new internal driver API
> fixing all the things you have learned,
> were crazy, insane, nuts etc.
> 
> e) have a lot of tests.

Sure more tests would be nice. I'll try to cook up something to stresses
the modeset side soon.

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

> g) throw away d
> 
> h) write final API and get it merged.
> 
> Yes this is probably more work than you or your manager is willing to
> buy in, but then maybe the feature isn't that important.

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 :)

-- 
Ville Syrjälä
Intel OTC