lkml.org 
[lkml]   [2016]   [Oct]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [RFC] v4l2 support for thermopile devices
    On Fri, Oct 28, 2016 at 2:53 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
    > Hi Matt,
    >
    > On 28/10/16 22:14, Matt Ranostay wrote:
    >>
    >> So want to toss a few thoughts on adding support for thermopile
    >> devices (could be used for FLIR Lepton as well) that output pixel
    >> data.
    >> These typically aren't DMA'able devices since they are low speed
    >> (partly to limiting the functionality to be in compliance with ITAR)
    >> and data is piped over i2c/spi.
    >>
    >> My question is that there doesn't seem to be an other driver that
    >> polls frames off of a device and pushes it to the video buffer, and
    >> wanted to be sure that this doesn't currently exist somewhere.
    >
    >
    > Not anymore, but if you go back to kernel 3.6 then you'll find this driver:
    >
    > drivers/media/video/bw-qcam.c
    >
    > It was for a grayscale parallel port webcam (which explains why it was
    > removed in 3.7 :-) ), and it used polling to get the pixels.

    Yikes parallel port, but I'll take a look at that for some reference :)

    >
    >> Also more importantly does the mailing list thinks it belongs in v4l2?
    >
    >
    > I think it fits. It's a sensor, just with a very small resolution and
    > infrared
    > instead of visible light.
    >
    >> We already came up the opinion on the IIO list that it doesn't belong
    >> in that subsystem since pushing raw pixel data to a buffer is a bit
    >> hacky. Also could be generically written with regmap so other devices
    >> (namely FLIR Lepton) could be easily supported.
    >>
    >> Need some input for the video pixel data types, which the device we
    >> are using (see datasheet links below) is outputting pixel data in
    >> little endian 16-bit of which a 12-bits signed value is used. Does it
    >> make sense to do some basic processing on the data since greyscale is
    >> going to look weird with temperatures under 0C degrees? Namely a cold
    >> object is going to be brighter than the hottest object it could read.
    >
    >
    >> Or should a new V4L2_PIX_FMT_* be defined and processing done in
    >> software?
    >
    >
    > I would recommend that. It's no big deal, as long as the new format is
    > documented.
    >
    >> Another issue is how to report the scaling value of 0.25 C
    >> for each LSB of the pixels to the respecting recording application.
    >
    >
    > Probably through a read-only control, but I'm not sure.
    >
    > Regards,
    >
    > Hans
    >
    >>
    >> Datasheet:
    >> http://media.digikey.com/pdf/Data%20Sheets/Panasonic%20Sensors%20PDFs/Grid-EYE_AMG88.pdf
    >> Datasheet:
    >> https://eewiki.net/download/attachments/13599167/Grid-EYE%20SPECIFICATIONS%28Reference%29.pdf?version=1&modificationDate=1380660426690&api=v2
    >>
    >> Thanks,
    >>
    >> Matt
    >> --
    >> To unsubscribe from this list: send the line "unsubscribe linux-media" in
    >> the body of a message to majordomo@vger.kernel.org
    >> More majordomo info at http://vger.kernel.org/majordomo-info.html
    >>
    >

    \
     
     \ /
      Last update: 2016-10-29 05:01    [W:5.354 / U:0.676 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site