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