l4t 28.2 camera sensor driver : do I really need to put 5 x 5 = 25 mode's entries in device tree ?

Robotics & Edge Computing Jetson & Embedded Systems Jetson TX1
1

Hello

I am developing a driver for a cmos sensor that can come in two versions that I can recognize in the driver : monochrome or bayer, and that can deliver in standard mode (not counting ROI mode) 5 different resolution. Moreover it can also reverse the image vertically or horizontally thus changing the order of the bayer sequence from rggb to bggr or grbg or gbrg. As the mode’s definition seems to describe a fixed resolution and a fixed pixel type, do I really need to fill the dt with 5 (monochrome + 4 bayer variations) X 5 (resolutions) = 25 mode’s, or is there a better solution, still compatible with nvcamera-daemon/nvcamerasrc and the camera_common infrastructure ?

2

I think the argus/nvcamera-daemon should have problem to support this, due to there no API for you to select the mode from the same resolution but different pixel type.

3

Let’s take the problem by another side then : how can I do a simple and efficient debayering from my bayer cmos sensor in a gstreamer pipeline using the isp but not using nvcamera-daemon ?

4

Using cuda for softway debayering is a option.

5

From another way then : is it possible to access argus/nvcamera-daemon/nvcamerasrc sources or the part that chooses resolution and pixel_phase in order to enhance it (eventually after signing a NDA) ?

6

Why do you need different pixel type input source event argus/nvcamera-daemon output are YUV/NV12 only?

7

I need only to have a simple way to tell nvcamerasrc the width, height and pixel_phase (“rggb”, “bggr”, “grbg” or “gbrg”) produced by my sensor, or the width, height, default pixel_phase and vertical and horizontal flip.

8

May I know the purpose and why?

9

My need is that the driver computes and exposes the pixel_phase (as a MEDIA_BUS_FMT) in function of user-settings like VFLIP, HFLIP and perhaps ROI without asking the user to compute himself the resultant pixel_phase and put it in some dtb file.

10

I can propose a feature request to designer, however it will take long long time to go through the process and it could be rejected finally. And be honest as I know this source would be public to any of partner until now.
I would suggest to implement a software debaying element and implement the kernel driver for your purpose. That’s a way you can fully control by yourself.