new userspace API approaches atomic *

[Daniel Vetter]

On Sun, Dec 16, 2012 at 7:04 AM, Dave Airlie <airlied at gmail.com> 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