On Thu, May 04, 2023 at 01:39:04PM +0300, Pekka Paalanen wrote: > On Thu, 4 May 2023 01:50:25 +0000 > Zack Rusin <zackr@xxxxxxxxxx> wrote: > > > On Wed, 2023-05-03 at 09:48 +0200, Javier Martinez Canillas wrote: > > > Zack Rusin <zackr@xxxxxxxxxx> 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. >From a compositor side, there is a valid reason to minimize the uAPI difference between "nested virtual machine" code paths and "running on actual hardware" code paths, which is to let virtual machines with a viewer connected to KMS act as a testing environment, rather than a production environment. Running a production environment in a virtual machine doesn't really need to use KMS at all. When using virtual machines for testing, I want to minimize the amount of differentation between running on hardware and running in the VM because otherwise the parts that are tested are not the same. I realize that hotpspots and the cursor moving viewer side contradicts that to some degree, but still, from a graphical testing witha VM point of view, one has to compromise, as testing isn't just for the KMS layer, but for the DE and distribution as a whole. Jonas > > > Thanks, > pq