libcamera: shaders: Fix input sampling when width != stride

When bayer_unpacked.vert is calculating the center and x/yCoord values
stride != width is taken into account for x/yCoord deltas since it is taken
into account by debayer_egl when setting the x part of tex_step uniform.

But it is not taken into account for the center.x which is just directly
copied from textureIn, leading to the input width sampling covering
the entire input stride instead of just covering the input width.

Use the existing and currently unused stride_factor uniform to pass
the width/stride ratio and correct center.x for this. This fixes
the misrendering seen on x86 laptops which is caused by the CSI2 receiver
there requiring a stride which is a multiple of 32 often leading to
stride != width.

Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Reviewed-by: Milan Zamazal <mzamazal@redhat.com>
Tested-by: Robert Mader <robert.mader@collabora.com>
Tested-by: Hans de Goede <johannes.goede@oss.qualcomm.com> # ThinkPad T14s gen 6 (arm64) ov02c10 + X1c gen 12 ov08x40
Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com> # Lenovo X13s
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>

src/libcamera/shaders/bayer_unpacked.vert

@@ -21,7 +21,7 @@ attribute vec2 textureIn;
 
 uniform mat4 proj_matrix;
 
-uniform vec2 tex_size;	/* The texture size in pixels */
+uniform vec2 tex_size;  /* The texture size in pixels */
 uniform vec2 tex_step;
 
 /** Pixel position of the first red pixel in the */
@@ -40,8 +40,10 @@ varying vec4            xCoord;
 /** of the adjacent pixels.*/
 varying vec4            yCoord;
 
+uniform float stride_factor;
+
 void main(void) {
-    center.xy = textureIn;
+    center.xy = vec2(textureIn.x * stride_factor, textureIn.y);
     center.zw = textureIn * tex_size + tex_bayer_first_red;
 
     xCoord = center.x + vec4(-2.0 * tex_step.x,