Operating KMS UAPI (Re: RFC: Drm-connector properties managed by another driver / privacy screen support)

[Daniel Vetter]

Refocusing on where I think we still have a bit a disconnnect.

On Mon, May 04, 2020 at 03:22:28PM +0300, Pekka Paalanen wrote:
> On Mon, 4 May 2020 13:00:02 +0200
> Daniel Vetter <daniel at ffwll.ch> wrote:
> > On Mon, May 4, 2020 at 11:49 AM Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > > On Thu, 30 Apr 2020 15:53:23 +0200
> > > Daniel Vetter <daniel at ffwll.ch> wrote:
> > I guess my point is, this is a lot bigger problem than just the
> > default state. This = vt switching that doesn't look horrible and
> > doesn't result in artifacts and issues on the new compositor.
> 
> I am interested in getting reliably to the same hardware state as you
> used to have before, either after reboots or after vt-switches. The
> transition does not have to be guaranteed to be smooth, but at the same
> time the restore policy should not exclude the possibility of a
> smooth transition.

So my point is kinda that if you want both, then the only way to get there
to have a very clear set of what's allowed to be left behind be the
outgoing compositor. For example:
- only primary plane
- only untiled
- no color transform magic
- ...

Imo this is a related problem to the save/restore topic, since if one
compositor does something the new one doesn't understand (e.g. tiled
buffers with modifiers, and new compositor doesn't use getfb2), then it's
going to break.

Similar, if the old compositor sets a new color transform property that
the new compositor doesn't understand, then you get a mess.

Blind restore handles the permanent mess issue, but it doesn't handle the
smooth transition issue. But both problems are of the "old compositor did
something the new compositor doesn't understand", hence why I chuck them
into the same bin. And the issue with a blind save/restore, or kernel
defaults, or any of the solutions proposed here is that they pretty much
guarantee non-smooth transitions, they only solve the permanent damange
part of the problem.

I think to solve both, we need some kind of proper compositor switching
protocol, e.g. using logind:
- old compositor transitions to the minimal config as specified somewhere
- logind forces all other properties to "defaults", whether that's
  restoring boot-up defaults or defaults obtained from the kernel or
  something else is tbd
- logind maybe even does a transition if there's multiple version of the
  protocol, e.g. v2 allows modifiers, v1 only untiled, so it'd need to do
  a blit to untiled if the new compositor only supports v1 switching
  protocol
- new compositor takes over, and can continue the smooth transition since
  it's a well-defined starting state with limited feature usage, _and_
  everything else is reset to "defaults"
 
I fear that if we only solve the "resets to defaults" issue then we can
draw ourselves into a corner for the smooth transition stuff, if e.g. the
wrong entity in the above dance forces the reset to defaults.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch