[libcamera-devel] Fwd: Surface Go VCM type (was: Need to pass acpi_enforce_resources=lax on the Surface Go (version1))
Laurent Pinchart
laurent.pinchart at ideasonboard.com
Mon Nov 15 14:33:56 CET 2021
On Fri, Nov 12, 2021 at 01:37:27PM +0200, Andy Shevchenko wrote:
> On Fri, Nov 12, 2021 at 12:46:56PM +0200, Laurent Pinchart wrote:
> > On Fri, Nov 12, 2021 at 10:32:31AM +0000, Dave Stevenson wrote:
> > > On Thu, 11 Nov 2021 at 22:04, Laurent Pinchart wrote:
>
> > > Sorry, just my two-penneth as someone who has to support general
> > > users, rather than just develop platforms or address specific use
> > > cases.
> >
> > As mentioned above, I certainly don't oppose improving power management
> > for VCMs, as well as the VCM control API in general, as long as we can
> > cover all use cases. I'm not familiar enough with the use cases to tell
> > whether making the kernel side more "clever" would be just fine or could
> > cause issues.
>
> Personally I found the
>
> kernel <--> library in userspace <--> another library or app
>
> schema is more flexible in many ways:
> - we unburden kernel from the heavy code that has nothing to
> do directly with HW
> - we allow nevertheless to use kernel ABIs if needed
> - we decrease burden of the ABI evolution by doing it in only
> two places
I think that's generally true (provided the low-level userspace library
is well designed). In this specific case, we're moving towards that
model, and even if it ends up being better, I agree with Dave that the
transition can be painful.
> After all this kind of schema might lead us at some point to the
> shifting of 'we don't break user space' paradigm to the 'we hardly
> try not to break user space and do not break library ABIs / APIs
> in user space'.
Is that an officially allowed policy for kernel subsystems ?
--
Regards,
Laurent Pinchart
More information about the libcamera-devel
mailing list