All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maxime Ripard <mripard@kernel.org>
To: "Rodrigo Siqueira" <rodrigosiqueiramelo@gmail.com>,
	"Melissa Wen" <melissa.srw@gmail.com>,
	"Maíra Canal" <mairacanal@riseup.net>,
	"Haneen Mohammed" <hamohammed.sa@gmail.com>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>,
	"Simona Vetter" <simona.vetter@ffwll.ch>,
	jose.exposito89@gmail.com, dri-devel@lists.freedesktop.org,
	arthurgrillo@riseup.net, linux-kernel@vger.kernel.org,
	jeremie.dautheribes@bootlin.com, miquel.raynal@bootlin.com,
	thomas.petazzoni@bootlin.com, seanpaul@google.com,
	nicolejadeyee@google.com
Subject: Re: [PATCH RFC v2 00/16] drm/vkms: ConfigFS interface
Date: Tue, 26 Nov 2024 09:42:02 +0100	[thread overview]
Message-ID: <20241126-overjoyed-knowing-cuttlefish-c8d0f6@houat> (raw)
In-Reply-To: <Z0DC8nd1ZFN4A82-@louis-chauvet-laptop>

[-- Attachment #1: Type: text/plain, Size: 2873 bytes --]

Hi,

On Fri, Nov 22, 2024 at 06:44:18PM +0100, Louis Chauvet wrote:
> On 22/11/24 - 18:38, Louis Chauvet wrote:
> > VKMS is manly used to test userspace program and its behavior. The current 
> > implementation is not very configurable as you can only have one device, 
> > with few specific planes.
> > 
> > This series aims to introduce a new interface, using ConfigFS, to create 
> > and configure more devices. This will introduce:
> > - Device creation
> > - Plane creation
> > - Plane configuration (type, color encoding, color range, rotations)
> > - Encoder creation
> > - CRTC creation
> > - Linking between CRTC and planes/encoders
> > 
> > The proposition is:
> > /config/vkms
> > 	DEVICE_1
> > 	┣━ enable
> > 	┣━ writeback
> > 	┣━ planes
> > 	┃  ┣━ PLANE_1
> > 	┃  ┃  ┣━ type
> > 	┃  ┃  ┣━ supported_rotations
> > 	┃  ┃  ┣━ color_range
> > 	┃  ┃  ┣━ color_encoding
> > 	┃  ┃  ┣━ default_color_encoding
> > 	┃  ┃  ┣━ default_rotations
> > 	┃  ┃  ┣━ default_color_range
> > 	┃  ┃  ┗━ possible_crtcs
> > 	┃  ┃     ┗━ >> /config/vkms/DEVICE_1/crtc/CRTC_1 
> > 	┃  ┣━ PLANE_2
> > 	┃  ┃  ┗━ ditto
> > 	┃  ┗━ PLANE_3
> > 	┃     ┗━ ditto
> > 	┃
> > 	┣━ encoders
> > 	┃  ┣━ ENCODER_1
> > 	┃  ┃  ┗━ possible_crtcs
> > 	┃  ┃     ┗━ >> /config/vkms/DEVICE_1/crtc/CRTC_1
> > 	┃  ┗━ ENCODER_2
> > 	┃     ┗━ ditto
> > 	┃
> > 	┗━ crtc
> > 	   ┗━ CRTC_1
> > 	
> > This interface aims to be extendable (new property can easly be added in 
> > objects) and easy to use (objects are created simply by creating folders, 
> > and configured by writing files).
> > 
> > This series depends on 
> > https://lore.kernel.org/all/20241122-google-remove-crtc-index-from-parameter-v2-0-81540742535a@bootlin.com
> > but as this is a bit complex to rebase, you can find a working branch 
> > here:
> > https://gitlab.freedesktop.org/louischauvet/kernel/-/tree/b4/vkms-configfs
> > 
> > Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
> 
> Hi all,
> 
> I am also currently working on MST emulation for VKMS. If someone can read 
> what I already did and at tell me if my implementation seems on the right 
> track it could be nice.
> 
> The current status is not very advanced: I can emulate a mst HUB, but not 
> a screen. I am currently working on properly emulating the HUB by using an 
> other hub.
> 
> You can find the branch for this work here:
> https://gitlab.freedesktop.org/louischauvet/kernel/-/tree/b4/vkms-mst

I think this is exactly the kind of things where we'll want eBPF I
think. There's no way you'll be able to model each possible test
scenarios for MST through configfs, even more so with a stable
interface.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]

  reply	other threads:[~2024-11-26  8:42 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-22 17:38 [PATCH RFC v2 00/16] drm/vkms: ConfigFS interface Louis Chauvet
2024-11-22 17:38 ` [PATCH RFC v2 01/16] drm/vkms: Add vkms_delete/create_device helper Louis Chauvet
2024-11-22 17:38 ` [PATCH RFC v2 02/16] drm/vkms: Cleanup configuration field on device destroy Louis Chauvet
2024-11-22 17:38 ` [PATCH RFC v2 03/16] drm/vkms: Introduce ConfigFS interface Louis Chauvet
2024-11-22 17:38 ` [PATCH RFC v2 04/16] drm/vkms: Introduce configfs for plane Louis Chauvet
2024-11-22 17:38 ` [PATCH RFC v2 05/16] drm/vkms: Introduce configfs for plane rotation Louis Chauvet
2024-11-22 17:38 ` [PATCH RFC v2 06/16] drm/vkms: Introduce configfs for plane color encoding Louis Chauvet
2024-11-22 17:38 ` [PATCH RFC v2 07/16] drm/vkms: Introduce configfs for plane color range Louis Chauvet
2024-11-22 17:38 ` [PATCH RFC v2 08/16] drm/vkms: Introduce configfs for crtc and encoder Louis Chauvet
2024-11-22 17:38 ` [PATCH RFC v2 09/16] drm/vkms: Introduce configfs for connectors Louis Chauvet
2024-11-22 17:38 ` [PATCH RFC v2 10/16] drm/vkms: Introduce configfs for connector type Louis Chauvet
2024-11-22 17:38 ` [PATCH RFC v2 11/16] drm/vkms: Introduce configfs for plane format Louis Chauvet
2024-11-22 17:38 ` [PATCH RFC v2 12/16] drm/vkms: Introduce configfs for device name Louis Chauvet
2024-11-22 17:38 ` [PATCH RFC v2 13/16] drm/vkms: Introduce configfs for connector status Louis Chauvet
2024-11-22 17:38 ` [PATCH RFC v2 14/16] drm/vkms: Introduce configfs for connector id Louis Chauvet
2024-11-22 17:38 ` [PATCH RFC v2 15/16] drm/vkms: Introduce configfs for connector EDID Louis Chauvet
2024-11-22 17:38 ` [PATCH RFC v2 16/16] drm/vkms: Introduce configfs for encoder type Louis Chauvet
2024-11-22 17:44 ` [PATCH RFC v2 00/16] drm/vkms: ConfigFS interface Louis Chauvet
2024-11-26  8:42   ` Maxime Ripard [this message]
2024-12-17 16:42     ` Louis Chauvet
2025-02-19  9:28       ` Maxime Ripard
2025-02-19 13:15         ` Simona Vetter
2025-02-19 16:28           ` Louis Chauvet
2025-02-20  9:43             ` Simona Vetter
2025-02-25 15:46               ` Louis Chauvet

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=20241126-overjoyed-knowing-cuttlefish-c8d0f6@houat \
    --to=mripard@kernel.org \
    --cc=airlied@gmail.com \
    --cc=arthurgrillo@riseup.net \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hamohammed.sa@gmail.com \
    --cc=jeremie.dautheribes@bootlin.com \
    --cc=jose.exposito89@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mairacanal@riseup.net \
    --cc=melissa.srw@gmail.com \
    --cc=miquel.raynal@bootlin.com \
    --cc=nicolejadeyee@google.com \
    --cc=rodrigosiqueiramelo@gmail.com \
    --cc=seanpaul@google.com \
    --cc=simona.vetter@ffwll.ch \
    --cc=simona@ffwll.ch \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=tzimmermann@suse.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.