[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