DVB ioctl FE_GET_EVENT behaviour broken in 3.3

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



The reason that DVB playback with xine is broken in 3.3 is that the userspace semantics of FE_GET_EVENT have changed. Xine tunes into a DVB channel as follows:

* discards stale frontend events by calling FE_GET_EVENT until there is none left.
* calls FE_SET_FRONTEND with the new frequency.
* starts polling for new frontend events by calling FE_GET_EVENT again.

Xine assumes that *every* FE_GET_EVENT after calling FE_SET_FRONTEND will have dvb_frontend_event.parameters.frequency set to the new frequency, if this channel exists. However, under Linux 3.3, at least the first new event with a newly-plugged-in device has a frequency parameter of zero. I am assuming that Linux is populating the frequency parameter from an internal data structure because xine behaves normally once some other DVB application manages to set it to something other than zero. And xine then continues to behave normally until I unplug the DVB adapter and plug in back in again.

So the question is: why is there no frequency for this first FE_GET_EVENT? Are the parameters incomplete, or shouldn't this event have been sent in the first place?

Cheers,
Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux