Thank you for the detailed explanation! > All the components can be found in https://launchpad.net/~oem-solutions-group/+archive/ubuntu/intel-ipu6, and are being proposed for inclusion to Ubuntu archive at. the same time
What's the status of the inclusion of the entire stack in Jammy? I don't see ipu6-camera-hal or ipu6-camera-bins packages in Ubuntu at all, for example. Right now, it seems to me that you're essentially asking for new features in v4l2loopback in Focal because they are required to make this new out-of-archive proprietary stack work. I assume that you're seeking to justify this SRU on the basis of our hardware enablement policy, as you've not stated any other justification in your SRU supplied information. But I'm not sure how this fits in with Ubuntu's existing hardware enablement policy, unless every required component for the entire enablement is also being added to Focal. Otherwise, if out-of- archive software will still be required to make the hardware enablement work, then why do the required feature additions to v4l2loopback need to go into the archive rather than the out-of-archive place? Ubuntu SRU policy requires that changes being made are "fixed" in the development release first. In this case I think the entire solution needs to be demonstrated working in Jammy without the need for an out- of-archive source - not just the v4l2loopback component. Otherwise, I don't think it makes sense to justify the feature addition to v4l2loopback on the basis of hardware enablement (as I assume you're seeking to do) as there wouldn't be a hardware enablement in Ubuntu itself actually happening. Please complete the entire hardware enablement in Jammy first - presumably using the restricted archive component as necessary - before proceeding with the hardware enablement in the Ubuntu archive in Focal. In the meantime, if users need to install out-of-archive (eg. PPA) software to get the stack working anyway, then it shouldn't be onerous for them to also bump v4l2loopback with the feature required. The reason I'm pushing on this is that I think there's quite a bit of risk in how the rest of the enablement will happen in Focal, which might lead to development iteration for users in a stable release which really should be avoided. We mitigate this by requiring fixes to be demonstrated to be fully functional and tested in the development release first, and I think that it's particularly important to ensure that is done here because this is a particularly complex case. I would also prefer to see the entire enablement in Focal being performed at once (after Jammy is complete) so that it can be tested and verified as a whole, rather than a component at a time. Otherwise we'll end up testing something different from the actual goal for users when doing v4l2loopback first, which risks those further iterations in a stable release. With just the v4l2loopback feature being added here, it becomes impossible for me to add "Check that a user can actually use the hardware being enabled as expected" to the test plan for SRU verification. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1921474 Title: Support client usage notification via V4l2 Event API To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/1921474/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
