pm24.git/drivers/media/test-drivers, branch rust-6.12

media: vivid: loopback based on 'Connected To' controls

2024-06-28T06:00:29Z

Instead of using hardwired video loopback limited to a single vivid instance, use the new 'Connected To' controls to only loopback if an HDMI or S-Video input is connected to another output, which can be in another vivid instance. Effectively this emulates connecting and disconnecting an HDMI/S-Video cable. The Loop Video control is dropped since it has now been replaced by the new 'Connected To' controls. The Display Present has also been dropped since it no longer fits. Signed-off-by: Hans Verkuil Co-developed-by: Dorcas Anono Litunya Signed-off-by: Dorcas Anono Litunya

media: vivid: Add 'Is Connected To' menu controls

2024-06-28T06:00:29Z

The video loopback functionality in vivid is very crude. What we really want is to be able to emulate connecting an HDMI or S-Video input to an HDMI or S-Video output, and the input and output can be in different vivid instances. Effectively this emulates what happens when you physically connect an HDMI or S-Video cable between two devices. In particular, this makes prototyping with vivid much more realistic. This patch creates a menu control for each HDMI or S-Video input. The menu control starts with "Test Pattern Generator" and "None" (i.e. disconnected). After that up to 62 HDMI or S-Video outputs are listed that you can connect the input to. If there are more than 62 HDMI or S-Video outputs, then those will not be included in the menu (currently menucontrols have max 64 entries). If an input is connected to an output, then all other 'Connected To' controls are updated to exclude that output to avoid having multiple inputs connected to the same output. Signed-off-by: Dorcas Anono Litunya Signed-off-by: Hans Verkuil [hverkuil: use u8 in loops in vivid_create_controls() to avoid truncate warning]

media: vivid: add instance number to input/output names

2024-06-28T06:00:29Z

Add the instance number before the input or output number. So "HDMI 1" becomes "HDMI 000-1". This is helps identifying which input or output belongs to which vivid instance. Signed-off-by: Hans Verkuil

media: vivid: don't set HDMI TX controls if there are no HDMI outputs

2024-06-28T06:00:29Z

When setting the EDID it would attempt to update two controls that are only present if there is an HDMI output configured. If there isn't any (e.g. when the vivid module is loaded with node_types=1), then calling VIDIOC_S_EDID would crash. Fix this by first checking if outputs are present. Signed-off-by: Hans Verkuil

media: vivid: vidioc_g_edid: do not change the original input EDID

2024-06-28T06:00:29Z

Returning an EDID for a connected output would modify the original input EDID with the physical address of the output. That causes problems, and it should just update the physical address of the output EDID. Update vivid_hdmi_edid to set the physical address to 0.0.0.0. Signed-off-by: Hans Verkuil

media: vivid: fix CREATE_BUFS support in queue_setup()

2024-06-26T15:28:31Z

While queue_setup was correct for CREATE_BUFS support for video devices, for VBI, SDR and touch devices it was wrong. This was found after adding new v4l2-compliance tests. Signed-off-by: Hans Verkuil

media: vivid: fix wrong sizeimage value for mplane

2024-06-26T15:28:31Z

In several places a division by fmt->vdownsampling[p] was missing in the sizeimage[p] calculation, causing incorrect behavior for multiplanar formats were some planes are smaller than the first plane. Found by new v4l2-compliance tests. Signed-off-by: Hans Verkuil

media: vimc: scaler: Use subdev active state

2024-06-26T14:39:34Z

Store the active formats and crop rectangle in the subdevice active state. This simplifies implementation of the format and selection accessors, and allows using the v4l2_subdev_get_fmt() helper to implement the .get_fmt() operation. The active configuration that is used in the .process_frame() handler is still stored in the vimc_scaler_device structure. The driver could instead access the active state in the .process_frame() handler, but the required locking could interfere with the real time constraints of the frame processing. This data would be stored in registers in the .s_stream() handler for real hardware, storing it in dedicated storage thus mimics a real driver. To differentiate them from the rest of the device private data, move the corresponding fields to a sub-structure of vimc_scaler_device named hw. Signed-off-by: Laurent Pinchart Signed-off-by: Shuah Khan Signed-off-by: Hans Verkuil

media: vimc: debayer: Use subdev active state

2024-06-26T14:39:34Z

Store the active formats and crop rectangle in the subdevice active state. This simplifies implementation of the format and selection accessors, and allows using the v4l2_subdev_get_fmt() helper to implement the .get_fmt() operation. The active configuration that is used in the .process_frame() handler is still stored in the vimc_debayer_device structure. The driver could instead access the active state in the .process_frame() handler, but the required locking could interfere with the real time constraints of the frame processing. This data would be stored in registers in the .s_stream() handler for real hardware, storing it in dedicated storage thus mimics a real driver. To differentiate them from the rest of the device private data, move the corresponding fields to a sub-structure of vimc_debayer_device named hw. Signed-off-by: Laurent Pinchart Signed-off-by: Shuah Khan Signed-off-by: Hans Verkuil

media: vimc: sensor: Use subdev active state

2024-06-26T14:39:34Z

Store the active formats and crop rectangle in the subdevice active state. This simplifies implementation of the format and selection accessors, and allows using the v4l2_subdev_get_fmt() helper to implement the .get_fmt() operation. The active configuration that is used in the .process_frame() handler is still stored in the vimc_sensor_device structure. The driver could instead access the active state in the .process_frame() handler, but the required locking could interfere with the real time constraints of the frame processing. This data would be stored in registers in the .s_stream() handler for real hardware, storing it in dedicated storage thus mimics a real driver. To differentiate them from the rest of the device private data, move the corresponding fields to a sub-structure of vimc_sensor_device named hw. Signed-off-by: Laurent Pinchart Signed-off-by: Shuah Khan Signed-off-by: Hans Verkuil