On Thursday 17 Nov 2005 15:51, Johannes Stezenbach wrote:
> On Thu, Nov 17, 2005 Andrew de Quincey wrote:
> > What should I do with the overridable tuning patch... should I check it
> > in?
> >
> > Its basically what I posted last, except the userspace API is now:
> >
> > typedef enum fe_tune_mode_flags {
> > FE_TUNE_MODE_ONESHOT = 0x01, /* if set, frontend will be oneshot mode */
> > } fe_tune_mode_flags_t;
> >
> > #define FE_SET_FRONTEND_TUNE_MODE _IO('o', 81) /* unsigned int */
>
> We should not introduce new typedefs.
>
> I still think we should use #defines for the flags, not an enum,
> i.e. videodev2.h style. OTOH the coding style within frontend.h.
> A few more opinions would help to decide this.
Ah yeah I saw the discussion on that in that thread you linked about scanning
w.r.t typedefs - I'll convert it into #defines.
> Please also add a comment in frontend.h that the tune mode is
> reset to default (zig-zag or auto mode) on each open().
> And "oneshot mode" in the comment is IMHO totally unclear,
> you need to spell it out as e.g. "disable zig-zag".
Sure.
> One semantic question: With FE_TUNE_MODE_ONESHOT, will the
> frontend thread still monitor the frontend and generate
> signal lost and locked events? Because I think that's not
> useful during scanning, you're better off calling FE_READ_STATUS
> manually.
Correct - it will not monitor/ generate them.
