Hi Hans & Mauro. So I sent a few patches today implementing some of what was discussed here. I added support for modprobe/rmmod, bind/unbind and kmemleak results at the test-media script by basically adapting the implementation for vim2m. The initial compliance test part is missing, of course. > I'm not a DVB expert, but I was thinking of testing if it can discover > channels, and perhaps just a test to stream data without checking if > it is > actually valid video. > > The problem is that I am not all that familiar with the DVB utilities > so I > don't know if anything can be automated. Mauro, can you chime in on the above please? Some of the last changes for vidtv broke some very minor details in the driver. This meant that some of the tables would not get picked up by userspace software, even though the driver itself did not crash. I wonder whether this sort of failure can be picked up in some automated way? > An alternative is to start adding dtv support to v4l2-compliance. That utility > already has media controller support, but it needs a bit of work to comfortably > integrate DTV support as well. I can help with that if you want to go > in that > direction. v4l2-compliance would need a bit of refactoring, but it is > nice to > have the tests there since that makes it easy to support hybrid > devices with a > single compliance utility. I am still getting acquainted with this tool, but otherwise I am fine with that. Also, as let's recap this from a past email from Mauro: > I suspect that, before that (or together with such tooling), we need > to properly implement the frontend ioctl, validating the per delivery > system parameters, as, right now, it just accepts anything from > userspace. Mauro, can you give me some tips on how to get started? I assume there's some technical documentation detailing what would be considered valid values for the different delivery systems in use today? Also, where should I add the checks? Is it at "vidtv_demod_set_frontend()" ? -- Daniel
