Le 09/05/24 - 18:18, Jim Shargo a écrit : > Sima--thanks SO MUCH for going through with everything leaving a > detailed review. I am excited to go through your feedback. > > It makes me extremely happy to see these patches get people excited. > > They've bounced between a few people, and I recently asked to take > them over again from the folks who were most recently looking at them > but haven't since had capacity to revisit them. I'd love to contribute > more but I am currently pretty swamped and I probably couldn't > realistically make too much headway before the middle of June. > > José--if you've got capacity and interest, I'd love to see this work > get in! Thanks!! Please let me know your timeline and if you want to > split anything up or have any questions, I'd love to help if possible. > But most important to me is seeing the community benefit from the > feature. > > And (in case it got lost in the shuffle of all these patches) the IGT > tests really make it much easier to develop this thing. Marius has > posted the most recent patches: > https://lore.kernel.org/igt-dev/?q=configfs > > Thanks! > -- Jim > > > > On Wed, May 8, 2024 at 2:17 PM José Expósito <jose.exposito89@xxxxxxxxx> wrote: > > > > Hi everyone, > > > > I wasn't aware of these patches, but I'm really glad they are getting > > some attention, thanks a lot for your review Sima. > > > > Given that it's been a while since the patches were emailed, I'm not > > sure if the original authors of the patches could implement your > > comments. If not, I can work on it. Please let me know. > > > > I'm working on a Mutter feature that'd greatly benefit from this uapi > > and I'm sure other compositors would find it useful. > > > > I'll start working on a new version in a few days if nobody else is > > already working on it. > > > > Best wishes, > > José Expósito Hi all! Very nice to see other people working on this subject. As the series seemed inactive, I started two weeks ago to rebase it on top of [1]. I also started some work to use drmm_* helpers instead of using lists in vkms. I currently struggle with a deadlock during rmmod. I need to clean my commits, but I can share a WIP version. Maybe we can discuss a bit the comment from Daniel (split init between default/configfs, use or not a real platform device...) For the split, I think the first solution (struct vkms_config) can be easier to understand and to implement, for two reasons: - No need to distinguish between the "default" and the "configfs" devices in the VKMS "core". All is managed with only one struct vkms_config. - Most of the lifetime issue should be gone. The only thing to synchronize is passing this vkms_config from ConfigFS to VKMS. The drawback of this is that it can become difficult to do the "runtime" configuration (today only hotplug, but I plan to add more complex stuff like DP emulation, EDID selection, MST support...). Those configuration must be done "at runtime" and will require a strong synchronization with the vkms "core". Maybe we can distinguish between the "creation" and the "runtime configuration", in two different configFS directory? Once a device is created, it is moved to the "enabled" directory and will have a different set of attribute (connection status, current EDID...) For the platform driver part, it seems logic to me to use a "real" platform driver and a platform device for each pipeline, but I don't have the experience to tell if this is a good idea or not. [1]: https://lore.kernel.org/dri-devel/20240409-yuv-v6-0-de1c5728fd70@xxxxxxxxxxx/ Thanks, Louis Chauvet -- Louis Chauvet, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
