Em Fri, 22 Apr 2016 10:26:37 +0200 Hans Verkuil <hverk...@xs4all.nl> escreveu:
> Hi Nick, > > On 04/21/2016 11:31 AM, Nick Dyer wrote: > > This is a series of patches to add diagnostic data support to the Atmel > > maXTouch driver. It's a rewrite of the previous implementation which output > > via > > debugfs: it now uses a V4L2 device in a similar way to the sur40 driver. > > > > There are significant performance advantages to putting this code into the > > driver. The algorithm for retrieving the data has been fairly consistent > > across > > a range of chips, with the exception of the mXT1386 series (see patch). > > > > We have a utility which can read the data and display it in a useful format: > > https://github.com/ndyer/heatmap/commits/heatmap-v4l > > > > These patches are also available from > > https://github.com/ndyer/linux/commits/diagnostic-v4l > > > > Any feedback appreciated. > > FYI: we're working on a new buffer type for meta data: > > https://patchwork.linuxtv.org/patch/33938/ > https://patchwork.linuxtv.org/patch/33939/ Nick, One of the things I missed on your patchset is the content of the new format you added (V4L2_PIX_FMT_YS16). You should be patching the V4L2 docbook too, in order to add it there. That's said, if the output is really an image, I don't think it should be mapped via the new V4L2_BUF_TYPE_META_CAPTURE. This type of buffer is meant to be used on non-image metadata, like image statistics to feed auto whitebalance and other similar AAA algorithms. It could still make sense to use the new device type (VFL_TYPE_META) for such drivers, as we don't want applications to identify those devices as if they are a webcam. > > This would be an excellent fit for you. I expect that this new feature would > be > merged soon (for 4.7 or 4.8 at the latest) since it looks all pretty good to > me. > > So let's wait for this to be merged and then you can migrate to the new buffer > type. > > Regards, > > Hans > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Thanks, Mauro
