[libcamera-devel] Video recording on PinePhone Re: libcamera on pinephone

Pavel Machek pavel at ucw.cz
Sat Jul 16 00:52:45 CEST 2022


Hi!

> > > > Wow. Ok, uncached explains things. Is it easy to switch to do read()
> > > > from /dev/videoX? That should be easy to do, not require ABI changes,
> > > > and should improve performance in this case...
> > > 
> > > read() is deprecated and won't help much as there will still be a copy
> > > reading from uncached memory. You can get the same result with a
> > > memcpy() of the whole frame in the application.
> > 
> > First, let me begin by saying that passing uncached memory to userland
> > is rude and maybe dangerous. There are some CPU errata, for
> > example. Placing futex in uncached memory might be fun. Userspace is
> > not really equipped to deal with uncached memory.
> 
> I'd be curious to know use cases for placing a futex in a video buffer
> though :-)

To demonstrate the CVE, obviously :-).
> 
> > Second, no. If we do read(), it is simple interface, kernel will be
> > doing the copying, and it is free to do the usual magic to speed
> > things up. (I suppose simply working with memory as cached and using
> > flush_dcache_range). 
> 
> Regardless of whether or not drivers could speed things up with read(),
> read() is not the way forward. It's deprecated for V4L2 camera devices,
> so we won't use it in libcamera, the way forward is to fix V4L2 memory
> mapping with cache management.

If I wanted to attempt that, do you have hints/ideas where to start?

Best regards,
								Pavel
-- 
People of Russia, stop Putin before his war on Ukraine escalates.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://lists.libcamera.org/pipermail/libcamera-devel/attachments/20220716/19b0692b/attachment.sig>


More information about the libcamera-devel mailing list