gistfile1.txt

Sima proposed a new type of property that can be used to git feedback to
userspace after atomic ioctl. The user supplies a list of output properties
that they want to query and the kernel fills it in before returning from the
ioctl. This would help to get some information about why things failed during
TEST_ONLY.

Emersion raised the point that you might not know how much memory is needed
beforehand for the returned properties, to which sima replied: blob property.
There was some discussion about how that makes it possible to leak kernel
memory, especially if userspace does not know about a new property blob.
Emersion pointed out that userspace should only request properties that it
understands and pq agreed.

Emersion asked how the user should inform the kernel that it's done with the
blob, to which sima replied: DRM_IOCTL_MODE_DESTROYPROPBLOB. Sima also
mentioned using some sort of weak reference garbage collection scheme for
properties and there was some further discussion, but I'm not sure there was
any conclusion.

I asked if it made sense to add color format capabilities to the mode info
struct, but the conclusion was that it wouldn't really be useful because we
need TEST_ONLY anyway to see if the color format setting is compatible with
other settings.

I asked again if we should drop the "active color format" property as it seems
to be more trouble than it's worth for now. pq mentioned that there are 2
separate use cases (in his words):
- People playing with setting UI would like to know what "auto" would result
  in, but that's just nice to have
- The other use case is the flicker-free boot into known configuration He went
  on to point out that the main problem with "auto" is that any modeset could
  make the driver decide differently. This means that we cannot fully rely on
  the previously set property.
  
However, leaving out "active color property" did not put us in a worse
situation than before, so the conclusion was that we should leave it out for
now.