On Mon, May 13, 2024 at 12:03:07PM +0300, Marius Vlad wrote: > Hi all, > On Mon, May 13, 2024 at 10:08:38AM +0200, José Expósito wrote: > > On Fri, May 10, 2024 at 06:19:45PM +0200, Louis Chauvet wrote: > > > 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. > > > > Hi Louis, > > > > If you could share a RFC/WIP series it would be awesome! > > > > Since you are already working on the kernel patches (and I guess IGT?), > > I'll start working on a libdrm high level API to interact with VKMS from > > user-space on top of your patches. I'll share a link as soon as I have a > > draft PR. > > Just out of curiosity what API would that be? These should fairly > simple that they can be configured from a shell script > (mount/mkdir/rm/echo/umount). Believe should be easy enough to test stuff with > bunch scripts like that. My plan is to add a very thin C API around mkdir/rmdir/etc. It is true that VKMS can be configure easily using a bash script; however, compositors with test suites written in C (or with bindings to libdrm) would have to write similar wrappers around the mkdir/rmdir/etc calls. I think that it could be beneficial for them to have a shared wrapper available in libdrm. > Perphas landing the I-G-T tests first (assuming we're settled > on how exactly this would work) might be of greated help to get a green lit > the kernel driver side? Skip if vkms/configfs/something else that tells > us VKMS doesn't have ConfigFS eneabled, and run it when that is on. > > The lastest iteration was shared by Jim at > https://lore.kernel.org/igt-dev/20230901092819.16924-1-marius.vlad@xxxxxxxxxxxxx/ > > That way sub-sequent BAT CI would pick up issues, and can also used > independently by Louis. Should also divide the work-load evenly with > Louis focusing on the just the driver. Happy to review and test it. > > > > > > 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. > > > > I agree, this seems like the easiest solution. > > > > > 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...) > > > > Once the device is enabled (i.e, `echo 1 > /config/vkms/my-device/enabled`), > > would it make sense to use sysfs instead of another configfs directory? > > The advantage is that with sysfs the kernel controls the lifetime of the > > objects and I think it *might* simplify the code, but I'll need to write a > > proof of concept to see if this works. > Can indeed sysfs be used similar to ConfigFS? To me it sounds like sysfs is a > view into a kernel objects, mostly for viewing and slight modifications > but not manipulating, adding/removing, on the fly, various things. Sort > of see it the other way around, device enabled with sysfs but > configuration happens through ConfigFS. At least from a user-space pov. > > > > > 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. > > > > I'm afraid I don't know which approach could work better. Trusting Sima and > > Maíra on this one. > > > > Jose > > > > > [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
