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

@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.

@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.

I'm happy to open a PR for that if you agree with the approach.

@cateim Awesome, agree that a runtime check sounds like the right solution. Can you cc: @bota87 on your PR so they can test it too? Thanks!

Hi @cateim, I have an OV5640 too (SKU 29456), came with my -C board (SKU 29668).

Same board, same camera, opposite result. Happy to test your PR when it's ready.

Thanks @bota87. Same board, same OV5640, opposite results: both modules identify as CAMERA_OV5640, so detecting by sensor model is off the table. The difference must be physical (module mounting or PCB revision), which software cannot see.

@jgriffiths so I'd adjust the plan: make it a user setting instead, like the existing Flip Orientation toggle. A persisted flag that picks copy_camera_image_0 vs copy_camera_image_180 at runtime; both are already compiled and the copy function is already a runtime pointer. The build default stays as the initial value and whoever's unit differs corrects it once.

If that sounds right I'll open the PR and cc @bota87 for testing.

@cateim Sounds like a flag is unavoidable - in that case please add it as a bit to the existing GUI_FLAGS_FIELD, thanks!