On Sat, Oct 30, 2021 at 1:49 PM Mauro Carvalho Chehab <mchehab@xxxxxxxxxx> wrote: > Em Sat, 30 Oct 2021 18:50:14 +0900 > Tsuchiya Yuto <kitakar@xxxxxxxxx> escreveu: ... > What I'm saying is that, IMHO, we should: > > 1. Fix the ioctls in order to allow a normal app to use it. I'm > already doing some work on this sense. We should ensure that the > driver will pass v4l2-compliance tests on this step; > > 2. remove VIDEO_ATOMISP_ISP2401, making the driver to auto-detect the > register address differences between ISP2400 and ISP2401; > > 3. Cleanup the driver code, removing the abstraction layers inside it; > > 4. Migrate the sensor drivers out of staging (or re-using existing > drivers); > > 5. Remove the logic which sets up pipelines inside it, moving it to > libcamera and implement MC support; > > 6. Move it out of staging. > > This is easily said than done, as steps 2-6 are very complex and will > require lots of work. Also, both ISP2400 and 2401 should be tested > while doing some of those major reworks, in order to avoid breakages. This is a great roadmap nevertheless! However, we missed one important step here, i.e. persuade Intel to clarify license of the firmware (for distirbution) and make sure we have it in Linux firmware project, so it won't get lost. > Btw, v4l2grab app (at v4l-utils) already works. This is a very simple > app, written to allow stream testing. It doesn't do anything fancy, > like trying to enumerate the formats, and it needs to be set to a > resolution lower than the one announced by the sensor, probably due > to some bug at the COPY pipeline settings at atomisp driver. > > qv4l2, for instance, causes a driver OOPS when it calls G/S_PRIORITY > ioctls. -- With Best Regards, Andy Shevchenko
