I'm adding features to VKMS! What would you like to see?

[Jim Shargo]

Wow, thanks so much for the great response. I'm hyped to keep going.

I've gone through all the messages and collected the ideas (LMK if I
missed anything), in no particular order:

  - Connector Hotplug
      - DP-MST style connector registering (disappearing and reappearing)
  - Format modifier support
  - Link-status change emulation
  - Damage, FB_DAMAGE_CLIPS
  - Multiple planes with customizable constraints
      - Z-order, format restrictions
  - Additional props (panel_orientation, non-desktop, TILE, etc.)
  - Multiple planes with writeback
  - Multiple outputs with different timing cycles
  - HDMI/DP infoframe contents
  - Fault injection
      - eBPF hook into atomic_check, or just errno
  - generic vkms helper library, e.g. for headless GPUs/datacenters

My first pass on requirements came from digging through our compositor
backend (https://source.chromium.org/chromium/chromium/src/+/main:ui/ozone/platform/drm/gpu/).
The features / additions I've already had on my plate are (also in no
particular order):

  - Plane props: COLOR_ENCODING, COLOR_RANGE, PLANE_CTM, IN_FORMATS, rotation
  - Connector props: Content protection, HDCP Content Type,
privacy-screen, privacy-screen hw-state, privacy-screen sw-state,
EDID, vrr_capable
  - CRTC props: CTM, DEGAMMA_LUT, DEGAMMA_LUT_SIZE, GAMMA_LUT,
GAMMA_LUT_SIZE, BACKGROUND_COLOR
  - Formats: DRM_FORMAT_ARGB8888, DRM_FORMAT_XRGB8888,
DRM_FORMAT_ARGB2101010, DRM_FORMAT_ABGR2101010, DRM_FORMAT_YVU420,
DRM_FORMAT_NV12, DRM_FORMAT_P010

Some things I'm not 100% on... like content protection be mostly
NOPs/blanked-out, if they get added at all.

My hope is to get the big ConfigFS patchset reviewed, and then do
connector hotplugging. Once that's in, I suspect that most of the
additional props and formats are going to be waaaaaaay less involved
and move quickly.

Thanks!
-- Jim


On Mon, Aug 1, 2022 at 3:50 AM Pekka Paalanen <ppaalanen at gmail.com> wrote:
>
> On Fri, 29 Jul 2022 17:33:48 +0200
> Jonas Ådahl <jadahl at gmail.com> wrote:
>
> > On Fri, Jul 29, 2022 at 12:09:27PM +0100, Daniel Stone wrote:
>
> > > One thing I've really wanted is corner-case handling which just can't
> > > be done in generic code. Weston is really aggressive at trying to get
> > > things into planes, but we can only test those on actual systems with
> > > particular semantics.
> > >
> > > I'd love to be able to programmatically fake those to be able to check
> > > our fallbacks in an automatic way. About the best idea I've come up
> > > with for that is being able to attach an eBPF hook to atomic_check.
> > > The absolute MVP would be no arguments and an errno return; if you
> > > completely control the environment, then you can store a counter in a
> > > map and return a particular error for the n'th attempt. But a better
> > > one would allow you to inspect the properties on each object in the
> > > atomic state, and also things like framebuffer attributes (dimensions,
> > > format, modifier, etc) so you could take action accordingly.
> >
> > Being able to queue errors would be great indeed. So far I've done this
> > by mocking a subset of the libdrm API, which I could use to test e.g.
> > failed commits handling:
> >
> > https://gitlab.gnome.org/jadahl/mutter/-/commit/93995754484536c61c7ddeffa2e50e4aef092a78
>
> I wonder, do we actually gain anything from having the kernel inject
> the exact errors we want vs. doing it in userspace similar to Jonas'
> approach?
>
> I can immediately think of more uses for the userspace interception of
> libdrm calls: Weston test suite making sure that stuff actually is
> hitting KMS planes instead of getting composited in GL. Being able to
> inspect the atomic request contents to make sure the expected KMS
> properties are being used would seem very useful.
>
> Maybe libdrm could offer a nice API for this to avoid playing dlsym()
> and function overriding games?
>
>
> Thanks,
> pq