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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
