Well, the DVB API as specified by Nokia says that FE_SET_FRONTEND
should start tuning, and the result (failure or success) is relayed
to the application by means of an event with FE_GET_EVENT.
I.e. one FE_SET_FRONTEND -> one FE_GET_EVENT. But it's also
possible for the frontend to generate additional events, e.g.
when the cable is unplugged and replugged.
The frontend code should do what it can get a lock, and if that
fails, report the failure. IMHO this is the job of the driver,
because the timeouts depend on the type of frontend (or even
on the frontend making and model).
But Holger thought differently, and said the application should
do its own timeouts, because the driver cannot know how
long it wants to wait before assuming failure. The code
also generated superflous events during tuning. After some
debate he put in the current FE_TIMEDOUT cruft (with an arbitrarily
chosen timeout), which essentially means "your tuning attempt
already timed out, so the following tuning-failed event is
superflous and can be discarded". Or something like this
(I never quite understood it).
Yeah, that is pretty much my thinking. I don't see how the Nokia API could
actually work in the real world. Unless we were prepared to break with the
Nokia API, and have apps do timeouts, I don't know if theres any point in me
attempting to fix it, because whatever I do, it will be a hack, and not work
in all situations. The driver just doesn't have enough information on what
the app is wanting it to do.