G5 X / 32 bpp display ( was Adding new cameras, applying patches into trunk (with source code prepar - General Discussion and Assistance - CHDK Forum

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

  • 15 Replies
  • 3737 Views
*

Offline philmoz

  • *****
  • 3450
    • Photos
Advertisements
Patch to add support for the 32bpp bitmap display on the G5X.


We now have 8bpp bitmaps (pre Digic6), 32bpp (G5X) and YUV (Digic6 except G5X).


Because gui_draw.c was becoming an #ifdef nightmare I split the code that is specific to the different bitmap types into new files (gui_draw_8bpp.c, gui_draw_32bpp.c and gui_draw_yuv.c), and cleaned up gui_draw.c.


Tested on 8bpp cameras and G5X; but I don't have a YUV bitmap camera so I can't test if I've broken anything (code compiles ok).


Phil.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

*

Offline srsa_4c

  • ******
  • 4451
Patch to add support for the 32bpp bitmap display on the G5X.


We now have 8bpp bitmaps (pre Digic6), 32bpp (G5X) and YUV (Digic6 except G5X).


Because gui_draw.c was becoming an #ifdef nightmare I split the code that is specific to the different bitmap types into new files (gui_draw_8bpp.c, gui_draw_32bpp.c and gui_draw_yuv.c), and cleaned up gui_draw.c.


Tested on 8bpp cameras and G5X; but I don't have a YUV bitmap camera so I can't test if I've broken anything (code compiles ok).
I tested this on my sx280 (640x480 screen), see attached screenshots. RBF codepath drawing built-in font is broken and modules also get bad font(?) size information. Cam was started with config files removed.

*

Offline philmoz

  • *****
  • 3450
    • Photos
Patch to add support for the 32bpp bitmap display on the G5X.


We now have 8bpp bitmaps (pre Digic6), 32bpp (G5X) and YUV (Digic6 except G5X).


Because gui_draw.c was becoming an #ifdef nightmare I split the code that is specific to the different bitmap types into new files (gui_draw_8bpp.c, gui_draw_32bpp.c and gui_draw_yuv.c), and cleaned up gui_draw.c.


Tested on 8bpp cameras and G5X; but I don't have a YUV bitmap camera so I can't test if I've broken anything (code compiles ok).
I tested this on my sx280 (640x480 screen), see attached screenshots. RBF codepath drawing built-in font is broken and modules also get bad font(?) size information. Cam was started with config files removed.


Thanks for testing this.


Did you do this as a clean build or had you previously built an 8bpp version?


A quick look at the code suggests there might be a bigger issue with the rbf_font and modules because they use the FONT_WIDTH & FONT_HEIGHT #define values.


Since these are no longer constant for all cameras this breaks the camera independent build assumption.


If you build an 8bpp camera then the modules and libfont.a will be built with 8x16 default font.
If you then build a YUV camera the modules and libfont.a won't be rebuilt unless it's a clean build.


Phil.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

*

Offline reyalp

  • ******
  • 14117
Quote
Did you do this as a clean build or had you previously built an 8bpp version?
The thumb2 firmware object files should be totally separate from the other cams, in .o2 rather than .o. So if building non-thumb2 before hand has an impact, something is really broken. THUMB_FW dependent ifdefs currently appear in "platform independent" code, because it's a totally separate binary.

If G5X / 32bpp needs additional defines in code that was previously under THUMB_FW ifdefs in "platform independent" code, that will need to be addressed. Using THUMB_FW as a shorthand for all the various differences associated with digic 6 was obviously going to run into differences *between* those cams eventually (but IMO the right choice at the time to get something working).

I haven't had a chance to look at the patch yet, will try to do that soon.
Don't forget what the H stands for.


*

Offline philmoz

  • *****
  • 3450
    • Photos
Quote
Did you do this as a clean build or had you previously built an 8bpp version?
The thumb2 firmware object files should be totally separate from the other cams, in .o2 rather than .o. So if building non-thumb2 before hand has an impact, something is really broken. THUMB_FW dependent ifdefs currently appear in "platform independent" code, because it's a totally separate binary.

If G5X / 32bpp needs additional defines in code that was previously under THUMB_FW ifdefs in "platform independent" code, that will need to be addressed. Using THUMB_FW as a shorthand for all the various differences associated with digic 6 was obviously going to run into differences *between* those cams eventually (but IMO the right choice at the time to get something working).

I haven't had a chance to look at the patch yet, will try to do that soon.


Thanks - been a while so I'm a bit rusty on some things :)


Looks like it's probably the order the include files are loaded - I put the DRAW_YUV_BITMAP definition in camera.h; but it's probably not being picked up in some cases. Need to re-think this.

Edit: This going to cause some issue since we will have D6 cameras with different FONT size values. I think I asked this before but why don't we just keep the original FONT_WIDTH and FONT_HEIGHT and use the ASPECT_CORRECTION stuff to take care of the differences. This already translates X co-ords for cameras with 640, 720 or more wide screens. We don't currently have code to handle Y scaling; but adding that would then bring everything back to the original CHDK 'virtual' screen size of 320/360 x 240/270.

Phil.
« Last Edit: 29 / April / 2019, 01:07:49 by philmoz »
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

*

Offline reyalp

  • ******
  • 14117
I split this into a standalone topic since it seems like it will involve some back and forth.

I'm not very familiar with the font stuff, I think you and @srsa_4c were the last ones to work on it, maybe around https://chdk.setepontos.com/index.php?topic=12684.msg127850#msg127850

Looking at the patch, the zebra module #ifndef DRAW_YUV_BITMAP will be problematic too. THUMB_FW and things *directly* dependent on it are currently the only valid platform ifdefs for modules.

If we want all builds of a given instruction set to run on all cameras, we may need to build different modules for different display types and choose at runtime.

Also: Good to have you back  :D
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 4451
If we want all builds of a given instruction set to run on all cameras, we may need to build different modules for different display types and choose at runtime.
Or, build both display library and only link the one that the port needs (yuv or 32bit). Or, build the display lib as part of platform code.

I think I asked this before but why don't we just keep the original FONT_WIDTH and FONT_HEIGHT and use the ASPECT_CORRECTION stuff to take care of the differences. This already translates X co-ords for cameras with 640, 720 or more wide screens. We don't currently have code to handle Y scaling; but adding that would then bring everything back to the original CHDK 'virtual' screen size of 320/360 x 240/270.
Not sure if that's what you mean, but I explained here why I didn't like the 320x240 resolution that many D6 ports would get.
Worth to note that 640x480 models have a 720x480 resolution RGBA surface, and drawing there would eliminate the need for the font scaling / aspect correction.

edit:
Zebra was mentioned. I can tell that (the D6 version) is still horribly buggy, contains dead code and can't cope with higher resolutions. I planned adding/correcting HDMI (resolution) support to my two D6 cams but stopped when I noticed that zebra would crash then.
« Last Edit: 29 / April / 2019, 17:40:37 by srsa_4c »

*

Offline philmoz

  • *****
  • 3450
    • Photos
If we want all builds of a given instruction set to run on all cameras, we may need to build different modules for different display types and choose at runtime.
Or, build both display library and only link the one that the port needs (yuv or 32bit). Or, build the display lib as part of platform code.

I think I asked this before but why don't we just keep the original FONT_WIDTH and FONT_HEIGHT and use the ASPECT_CORRECTION stuff to take care of the differences. This already translates X co-ords for cameras with 640, 720 or more wide screens. We don't currently have code to handle Y scaling; but adding that would then bring everything back to the original CHDK 'virtual' screen size of 320/360 x 240/270.
Not sure if that's what you mean, but I explained here why I didn't like the 320x240 resolution that many D6 ports would get.
Worth to note that 640x480 models have a 720x480 resolution RGBA surface, and drawing there would eliminate the need for the font scaling / aspect correction.


Thanks again. Getting my head back around it now.


Using the 32bpp RGBA bitmap would simplify things - are you sure it's 720x480 (the G5X is 720x240)?


I should be able to add a pre-alpha version of the G5X to SVN soon so there might be something of use there.

CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)


*

Offline srsa_4c

  • ******
  • 4451
Using the 32bpp RGBA bitmap would simplify things - are you sure it's 720x480
Yes, see attachment. It's from a RAM dump, shows the two consecutive rgba buffers.
Quote
(the G5X is 720x240)
:blink: Can you show a similar "screenshot" of the buffer?

*

Offline philmoz

  • *****
  • 3450
    • Photos
Using the 32bpp RGBA bitmap would simplify things - are you sure it's 720x480
Yes, see attachment. It's from a RAM dump, shows the two consecutive rgba buffers.
Quote
(the G5X is 720x240)
:blink: Can you show a similar "screenshot" of the buffer?


Thanks - that would then need 2x vertical scaling in order to keep the rest of the CHDK code consistent with existing cameras (font size, OSD element position etc).


The G5X has two buffers but they are interleaved by row.
The first 864 pixels are the first row of the first buffer (only 720 used).
The next 864 pixels are the first row of the second buffer, and so on.

Edit: What did you use to capture the screenshot from the RAM dump?

« Last Edit: 29 / April / 2019, 18:45:01 by philmoz »
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

 

SimplePortal 2.3.6 © 2008-2014, SimplePortal