Display (bitmap overlay) - page 11 - General Discussion and Assistance - CHDK Forum supplierdeeply
« previous next »
Pages: 1 ... 6 7 8 9 10 [11] 12 13 14 15 16 ... 41   Go Down

Display (bitmap overlay)

  • 403 Replies
  • 125341 Views
*

Offline Ant

  • *****
  • 509
Re: Display (bitmap overlay)
« Reply #100 on: 20 / July / 2017, 13:14:51 »
Advertisements
Quote from: srsa_4c on 20 / July / 2017, 11:39:49
The main OSD content is in the upper buffer, in all dumps I have seen.
Overlaid items (here, the AF frame) are in the second buffer, with no other content. I don't know whether this topology is fixed, or it can change.
On M3 items are in the same buffer:





Quote
As for screen refresh, following seems to work for me. No active_bitmap_buffer is involved.
Code: [Select]
    _transfer_src_overlay(0);
    _transfer_src_overlay(1);
This works on M3 in auto modes: no CHDK ghosts but CHDK OSD still flikering...
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: Display (bitmap overlay)
« Reply #101 on: 20 / July / 2017, 14:15:18 »
Quote from: Ant on 20 / July / 2017, 13:14:51
On M3 items are in the same buffer
That's one of the YUV overlay buffers and an opacity buffer below. I was talking about the source overlay buffers which have RGBA pixel format (32 bit per pixel) and fixed dimensions: 960x480. There's two of them, hence my 960x960 image.
Quote
This works on M3 in auto modes: no CHDK ghosts but CHDK OSD still flikering...
Since we're still drawing to a buffer that's continuously getting overwritten, flickering is absolutely no surprise.
Logged
*

Offline Ant

  • *****
  • 509
Re: Display (bitmap overlay)
« Reply #102 on: 20 / July / 2017, 15:25:32 »
Quote from: srsa_4c on 20 / July / 2017, 14:15:18
I was talking about the source overlay buffers which have RGBA pixel format (32 bit per pixel) and fixed dimensions: 960x480

Understood.
It's interesting that LCDRect_Create draws at the same buffer as AF frame.
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: Display (bitmap overlay)
« Reply #103 on: 21 / July / 2017, 11:17:15 »
Additional idea (did not try it).

If it is really Ximrexe that does the framebuffer copy AND the camera survives if it is not sent, we could block the message in ALT mode and enjoy flickerless drawing...
Sounds too good to be true?

Another use: when this message is detected, there's a high probability that something needs to be redrawn.

Drawback: intercepting this message requires a permanent TakeSemaphore patch that causes a (tiny) performance drop.
Logged
*

Offline Ant

  • *****
  • 509
Re: Display (bitmap overlay)
« Reply #104 on: 21 / July / 2017, 11:54:41 »
Quote from: srsa_4c on 21 / July / 2017, 11:17:15
Drawback: intercepting this message requires a permanent TakeSemaphore patch that causes a (tiny) performance drop.
mzrm_createmsg and mzrm_sendmsg functions are using pointers to debug functions(see at 0xFC2FD870 on M3) that actually are NULL. Maybe we can use it?
« Last Edit: 21 / July / 2017, 12:03:56 by Ant »
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: Display (bitmap overlay)
« Reply #105 on: 22 / July / 2017, 08:27:08 »
Quote from: Ant on 21 / July / 2017, 11:54:41
mzrm_createmsg and mzrm_sendmsg functions are using pointers to debug functions(see at 0xFC2FD870 on M3) that actually are NULL. Maybe we can use it?
They are too deep down and too conditional.
TakeSemaphore is right at start. It lets us skip the whole mzrm_createmsg if we chose to do so. The mzrm message functions usually check the return value of mzrm_createmsg for NULL and skip sending the message if it is indeed NULL (well, not much else could they do).

I did this on the sx280 102b:
Code: [Select]
Index: boot.c
===================================================================
--- boot.c (revision 4883)
+++ boot.c (working copy)
@@ -74,6 +74,16 @@
         "cmp    r0,r2\n"
         "blo    task_hook_loop\n"
 
+        "adr     r0, patch_TakeSemaphore\n"    // src: Patch data
+        "ldr     r1, =0x010c59f8\n"    // dest: Address to patch (hook_ has thumb bit off)
+        "add     r2, r0, #8\n" // two words
+"ts_hook_loop:\n"
+        "ldrh   r3, [r0],#2\n"
+        "strh   r3, [r1],#2\n"
+        "cmp    r0,r2\n"
+        "blo    ts_hook_loop\n"
+
+
 "    ldr     r0, =0x010c1000\n"
 "    ldr     r1, =0x0001f3c4\n"
 "    BL      sub_fc12dd3a\n" // clean data cache (on the kernel area)
@@ -99,6 +109,10 @@
         "patch_CreateTask:\n"
         "ldr.w   pc, [pc,#0]\n"             // Do jump to absolute address CreateTask_my
         ".long   CreateTask_my + 1\n"           // has to be a thumb address
+
+        "patch_TakeSemaphore:\n"
+        "ldr.w   pc, [pc,#0]\n"             // Do jump to absolute address
+        ".long   TakeSemaphore_my + 1\n"           // has to be a thumb address
 );
 }
 
@@ -590,3 +604,44 @@
 }
 
 
+//*****************************************************************
+
+void __attribute__((naked,noinline)) TakeSemaphore_my() {
+asm volatile (
+    "ldr       r3, =0xfc2546a7\n"
+    "cmp       r3, lr\n"
+    "bne       nomod\n"
+"mod1:\n"
+    "push      {r0,lr}\n"
+    "mov       r0, r11\n" // r2 of mzrm_create
+    "cmp       r0, #0x1d\n" // ximrexe, @ FC2DC5D6
+    "bne       mod1out\n" // only touch ximrexe
+    "bl        mzrmmod1\n"
+    "pop       {r0,lr}\n"
+    "mov       r0, #0\n" // make mzrm_create return null pointer
+    "ldr       pc, =0xFC254725\n" // leave mzrm_create, without doing anything
+"mod1out:\n"
+    "pop       {r0,lr}\n"
+    //"b         nomod\n"
+"nomod:\n"
+    "push      {r2, r3, r4, r5, r6, lr}\n"
+    "mov       r4, r0\n"
+    "ldr       r0, =0x8154\n"
+    "mov       r5, r1\n"
+    "ldr       pc, =0x10c5a01\n"
+".ltorg\n"
+);
+}
+
+
+static unsigned int taskinf[20];
+static int msgsize;
+
+extern int _get_self_task_id();
+extern void _get_tcb(int tid, void* buf);
+
+void mzrmmod1() {
+}
+
+The patch contains unnecessary parts and the asm isn't optimal.
This is just POC, it just suppresses all Ximrexe messages. Screenshot attached (shows both framebuffers from the same session, as you can see the previous diskboot's splash has survived the few seconds while the cam was off).

Using this, framebuffers are still flipped back and forth as usual while using the camera.
Newer cameras contain more Ximr messages (for example, g7x has XimrExeGain, no idea what it does).
I only tried this on the sx280.
Logged
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Display (bitmap overlay)
« Reply #106 on: 22 / July / 2017, 19:41:44 »
Thanks for that - works on G5X  :D


That was the magic function I could not find - might be able to make some progress now (time permitting).


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

  • ******
  • 14082
Re: Display (bitmap overlay)
« Reply #107 on: 22 / July / 2017, 21:23:58 »
Quote from: reyalp on 18 / July / 2017, 01:21:07
Quote from: 62ndidiot on 17 / July / 2017, 23:38:29
Will this function be in the sigfinder soon?
I'm working on it.
I added a match for transfer_src_overlay, it finds the same values srsa_4c listed earlier.

I also added a match for active_bitmap_buffer. The match is the value the canon firmware passes to transfer_src_overlay, which is 4 bytes off from the the value we used on most ports before. Based on testing with chdkptp live view, it appears work correctly on g7x, and (almost always?) contains the same value as the old variable.

Using the new active_bitmap_buffer value did not affect the ghosting in after leaving alt in auto mode. However transfer_src_overlay the function with 0 and 1 does. I'm going to check this code in for g7x, as it seems substantially better than the displaybusy code.
Logged
Don't forget what the H stands for.
*

Offline reyalp

  • ******
  • 14082
Re: Display (bitmap overlay)
« Reply #108 on: 23 / July / 2017, 16:58:19 »
I updated finsig_thumb2 to identify mzrm_createmsg and mzrm_sendmsg (along GraphicSystemCoreFinish which is used to find them)
Logged
Don't forget what the H stands for.
*

Offline zweistein68

  • *
  • 29
Re: Display (bitmap overlay)
« Reply #109 on: 24 / July / 2017, 05:32:27 »
Does this work for M10 110d and 110f and if so what are the addresses for 'transfer_src_overlay' ?
Logged
Pages: 1 ... 6 7 8 9 10 [11] 12 13 14 15 16 ... 41   Go Up
« previous next »
 

Related Topics