Hi all! The v4l2-compliance utility checks whether device drivers follows the V4L2 specification. What is missing are 'profiles' detailing what device drivers should and shouldn't implement for particular device classes. This has been discussed several times, but until now no attempt was made to actually write this down. This RFC is my attempt to start this process by describing three profiles: the core profile that all drivers must adhere to, a profile for a radio receiver and a profile for a radio transmitter. Missing in this RFC is a description of how tuner ownership is handled if a tuner is shared between a radio and video driver. This will be discussed during the workshop next week. I am not certain where these profile descriptions should go. Should we add this to DocBook, or describe it in Documentation/video4linux? Or perhaps somehow add it to v4l2-compliance, since that tool effectively verifies the profile. Also note that the core profile description is more strict than the spec. For example, G/S_PRIORITY are currently optional, but I feel that all new drivers should implement this, especially since it is very easy to add provided you use struct v4l2_fh. Similar with respect to the control requirements which assume you use the control framework. Note that these profiles are primarily meant for driver developers. The V4L2 specification is leading for application developers. While writing down these profiles I noticed one thing that was very much missing for radio devices: there is no capability bit to tell the application whether there is an associated ALSA device or whether the audio goes through a line-in/out. Personally I think that this should be fixed. Comments are welcome! Regards, Hans Core Profile ============ All V4L2 device nodes must support the core profile. VIDIOC_QUERYCAP must be supported and must set the device_caps field. bus_info must be a unique string and must not be empty (pending result of the upcoming workshop). VIDIOC_G/S_PRIORITY must be supported. If you have controls then both the VIDIOC_G/S_CTRL and the VIDIOC_G/S/TRY_EXT_CTRLS ioctls must be supported, together with poll(), VIDIOC_DQEVENT and VIDIOC_(UN)SUBSCRIBE_EVENT to handle control events. Use the control framework to implement this. VIDIOC_LOG_STATUS is optional, but recommended for complex drivers. VIDIOC_DBG_G_CHIP_IDENT, VIDIOC_DBG_G/S_REGISTER are optional and are primarily used to debug drivers. Video, Radio and VBI nodes are for input or output only. The only exception are video nodes that have the V4L2_CAP_VIDEO_M2M(_MPLANE) capability set. Video nodes only control video, radio nodes only control radio and RDS, vbi nodes only control VBI (raw and/or sliced). Streaming I/O is not supported by radio nodes. Radio Receiver Profile ====================== Radio devices have a tuner and (usually) a demodulator. The audio is either send out to a line-out connector or uses ALSA to stream the audio. It implements VIDIOC_G/S_TUNER, VIDIOC_G/S_FREQUENCY and VIDIOC_ENUM_FREQ_BANDS. If hardware seek is supported, then VIDIOC_S_HW_FREQ_SEEK is implemented. It does *not* implement VIDIOC_ENUM/G/S_INPUT or VIDIOC_ENUM/G/S_AUDIO. If RDS_BLOCK_IO is supported, then read() and poll() are implemented as well. If a mute control exists and the audio is output using a line-out, then the audio must be muted on driver load and unload. On driver load the frequency must be initialized to a valid frequency. Note: There are a few drivers that use a radio (pvrusb2) or video (ivtv) node to stream the audio. These are legacy exceptions to the rule. FM Transmitter Profile ====================== FM transmitter devices have a transmitter and modulator. The audio is transferred using ALSA or a line-in connector. It implements VIDIOC_G/S_MODULATOR, VIDIOC_G/S_FREQUENCY and VIDIOC_ENUM_FREQ_BANDS. It does *not* implement VIDIOC_ENUM/G/S_OUTPUT or VIDIOC_ENUM/G/S_AUDOUT. If RDS_BLOCK_IO is supported, then write() and poll() are implemented as well. On driver load the frequency must be initialized to a valid frequency. -- 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
