On Thu, May 04, 2023 at 01:39:04PM +0300, Pekka Paalanen wrote:
On Thu, 4 May 2023 01:50:25 +0000 Zack Rusin email@example.com wrote:
On Wed, 2023-05-03 at 09:48 +0200, Javier Martinez Canillas wrote:
Zack Rusin firstname.lastname@example.org 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.