G5X Porting. - page 2 - DryOS Development - CHDK Forum
« previous next »
Pages: 1 [2] 3 4 5 6 7 ... 10   Go Down

G5X Porting.

  • 93 Replies
  • 39473 Views
*

Offline ghager

  • *
  • 2
Re: G5X Porting.
« Reply #10 on: 05 / March / 2018, 14:31:25 »
Advertisements
I'm not a developer, but I'm wandering if there is anything I can do to help to get CHDK for the G5X. It's a wonderfull camera but it still can have some improvement. I have time and have the camera. Somebody?
Logged
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: G5X Porting.
« Reply #11 on: 05 / March / 2018, 15:56:06 »
Quote from: ghager on 05 / March / 2018, 14:31:25
I'm not a developer, but I'm wandering if there is anything I can do to help to get CHDK for the G5X. It's a wonderfull camera but it still can have some improvement. I have time and have the camera. Somebody?


The G5X appears to have a slightly different display system to other Digic6 cameras.


The port is stalled at the moment as I haven't been able to get the display working properly for CHDK, also I have don't have a lot of spare time to work on CHDK anymore.


Phil.

Logged
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 ghager

  • *
  • 2
Re: G5X Porting.
« Reply #12 on: 06 / March / 2018, 05:34:13 »
Hi Phil,

Thanks for your answer. Is there anything I can do, without the knowlede of programming? Is it difficult to learn? (I have a little knowldedge of html, from 20 years ago...  :D)
Logged
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: G5X Porting.
« Reply #13 on: 05 / May / 2019, 07:42:51 »
After a long hiatus I've managed to get some time on the G5X and now have a build that seems to work pretty well.

Thanks to all the help from reyalp, srsa_4c, and everyone else who've done so much hard work with the Digic6 investigations :)

I've create a new branch in SVN with the G5X changes. There are a few things in the core CHDK code I've updated to support the camera.

I ended up using the YUV bitmap display like the other D6 cameras; but went a slightly different path from what is currently checked in (hence the changes in core and modules).

I've tested a lot of functionality and it seems to work ok; but like all new ports there will be issues.

I'd like to get feedback on whether my changes are working on older cameras and other D6 ports.
If you are able to check out the g5x branch and build and test on other cameras please let me know of any issues.
It seems to work on my cameras; but the G5X is the only D6 camera I have at the moment, so there could be issues with the other D6 ports.

Phil.
Logged
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
Re: G5X Porting.
« Reply #14 on: 05 / May / 2019, 14:23:47 »
Quote from: philmoz on 05 / May / 2019, 07:42:51
If you are able to check out the g5x branch and build
First hurdle
Code: [Select]
../../core/autoiso.c: In function 'live_histogram_read_y':
../../core/autoiso.c:60:9: error: 'for' loop initial declarations are only allowed in C99 or C11 mode
         for (int y=0; y<vp_height; y+=1, img+=vp_offset)
         ^
../../core/autoiso.c:60:9: note: use option -std=c99, -std=gnu99, -std=c11 or -std=gnu11 to compile your codehow come you don't get this error? There don't seem to be any -std switches in any makefiles. I've been avoiding the newer syntax for this exact reason.

edit:
Compilation succeeds if I add -std=gnu99 to CFLAGS, c99 mode doesn't like 'asm'.

edit2:
Testing on sx280.
CHDK menu and display works, RBF fonts work also.
Zebra works, and it seems the screen is erased now. As a result, it now blinks in an irritating manner (due to slow redraw and erasure).
Edge overlay is more broken than before (contours are drawn with half width, two copies are on screen).
CHDKPTP live view is also broken, I get errors like
Code: [Select]
gui_live.lua:543: data < buffer_width*heightand a partial display with wrong overlay colors (mis-interpreted data stream?).
« Last Edit: 05 / May / 2019, 16:26:54 by srsa_4c »
Logged
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: G5X Porting.
« Reply #15 on: 05 / May / 2019, 18:34:10 »
Quote from: srsa_4c on 05 / May / 2019, 14:23:47
Quote from: philmoz on 05 / May / 2019, 07:42:51
If you are able to check out the g5x branch and build
First hurdle
Code: [Select]
../../core/autoiso.c: In function 'live_histogram_read_y':
../../core/autoiso.c:60:9: error: 'for' loop initial declarations are only allowed in C99 or C11 mode
         for (int y=0; y<vp_height; y+=1, img+=vp_offset)
         ^
../../core/autoiso.c:60:9: note: use option -std=c99, -std=gnu99, -std=c11 or -std=gnu11 to compile your codehow come you don't get this error? There don't seem to be any -std switches in any makefiles. I've been avoiding the newer syntax for this exact reason.

edit:
Compilation succeeds if I add -std=gnu99 to CFLAGS, c99 mode doesn't like 'asm'.

edit2:
Testing on sx280.
CHDK menu and display works, RBF fonts work also.
Zebra works, and it seems the screen is erased now. As a result, it now blinks in an irritating manner (due to slow redraw and erasure).
Edge overlay is more broken than before (contours are drawn with half width, two copies are on screen).
CHDKPTP live view is also broken, I get errors like
Code: [Select]
gui_live.lua:543: data < buffer_width*heightand a partial display with wrong overlay colors (mis-interpreted data stream?).


Thanks for testing.


I've checked in changes to fix the autoiso.c build (I'm using GCC5, should now work on 4).
Also (hopefully) fixed the live view issue.


Not sure about zebra and edge overlay, will look at these more closely tonight.


Phil.
Logged
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

  • ******
  • 14114
Re: G5X Porting.
« Reply #16 on: 05 / May / 2019, 19:00:30 »
Quote from: philmoz on 05 / May / 2019, 07:42:51
I ended up using the YUV bitmap display like the other D6 cameras; but went a slightly different path from what is currently checked in (hence the changes in core and modules).
I'm a bit confused. It sounds like you were ultimately able to find buffers that are equivalent to existing d6 ports. Are other changes (like the BITMAP_YUV2 stuff) required due to something unique to G5X?

If not, it would seem preferable to just make this port work like the others, at least initially.

If you've found better ways to do things that can be applied to all D6 ports, that's great, but IMO it should be a separate project, and it should be applied to all of them.
Logged
Don't forget what the H stands for.
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: G5X Porting.
« Reply #17 on: 05 / May / 2019, 19:19:00 »
Quote from: reyalp on 05 / May / 2019, 19:00:30
Quote from: philmoz on 05 / May / 2019, 07:42:51
I ended up using the YUV bitmap display like the other D6 cameras; but went a slightly different path from what is currently checked in (hence the changes in core and modules).
I'm a bit confused. It sounds like you were ultimately able to find buffers that are equivalent to existing d6 ports. Are other changes (like the BITMAP_YUV2 stuff) required due to something unique to G5X?

If not, it would seem preferable to just make this port work like the others, at least initially.

If you've found better ways to do things that can be applied to all D6 ports, that's great, but IMO it should be a separate project, and it should be applied to all of them.


Yes I was able to (eventually) figure out how to use the YUV bitmaps like the other D6 ports.
The main difference is I don't have to use the 14x32 font system because the bitmap is 720x480 so there are enough characters to display the CHDK menu.
This avoids all the complication and allows the display code to work like older cameras (pretending to be a 360x240 display).


This could be used for any D6 camera with a 720x480 YUV bitmap; but I don't have any way to test these easily.
Adding the BITMAP_YUV2 flag lets me get the G5X into the system without (hopefully) breaking existing stuff.
In theory setting this flag in 'makefile.inc' for other D6 cameras should work.


If there's a better way to handle this I'm happy to discuss it - I thought a separate branch for now would be simpler to manage.


Phil.
Logged
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

  • ******
  • 14114
Re: G5X Porting.
« Reply #18 on: 05 / May / 2019, 23:10:39 »
I briefly tried elph180, g7x and sx710 built from the branch r5182.

On the digic 6 cams, I see the same horizontally doubled edge overlay srsa_4c mentioned, didn't notice anything else wrong in a quick look.

Quote from: philmoz on 05 / May / 2019, 19:19:00
The main difference is I don't have to use the 14x32 font system because the bitmap is 720x480 so there are enough characters to display the CHDK menu.
G7X and the EOS M cameras have a 720x480 displays, and work fine (or at least acceptably well) with the existing code. It may be complicated and ugly, but the code is already there.

If G5X has the same underlying display, I really don't understand what benefit would outweigh the ongoing maintenance impact of adding yet another display system.
Quote
This avoids all the complication and allows the display code to work like older cameras (pretending to be a 360x240 display).
Given that the other code already exists and has to be maintained for the 640x480 D6 cams, what is the practical benefit? I guess grids and some games would be at the right scale (+/- aspect ratio), but it seems like that could be addressed in much lower impact ways.

I appreciate that you've put a lot of work into this, but my gut reaction is really strongly against having one port do things in a wildly different way without a significant underlying difference in the camera.
Quote
If there's a better way to handle this I'm happy to discuss it - I thought a separate branch for now would be simpler to manage.
Having a separate branch to test is totally reasonable, no objection to that.
Logged
Don't forget what the H stands for.
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: G5X Porting.
« Reply #19 on: 06 / May / 2019, 00:31:05 »
Quote from: reyalp on 05 / May / 2019, 23:10:39
I briefly tried elph180, g7x and sx710 built from the branch r5182.

On the digic 6 cams, I see the same horizontally doubled edge overlay srsa_4c mentioned, didn't notice anything else wrong in a quick look.

Quote from: philmoz on 05 / May / 2019, 19:19:00
The main difference is I don't have to use the 14x32 font system because the bitmap is 720x480 so there are enough characters to display the CHDK menu.
G7X and the EOS M cameras have a 720x480 displays, and work fine (or at least acceptably well) with the existing code. It may be complicated and ugly, but the code is already there.

If G5X has the same underlying display, I really don't understand what benefit would outweigh the ongoing maintenance impact of adding yet another display system.
Quote
This avoids all the complication and allows the display code to work like older cameras (pretending to be a 360x240 display).
Given that the other code already exists and has to be maintained for the 640x480 D6 cams, what is the practical benefit? I guess grids and some games would be at the right scale (+/- aspect ratio), but it seems like that could be addressed in much lower impact ways.

I appreciate that you've put a lot of work into this, but my gut reaction is really strongly against having one port do things in a wildly different way without a significant underlying difference in the camera.
Quote
If there's a better way to handle this I'm happy to discuss it - I thought a separate branch for now would be simpler to manage.
Having a separate branch to test is totally reasonable, no objection to that.


It's a work in progress and I don't think it will end up as complex as it currently seems.
There are currently 7 D6 cameras with 640x480 bitmaps and 5 with 720x480 - if I include the G7X2 :)

I expect most new cameras will have the higher res display so the balance may shift.
Providing a method for the higher res cameras to work more efficiently seems worth the effort to me - we'll see how it pans out.

EDIT: After more consideration I believe reyalp is right and keeping things consistent is better. It also means less testing for me which is a plus :)
I will check in the G5X port using the existing YUV bitmap system soon - just want to double check the finsig changes don't affect anything.

Ignore the G5X branch in SVN, I will archive it later.
« Last Edit: 06 / May / 2019, 08:11:05 by philmoz »
Logged
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)
Pages: 1 [2] 3 4 5 6 7 ... 10   Go Up
« previous next »
 

Related Topics
SimplePortal 2.3.6 © 2008-2014, SimplePortal