On Sun, Dec 16, 2012 at 7:04 AM, Dave Airlie <airlied@xxxxxxxxx> wrote: > 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. For actual semantics I think we need to split the discussion into the modeset and the pageflip part: - For modeset it shouldn't be hard to whip up some helpers which use the current crtc helpers to do modeset changes accross multiple crtcs. Like currently, drivers might refuse a modeset in one of their callbacks, and that might only happen once the hw touching has started already. Which means we can't efficiently implement a check flag mode for those drivers. But otoh if they have global constraints they might want to implement their own magic like i915. Or we could add a new global ->check_modeset callback which checks for these (after crtc/encoders have done the respective checking). - For pageflip things are a bit messier, since we really should aim for all changes to be applied on the same vblank. But luckily the set of drivers which support more than one of cursors/pageflips/plane is manageable, and most are just cursosrs+pageflip. Since I've just read through them all I think it shouldn't be too hard to whip up a (totally broken) patch for each of them to guide driver maintainers. So imo to really exploit atomic modeset/pageflip we need special support from each driver to check a given configuration before committing it (this also seems to be the only sane way for userspace to figure out what works and what doesn't without causing tons of flickering). And doing that for each driver is obviously out of the question. But reworking internal interfaces and converting drivers in a simplistic fashion which assume that no global state checking is required (assuming e.g. for modesets the current crtc/encoder checks are good enough) is a requirement I agree with. Which is why I think we should aim first for something much more restricted than the current "every possible feature for kms" approach, for example just pageflips on one crtc ... >From an i915 perspective I'm leaning towards pageflips because things are much simpler there (similar to all other drivers). It's much more immediately useful for us and for atomic modeset our driver-internal code is simple not yet ready to do global state-checking up-front before we start touching hw - we need to move around quite a bit of code until that's doable. So atomic modeset won't really help us yet to for 3-pipe pll sharing and similar shared global resources issues and how to correctly expose them to userspace. Yours, Daniel PS: My totally broken exynos patch, which Inki Dae fixed up for me, and the 3 radeon patches are already merged. It's really not rocket science afaict ... just requires pinging relevant people early so that they can check your patches quickly and know what you're up to. -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
