Display (bitmap overlay) - page 22 - General Discussion and Assistance - CHDK Forum  
« previous next »
Pages: 1 ... 17 18 19 20 21 [22] 23 24 25 26 27 ... 41   Go Down

Display (bitmap overlay)

  • 403 Replies
  • 123914 Views
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Display (bitmap overlay)
« Reply #210 on: 03 / May / 2021, 07:39:53 »
Advertisements
In case anyone is interested here is a patch of my current progress on using an RGBA Ximr layer for the CHDK UI.


I have implemented this for the G5X and G7X2 in this patch.
From what i have tested so far it works well - rock steady CHDK UI with no flickering.


I create a 360x240 (or 480x270 for HDMI) buffer inserted into the Canon display pipeline via the dry_memcpy patch.
This is then scaled 2x in both directions when rendered.


At the moment the CAM_DRAW_RGBA setting has to be in the makefile for the camera in order to build correctly - I'm not sure how to fix this at the moment.


I'm sure much of this could be done better so feedback is welcome.


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 pigeonhill

  • *****
  • 1155
Re: Display (bitmap overlay)
« Reply #211 on: 03 / May / 2021, 07:47:54 »
@philmoz

Looking forward to testing this on the M3.
Logged
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Display (bitmap overlay)
« Reply #212 on: 03 / May / 2021, 08:01:12 »
@pigeonhill


Here is a test build for M3 1.20f.


Note this is very experimental. It may not work, it may crash or cause issues in areas I have not fully tested.


One change you will need to make for your script is the display size - the current code draws to a 720x480 display.
In this version the CHDK UI buffer is 360x240 pixels so you will need to adjust any drawing you do to the screen.


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 pigeonhill

  • *****
  • 1155
Re: Display (bitmap overlay)
« Reply #213 on: 03 / May / 2021, 08:09:42 »
@philmoz

Phil

Transformational!!!!!!!  :)

The overlays are rock solid and 100% compatible with the Canon GUI, ie as I cycle through, including the Canon histogram.

I won't try and tweak my code yet, as I'm sure you will be refining things.

As soon as you think you have a stable configuration, I'll tweak my Bracketing script to match the new screen sizes.

Fantastic work and thanks for your efforts: and my M3 builds  ;)

Cheers

Garry
« Last Edit: 03 / May / 2021, 08:40:01 by pigeonhill »
Logged
*

Offline Ant

  • *****
  • 509
Re: Display (bitmap overlay)
« Reply #214 on: 03 / May / 2021, 09:03:38 »
Quote from: philmoz on 03 / May / 2021, 07:39:53
In case anyone is interested here is a patch of my current progress on using an RGBA Ximr layer for the CHDK UI.

Why don't you use own YUV+Opacity buffers(as Ximr input layer) for drawing CHDK UI?

I also suggest not to patch dry_memcpy or TakeSemaphore. I think these functions are being called more intensively.
It's better to hook disabled debug messages inside mzrm_sendmsg function:
Code: [Select]
void __attribute__((naked,noinline)) MZRM_hook() {
 asm volatile (
"ldr     r0, =0xfc2fd873\n"
"cmp     r0,lr\n"
"bne     mh_exit\n"

"push {lr}\n"
"mov r1, r11\n" // MZRM message
"bl mylogfunc2\n"
"pop  {pc}\n"

"mh_exit:\n"
"bx lr\n"
".ltorg\n"
);
}
EOS M3 v1.01a

But this require parsing the MZRM messages.
« Last Edit: 03 / May / 2021, 12:16:36 by Ant »
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: Display (bitmap overlay)
« Reply #215 on: 03 / May / 2021, 12:36:51 »
Quote from: Ant on 03 / May / 2021, 09:03:38
Why don't you use own YUV+Opacity buffers(as Ximr input layer) for drawing CHDK UI?
I would consider using the area where the firmware's yuv layer is drawn. By hooking the ximrexe call that creates it, we could reconfigure the yuv layer to be half height or width (and later double its height (or width) when it is used as input layer). The remaining space in that area is more than enough for a 720x240 RGBA buffer for CHDK - we wouldn't have to allocate any memory.
I found more than one byte in the layer struct where certain bits cause the layer to be rendered with double width and/or height. I don't know what this effect actually is, it's not a smooth bilinear operation, it just doubles pixels.
Logged
*

Offline Ant

  • *****
  • 509
Re: Display (bitmap overlay)
« Reply #216 on: 03 / May / 2021, 12:54:15 »
Quote from: srsa_4c on 03 / May / 2021, 12:36:51
By hooking the ximrexe call that creates it, we could reconfigure the yuv layer to be half height or width
This will decrease the quality of Canon graphics

Quote
we wouldn't have to allocate any memory.
Is this a big problem to allocate a couple of megabytes from hundreds?

Currently I'm experimenting with my own YUV buffer created using exmem_ualloc. I use it as third layer to draw CHDK UI over Canon GUI.
Logged
*

Offline reyalp

  • ******
  • 14080
Re: Display (bitmap overlay)
« Reply #217 on: 03 / May / 2021, 15:25:33 »
Quote from: Ant on 03 / May / 2021, 12:54:15
Is this a big problem to allocate a couple of megabytes from hundreds?
It's virtually certain there's megabytes to spare *somewhere*, but that's not the same as knowing where they are or being able to allocate them without impacting the original firmware. For example, we've observed on earlier cams that using exmem can impact the maximum jpeg quality, as well as the conflicts with video buffers.

Quote
I also suggest not to patch dry_memcpy or TakeSemaphore. I think these functions are being called more intensively.
This would be my initial gut reaction too, but the hook is essentially just comparing LR with a constant and jumping back to the firmware if it doesn't match, which is negligible compared to the rest of the function.

Phil's version does slightly more, but could be optimized for the non-matching case. R12 and R3 are free to use. (edit: To be clear, I'm not against using the log function instead, I generally favor using the approach with lowest impact to other parts of the firmware. I just wouldn't worry much about hooking dry_memcpy)
« Last Edit: 03 / May / 2021, 15:57:58 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Display (bitmap overlay)
« Reply #218 on: 04 / May / 2021, 04:15:55 »
Thanks @Ant - i was able to figure out patching the mzrm_sendmsg logging call and access the Ximr context data.
I am still able to then add the new layer in the Ximr context so no need to parse MZRM stuff.


This is more efficient (called less often), especially in record mode.


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 Ant

  • *****
  • 509
Re: Display (bitmap overlay)
« Reply #219 on: 04 / May / 2021, 04:55:14 »
Quote from: philmoz on 04 / May / 2021, 04:15:55
so no need to parse MZRM stuff.

By parsing, I meant checking the message type number(the 1st word) and taking the address of the XIMR context (the 4th word). This can be done using assembler.
XIMR context in XimrExeGain message also can be modified.

How do you clear the CHDK layer when you enter canon menu?

P.S. Original canon buffers are aligned to 0x1000.
« Last Edit: 04 / May / 2021, 07:15:41 by Ant »
Logged
Pages: 1 ... 17 18 19 20 21 [22] 23 24 25 26 27 ... 41   Go Up
« previous next »
 

Related Topics