Virtualization - May 2023 - [PATCH v2 1/8] drm: Disable the cursor plane on atomic contexts with virtualized drivers

On Thu, 4 May 2023 01:50:25 +0000
Zack Rusin <zackr at vmware.com> wrote:
> On Wed, 2023-05-03 at 09:48 +0200, Javier Martinez Canillas wrote:
> > Zack Rusin <zackr at vmware.com> writes:
> >   
> > > On Tue, 2023-05-02 at 11:32 +0200, Javier Martinez Canillas
wrote:
> > > > AFAICT this is the only remaining thing to be addressed for
this series ?
> > > 
> > > No, there was more. tbh I haven't had the time to think about
whether the above
> > > makes sense to me, e.g. I'm not sure if having virtualized
drivers expose
> > > "support
> > > universal planes" and adding another plane which is not
universal (the only
> > > "universal" plane on them being the default one) makes
more sense than a flag
> > > that
> > > says "this driver requires a cursor in the cursor
plane". There's certainly a
> > > huge
> > > difference in how userspace would be required to handle it and
it's way uglier
> > > with
> > > two different cursor planes. i.e. there's a lot of ways in
which this could be
> > > cleaner in the kernel but they all require significant changes to
userspace,
> > > that go
> > > way beyond "attach hotspot info to this plane". I'd
like to avoid approaches
> > > that
> > > mean running with atomic kms requires completely separate paths
for virtualized
> > > drivers because no one will ever support and maintain it.
> > > 
> > > It's not a trivial thing because it's fundamentally hard
to untangle the fact
> > > the
> > > virtualized drivers have been advertising universal plane support
without ever
> > > supporting universal planes. Especially because most new
userspace in general
> > > checks
> > > for "universal planes" to expose atomic kms paths.
> > >   
> > 
> > After some discussion on the #dri-devel, your approach makes sense and
the
> > only contention point is the name of the driver feature flag name. The
one
> > you are using (DRIVER_VIRTUAL) seems to be too broad and generic (the
fact
> > that vkms won't set and is a virtual driver as well, is a good
example).
> > 
> > Maybe something like DRIVER_CURSOR_HOTSPOT or
DRIVER_CURSOR_COMMANDEERING
> > would be more accurate and self explanatory ?  
> 
> Sure, or even more verbose DRIVER_NEEDS_CURSOR_PLANE_HOTSPOT, but it sounds
like
> Pekka doesn't agree with this approach. As I mentioned in my response
to him, I'd be
> happy with any approach that gets paravirtualized drivers working with
atomic kms,
> but atm I don't have enough time to be creating a new kernel subsystem
or a new set
> of uapi's for paravirtualized drivers and then porting mutter/kwin to
those.
It seems I have not been clear enough, apologies. Once more, in short:

Zack, I'm worried about this statement from you (copied from above):
> > > I'd like to avoid approaches that mean running with atomic
kms
> > > requires completely separate paths for virtualized drivers
> > > because no one will ever support and maintain it.
It feels like you are intentionally limiting your own design options
for the fear of "no one will ever support it". I'm worried that
over
the coming years, that will lead to a hard to use, hard to maintain
patchwork of vague or undocumented or just too many little UAPI details.

Please, don't limit your designs. There are good reasons why nested KMS
drivers behave fundamentally differently to most KMS hardware drivers.
Userspace that does not or cannot take that into account is unavoidably
crippled.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.linuxfoundation.org/pipermail/virtualization/attachments/20230504/25ff17a7/attachment.sig>