G5 X / 32 bpp display ( was Adding new cameras, applying patches into trunk (with source code prepar

Attempt 2 3.


Summary:
- Reverted back to using THUMB_FW as the main controller for building old / new cameras.
- Added a BITMAP_RGBA control in the Makefile system for G5X
- G5X (via BITMAP_RGBA) uses .o3 for compiling files to avoid clashes with other D6 cameras.
- Split gui_draw, live_view and zebra source into seperate files based on bitmap type (_8bpp, _yuv and _rgba), selection is controlled using similar method as selecting build folder (.o, .o2 and .o3)


The last change with splitting the files up is probably not ideal (lots of duplication); but it make it easier to understand where each bitmap type needs changes. There are other areas where we might be able to utilise this (edge_overlay, histogram, etc). Have not investigated all these for the 32bpp bitmap yet.

Edit: attachment remove - does not work

Edit2: new attachment. Also added screenshot of the G5X RGBA bitmap.

Phil.

new attachment.

sx280: CHDK overlay seems okay

Also added screenshot of the G5X RGBA bitmap.

Do these buffers ever have different content? For example, when the Canon menu is visible.
One more request, though a bit off-topic here: can you upload the g5x cpuinfo?

Quote from: philmoz on 01 / May / 2019, 06:26:05

new attachment.

sx280: CHDK overlay seems okay

Phew - that's a relief

Quote

Also added screenshot of the G5X RGBA bitmap.

Do these buffers ever have different content? For example, when the Canon menu is visible.
One more request, though a bit off-topic here: can you upload the g5x cpuinfo?

CPUINFO.TXT attached.


Also added another screenshot of the Canon OSD in rec mode.
Looking at this more closely it would appear that it's not two buffers; but one 480 high interleaved buffer.

G5X has a single 720x480 bitmap buffer - not sure what I was thinking before.

EDIT: I remembered why I treated the bitmap as two buffers in the code.
By pretending the buffer is twice as wide and half the height I avoided implementing 2x vertical scaling in the CHDK code.
When drawing pixels I just plot them in both left and right halves at the same time, this give me double height pixels without any scaling.

CPUINFO.TXT attached.

Thanks, matches M10 except for MPU region #6 which is unused here.

Also added another screenshot of the Canon OSD in rec mode.

That matches what I would see in the first RGBA buffer in my cams. The AF rectangle, for example, is always drawn on the second buffer.
The camera obviously does have an AF frame, and it is drawn somewhere. The yuv+opacity buffers should also be present somewhere that is accessible from the display hardware.
I would not rule out the possibility that, for this camera, the creators chose to configure the hw differently. On other cams, they seemed to keep memory mappings uniform between CPUs (ARM and Xtensa cores see the main RAM from address 0).
May I ask how you retrieve RAM content for purposes of finding something in it? Have you made full RAM dumps, and if so, with what method (cached address, uncached address, address passed directly to write() or memcpy'd to a buffer before)?

Quote from: philmoz on 01 / May / 2019, 23:55:02

CPUINFO.TXT attached.

Thanks, matches M10 except for MPU region #6 which is unused here.

Quote

Also added another screenshot of the Canon OSD in rec mode.

That matches what I would see in the first RGBA buffer in my cams. The AF rectangle, for example, is always drawn on the second buffer.
The camera obviously does have an AF frame, and it is drawn somewhere. The yuv+opacity buffers should also be present somewhere that is accessible from the display hardware.
I would not rule out the possibility that, for this camera, the creators chose to configure the hw differently. On other cams, they seemed to keep memory mappings uniform between CPUs (ARM and Xtensa cores see the main RAM from address 0).
May I ask how you retrieve RAM content for purposes of finding something in it? Have you made full RAM dumps, and if so, with what method (cached address, uncached address, address passed directly to write() or memcpy'd to a buffer before)?

Yes, there is another buffer for the AF frame and grid overlay; but it is drawn below the main OSD elements in record mode only so I didn't use it. It's not displayed in playback mode.

I'm just using open/write/close to dump RAM from the cached addresses.

I hope to find the YUV buffer(s) so I can do the bits that use them (zebra, edge overlay, historgram, live view, etc).

EDIT: Light bulb moment Found the YUV buffers that the RGBA buffers are transferred to; but they only contain the OSD, not the sensor image. So I'm guessing the viewport is yet another set of YUV buffers somewhere else (more spelunking needed). So I could use either the RGBA buffer or the YUV buffers for the CHDK display. Will need to look closer at the other D6 YUV code to see what might work better.

EDIT2: Found all the YUV buffers (live view & overlays). Live view is working in chdkptp using the YUV and opacity buffers like the other D6 cameras. CHDK display is drawn to the RGBA buffer.