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
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
--
2.49.0
Hi everyone, I have reviewed all the series, but I would appreciate an additional review for two important reasons: - This series introduces a new uAPI, and I believe it is crucial to have at least a third perspective before merging. - I was heavily involved in the creation of these patches, so an external review would be very valuable. Could someone please look at it so we can move forward? We have many new parameters to introduce, such as plane configuration and dynamic connectors, but everything depends on this series. Thank you very much for your help! Best regards, Louis Chauvet 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
+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
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. 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. 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 >
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
Hi everyone, On Fri, Jul 18, 2025 at 05:51:40PM +0200, Louis Chauvet wrote: > > > 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). Back from holiday and catching up on email. First, thanks for presenting this in the Display Next Hackfest :D I couldn't attend, is there a link to the presentation? Back to zpos, as far as I can tell, we do not expose this property at the moment for any plane type. 3 years ago I sent a patch adding the property and blending following the zpos order, but it wasn't merged: https://github.com/JoseExposito/linux/commit/befc79a1341b27eb328b582c3841097d17ccce71 Code has changed since then, but we might be able to reuse some bits. CC me if you send a patch and I'll review it :) > 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. If we don't set the zpos at the moment, I don't think we need to add it before configfs. I'd prefer to merge configfs as it is and then support zpos both in the default VKMS device and in the custom ones. In this way, we might avoid unexpected user-space changes. Anyway, this is something we can discuss in the series adding zpos rather than here. > 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. Check my patch, it is already done. But for the configs code we might need a different solution. Thanks to everyone for your interest in this series, José Expósito > 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 >
Merged into Android tree: https://android-review.git.corp.google.com/c/kernel/common-modules/virtual-device/+/3661920 I'm able to use configfs as expected. Tested-by: Mark Yacoub <markyacoub@google.com> On Thu, Jul 17, 2025 at 12:37 PM Louis Chauvet <louis.chauvet@bootlin.com> 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 >
© 2016 - 2025 Red Hat, Inc.