mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Louis Chauvet <louis.chauvet@bootlin.com>
To: Marius Vlad <marius.vlad@collabora.com>
Cc: "José Expósito" <jose.exposito89@gmail.com>,
	tzimmermann@suse.de, mripard@kernel.org, simona@ffwll.ch,
	sebastian.wick@redhat.com, victoria@system76.com,
	"Mark Yacoub" <markyacoub@google.com>,
	xaver.hugl@kde.org, hamohammed.sa@gmail.com,
	melissa.srw@gmail.com, maarten.lankhorst@linux.intel.com,
	airlied@gmail.com, dri-devel@lists.freedesktop.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 00/16] drm/vkms: Add configfs support
Date: Fri, 18 Jul 2025 17:51:40 +0200	[thread overview]
Message-ID: <bc0d775e-21dc-4cb7-a905-06b81028267b@bootlin.com> (raw)
In-Reply-To: <aHpGGxZyimpJ8Ehz@xpredator>



Le 18/07/2025 à 15:03, Marius Vlad a écrit :
> Hi,
> 
> FWIW, we (Weston) also use vkms in CI and we have in plan to make use of
> these changes to exercise some internal code paths and enhance our tests.
> Look forward to getting these into the tree and have it a in release. We
> tend to follow with a branch/stable release so I suppose that's going be
> a while. Just wanted to also say thanks a lot for driving this.

Hi,

Thanks a lot for this positive feedback!

> Just curios, in the current form would it be possible to configure the
> plane's zpos position? Apart from testing underlay/overlay in the same
> time, some drivers today allows the primary to be independently
> positioned. Simulating these type of configurations would allow see what
> architectural changes we might need to do to transition towards a place
> where we can use any other plane as a (fallback) compositing one like we
> do today with the primary one.

Currently nothing is done to do a proper z-pos managment, and even 
worse: the z-order is not really predictable (order of creation in 
configfs, so if userspace creates cursor-primary, the cursor will be 
behind the primary plane).

We need to change this before merging ConfigFS. Fir the first iteration, 
we can simply: make primary plane always at the back (zpos=0), overlay 
with undefined ordering (zpos=1), cursor on top (zpos=2) directly in 
vkms_plane_init. I need to check if this will be a uAPI break if we add 
later some configfs attributes like default_zpos / zpos_min / zpos_max.

Even with this, we need to fix [1] to compose planes in the correct 
order (I don't think this is broken right now because we create primary 
then overlays then cursor, so the composition order will be correct).

[1]:https://elixir.bootlin.com/linux/v6.15.6/source/drivers/gpu/drm/vkms/vkms_composer.c#L392-L394

@José, I will fix the vkms_composer to use plane->state->zpos or 
normalized_zpos.

Thanks a lot for this suggestion which showed a flaw in the current 
implementation!

Louis Chauvet

> On Thu, Jul 17, 2025 at 06:37:17PM +0200, Louis Chauvet wrote:
>> +CC: Mark (Google), Sebastian (Mutter), Xaver (KWin), Victoria (Cosmic)
>>
>> Hi everyone,
>>
>> Last week, I presented this work at the Display Next Hackfest, and the
>> feedback from compositors was very positive. At least KWin, Mutter, and
>> Cosmic are interested in integrating it into their tests, so it would be
>> great if someone could review it.
>>
>> Sebastian quickly tested this work (using [2] for full features) with their
>> existing VKMS tests [1], and it worked. From what I understand, the tests
>> are quite basic —just sanity checks— but we were able to reproduce the
>> default vkms device using ConfigFS.
>>
>> If another compositor wants to test the ConfigFS interface (I will try to
>> keep [2] updated), that would be amazing. Feel free to send feedback!
>>
>> A small note: This series has a minor conflict since the conversion to the
>> faux device, but it can be applied using `b4 am -3 ... && git am -3 ...`.
>> @josé, if you send a new iteration, can you add markyacoub@google.com in
>> copy, and maybe Sebastian, Xaver, Victoria if they want to follow the
>> upstreaming?
>>
>> Thank you,
>> Louis Chauvet
>>
>> [1]:https://gitlab.gnome.org/swick/mutter/-/commit/88a7354942d9728dae06fb83cc4f2d2c7b08b694
>> [2]:https://github.com/Fomys/linux/tree/configfs-everything
>>
>>
>>
>> Le 07/05/2025 à 15:54, José Expósito a écrit :
>>> Hi everyone,
>>>
>>> This series allow to configure one or more VKMS instances without having
>>> to reload the driver using configfs.
>>>
>>> The series is structured in 3 blocks:
>>>
>>>     - Patches 1..11: Basic device configuration. For simplicity, I kept the
>>>       available options as minimal as possible.
>>>
>>>     - Patches 12 and 13: New option to skip the default device creation and to-do
>>>       cleanup.
>>>
>>>     - Patches 14, 15 and 16: Allow to hot-plug and unplug connectors. This is not
>>>       part of the minimal set of options, but I included in this series so it can
>>>       be used as a template/example of how new configurations can be added.
>>>
>>> The process of configuring a VKMS device is documented in "vkms.rst".
>>>
>>> Finally, the code is thoroughly tested by a collection of IGT tests [1].
>>>
>>> Best wishes,
>>> José Expósito
>>>
>>> [1] https://lists.freedesktop.org/archives/igt-dev/2025-February/086071.html
>>>
>>> Changes in v5:
>>>
>>>     - Added Reviewed-by tags, thanks Louis!
>>>     - Rebased on top of drm-misc-next
>>>     - Link to v4: https://lore.kernel.org/dri-devel/20250407081425.6420-1-jose.exposito89@gmail.com/
>>>
>>> Changes in v4:
>>>
>>>     - Since Louis and I worked on this together, set him as the author of some of
>>>       the patches and me as co-developed-by to reflect this joint effort.
>>>     - Rebased on top of drm-misc-next
>>>     - Link to v3: https://lore.kernel.org/all/20250307163353.5896-1-jose.exposito89@gmail.com/
>>>
>>> Changes in v3:
>>>
>>>     - Applied review comments by Louis Chauvet: (thanks!!)
>>>       - Use scoped_guard() instead of guard(mutex)(...)
>>>       - Fix a use-after-free error in the connector hot-plug code
>>>     - Rebased on top of drm-misc-next
>>>     - Link to v2: https://lore.kernel.org/all/20250225175936.7223-1-jose.exposito89@gmail.com/
>>>
>>> Changes in v2:
>>>
>>>     - Applied review comments by Louis Chauvet:
>>>       - Use guard(mutex)(...) instead of lock/unlock
>>>       - Return -EBUSY when trying to modify a enabled device
>>>       - Move the connector hot-plug related patches to the end
>>>     - Rebased on top of drm-misc-next
>>>     - Link to v1: https://lore.kernel.org/dri-devel/20250218170808.9507-1-jose.exposito89@gmail.com/T/
>>>
>>> José Expósito (6):
>>>     drm/vkms: Expose device creation and destruction
>>>     drm/vkms: Allow to configure the default device creation
>>>     drm/vkms: Remove completed task from the TODO list
>>>     drm/vkms: Allow to configure connector status
>>>     drm/vkms: Allow to update the connector status
>>>     drm/vkms: Allow to configure connector status via configfs
>>>
>>> Louis Chauvet (10):
>>>     drm/vkms: Add and remove VKMS instances via configfs
>>>     drm/vkms: Allow to configure multiple planes via configfs
>>>     drm/vkms: Allow to configure the plane type via configfs
>>>     drm/vkms: Allow to configure multiple CRTCs via configfs
>>>     drm/vkms: Allow to configure CRTC writeback support via configfs
>>>     drm/vkms: Allow to attach planes and CRTCs via configfs
>>>     drm/vkms: Allow to configure multiple encoders via configfs
>>>     drm/vkms: Allow to attach encoders and CRTCs via configfs
>>>     drm/vkms: Allow to configure multiple connectors via configfs
>>>     drm/vkms: Allow to attach connectors and encoders via configfs
>>>
>>>    Documentation/gpu/vkms.rst                    | 100 ++-
>>>    drivers/gpu/drm/vkms/Kconfig                  |   1 +
>>>    drivers/gpu/drm/vkms/Makefile                 |   3 +-
>>>    drivers/gpu/drm/vkms/tests/vkms_config_test.c |  24 +
>>>    drivers/gpu/drm/vkms/vkms_config.c            |   8 +-
>>>    drivers/gpu/drm/vkms/vkms_config.h            |  26 +
>>>    drivers/gpu/drm/vkms/vkms_configfs.c          | 833 ++++++++++++++++++
>>>    drivers/gpu/drm/vkms/vkms_configfs.h          |   8 +
>>>    drivers/gpu/drm/vkms/vkms_connector.c         |  35 +
>>>    drivers/gpu/drm/vkms/vkms_connector.h         |   9 +
>>>    drivers/gpu/drm/vkms/vkms_drv.c               |  18 +-
>>>    drivers/gpu/drm/vkms/vkms_drv.h               |  20 +
>>>    12 files changed, 1072 insertions(+), 13 deletions(-)
>>>    create mode 100644 drivers/gpu/drm/vkms/vkms_configfs.c
>>>    create mode 100644 drivers/gpu/drm/vkms/vkms_configfs.h
>>>
>>>
>>> base-commit: a6c0a91ccb257eaec2aee080df06863ce7601315
>>
>> -- 
>> Louis Chauvet, Bootlin
>> Embedded Linux and Kernel engineering
>> https://bootlin.com
>>

-- 
Louis Chauvet, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


  reply	other threads:[~2025-07-18 15:51 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-07 13:54 José Expósito
2025-05-07 13:54 ` [PATCH v5 01/16] drm/vkms: Expose device creation and destruction José Expósito
2025-05-07 13:54 ` [PATCH v5 02/16] drm/vkms: Add and remove VKMS instances via configfs José Expósito
2025-05-07 13:54 ` [PATCH v5 03/16] drm/vkms: Allow to configure multiple planes " José Expósito
2025-05-07 13:54 ` [PATCH v5 04/16] drm/vkms: Allow to configure the plane type " José Expósito
2025-05-07 13:54 ` [PATCH v5 05/16] drm/vkms: Allow to configure multiple CRTCs " José Expósito
2025-05-07 13:54 ` [PATCH v5 06/16] drm/vkms: Allow to configure CRTC writeback support " José Expósito
2025-05-07 13:54 ` [PATCH v5 07/16] drm/vkms: Allow to attach planes and CRTCs " José Expósito
2025-05-07 13:54 ` [PATCH v5 08/16] drm/vkms: Allow to configure multiple encoders " José Expósito
2025-05-07 13:54 ` [PATCH v5 09/16] drm/vkms: Allow to attach encoders and CRTCs " José Expósito
2025-05-07 13:54 ` [PATCH v5 10/16] drm/vkms: Allow to configure multiple connectors " José Expósito
2025-05-07 13:54 ` [PATCH v5 11/16] drm/vkms: Allow to attach connectors and encoders " José Expósito
2025-05-07 13:54 ` [PATCH v5 12/16] drm/vkms: Allow to configure the default device creation José Expósito
2025-05-07 13:54 ` [PATCH v5 13/16] drm/vkms: Remove completed task from the TODO list José Expósito
2025-05-07 13:54 ` [PATCH v5 14/16] drm/vkms: Allow to configure connector status José Expósito
2025-05-07 13:54 ` [PATCH v5 15/16] drm/vkms: Allow to update the " José Expósito
2025-05-07 13:54 ` [PATCH v5 16/16] drm/vkms: Allow to configure connector status via configfs José Expósito
2025-05-23 12:32 ` [PATCH v5 00/16] drm/vkms: Add configfs support Louis Chauvet
2025-07-17 16:37 ` Louis Chauvet
2025-07-17 16:51   ` Mark Yacoub
2025-07-18 13:03   ` Marius Vlad
2025-07-18 15:51     ` Louis Chauvet [this message]
2025-08-04 14:29       ` José Expósito

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bc0d775e-21dc-4cb7-a905-06b81028267b@bootlin.com \
    --to=louis.chauvet@bootlin.com \
    --cc=airlied@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hamohammed.sa@gmail.com \
    --cc=jose.exposito89@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=marius.vlad@collabora.com \
    --cc=markyacoub@google.com \
    --cc=melissa.srw@gmail.com \
    --cc=mripard@kernel.org \
    --cc=sebastian.wick@redhat.com \
    --cc=simona@ffwll.ch \
    --cc=tzimmermann@suse.de \
    --cc=victoria@system76.com \
    --cc=xaver.hugl@kde.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®