diy: fix upside down camera image on Waveshare Touch LCD 2

[bota87]

The camera sensor is mounted the right way up on this board, so the CAMERA_ROTATE_180 default was flipping the image.

[jgriffiths]

@cateim Any chance I can get an ack on this change from you? thanks!

[cateim]

@CaTeIM Any chance I can get an ack on this change from you? thanks!

Absolutely! I'll check it out and get back to you with what I find.

[cateim]

@jgriffiths Testing result:

Tested on a Waveshare ESP32-S3-Touch-LCD-2 with an OV5640 camera module:

• CONFIG_CAMERA_ROTATE_180=y (current master default): preview is correct.
• CONFIG_CAMERA_ROTATE_180=n (this PR): preview is upside down.

So I can't ack this as-is. It fixes one module and regresses another on the same board.

Why both results are valid

The camera on this board is a detachable module on the 24-pin FPC socket, and the Waveshare wiki lists both OV2640 and OV5640 as supported. The firmware already treats them differently at init: set_hmirror(1) + set_vflip(1) for GC0308 (main/camera.c:303-311) and set_vflip(1) for OV3660/OV5640 (main/camera.c:315-321), while OV2640 gets no hardware transform at all. The module is also physically mounted by the builder, so its orientation is an assembly variable rather than a board property.

@bota87 which camera module is on your unit? That's the datum that settles this.

Why flipping the default can't be the fix

Whichever default wins, the other half of the builders can't correct it. The Camera Orientation menu is visible if HAS_CAMERA && BOARD_TYPE_CUSTOM (main/Kconfig.projbuild:331), so under BOARD_TYPE_WS_TOUCH_LCD2 the symbol has no visible prompt and always falls back to its default. Editing sdkconfig by hand does not stick across a reconfigure.

Note: this is preview-only. The QR decoder gets the raw sensor framebuffer (fb->buf, main/camera.c:362), not the rotated copy, so an upside-down preview still scans normally. No functional regression either way.

Suggested direction

In the 0/180 family both copy_camera_image_0 and copy_camera_image_180 are already compiled in, and the copy function is already a runtime pointer (main/camera.c:376-377). Selecting between them at runtime from camera_info->model, alongside the existing set_vflip quirks, would cover OV2640 and OV5640 on this board without either side regressing. I'm happy to open a PR for that if you agree with the approach.