Display (bitmap overlay)

  • 110 Replies
  • 13521 Views
*

Offline reyalp

  • ******
  • 10668
  • Publish
    Re: New screen refresh method on DIGIC 6
    « Reply #90 on: 16 / July / 2017, 18:29:39 »
    Advertisements
    I think I found it.
    Attached patch replaces the old DisplayBusyOnScreen-based vid_bitmap_refresh() on the sx280. It works by copying the "source" RGBA overlay over the active overlay buffers. The fw function I found sends out the GraphicSystemCoreFinish, JediFinish, XimrExe messages, and it only takes a single argument.
    Nice job :D

    On g7x, this works, and resolves the key press issue I mentioned earlier.

    I noticed in Auto mode (where the canon firmware updates the focus box all the time) leaving alt mode with the CHDK menu open sometimes results in a flashing copy of the menu. Similarly, sometimes the <alt> indicator will flash for a long time after leaving alt mode.

    I don't see this with the displaybusy code. Both flash while the menu is open, but only the new function shows a stale copy of the menu flashing after leaving alt. It looks like the focus box updates swap buffers without clearing the rest of the screen.

    Doing something something that updates more of the Canon UI (like pressing SET) makes it go away.
    Don't forget what the H stands for.

    *

    Offline reyalp

    • ******
    • 10668
  • Publish
    Re: Display (bitmap overlay)
    « Reply #91 on: 17 / July / 2017, 00:29:16 »
    I spent some time unsuccessfully trying to draw directly with Zico

    The various Zico messages (https://chdk.setepontos.com/index.php?topic=11316.80) have wrappers call mzrm_createmsg, package up the parameters, and call mzrm_sendmsg.

    A bunch of these call seemingly simple drawing functions (GrypDrawDot, GrypDrawHLine) which I hoped to call directly. However, I wasn't able to get GrypDrawHLine to do anything with various guessed arguments and sequences of Flush/Finish calls, in a loop of 50 calls with a 10ms sleep. Little surprise this didn't work since I couldn't find examples in the firmware of a correct sequence.
    Don't forget what the H stands for.

  • Publish
    Re: Display (bitmap overlay)
    « Reply #92 on: 17 / July / 2017, 23:38:29 »
    works on SX60HS.  Nice!   :D
    It would be interesting to catalog messages for various video modes (and other modes as well), just to see if we can make sense of the arguments and syntax. I'm assuming I can find your message logging code somewhere up this thread?

    Will this function be in the sigfinder soon?  I already modified my stubs_entry_2.S for each firmware, but it'll probably be redundant.

    *

    Offline reyalp

    • ******
    • 10668
  • Publish
    Re: Display (bitmap overlay)
    « Reply #93 on: 18 / July / 2017, 01:21:07 »
    Will this function be in the sigfinder soon?
    I'm working on it.

    I'm curious if anyone else sees what I'm seeing on g7x, with the menu flashing after leaving alt mode.
    Don't forget what the H stands for.


    *

    Offline Ant

    • ****
    • 283
  • Publish
    Re: Display (bitmap overlay)
    « Reply #94 on: 18 / July / 2017, 02:23:33 »
    I'm curious if anyone else sees what I'm seeing on g7x, with the menu flashing after leaving alt mode.
    On M3 it's ok excepting movie mode(when AF is on) and canon's histogram.

  • Publish
    Re: Display (bitmap overlay)
    « Reply #95 on: 18 / July / 2017, 10:03:53 »
    Quote
    I'm curious if anyone else sees what I'm seeing on g7x, with the menu flashing after leaving alt mode.
    I tried a few times an SX60 to reproduce this in Auto mode (shoot) with ALT and menu.  The screen is flickering quite a bit, but leaving Alt mode seems to just behave normally.  No ghosts. 

    *

    Offline srsa_4c

    • ******
    • 3435
  • Publish
    Re: New screen refresh method on DIGIC 6
    « Reply #96 on: 18 / July / 2017, 12:20:20 »
    It looks like the firmware only updates parts of this overlay that actually change.
    But your voltmeter script (that uses _LCDMsg_SetStr) causes flickering of all CHDK OSD elements and menu.
    I filled a part of the RGBA overlay(s) using memset. The Canon OSD did not erase parts that fell outside the playback mode overlay, while browsing images. It only got overwritten when I entered the Canon menu.
    I noticed in Auto mode (where the canon firmware updates the focus box all the time) leaving alt mode with the CHDK menu open sometimes results in a flashing copy of the menu. Similarly, sometimes the <alt> indicator will flash for a long time after leaving alt mode.
    I managed to reproduce something similar on the M10. "Scene intelligent auto" and "hybrid auto" modes seem to be affected, but it's not easy to reproduce.
    What's likely happening (IMHO) is that we are refreshing the wrong buffer (because the firmware happens to flip them while we're trying).
    I could think of 2 possible workarounds:
    1) try using a different active_bitmap_buffer (for example, the M10 has another very similarly acting fw variable at offset +4)
    2) refresh both buffers
    I tried 2) on M10 and now I don't seem to get visible glitches.

    The sx280 seems to act differently, the only problem I encountered (once) so far was when I exited ALT while the Canon menu was active: upon exiting the Canon menu, the CHDK menu appeared on the fading remains of the Canon one.

    Quote
    A bunch of these call seemingly simple drawing functions (GrypDrawDot, GrypDrawHLine) which I hoped to call directly. However, I wasn't able to get GrypDrawHLine to do anything with various guessed arguments and sequences of Flush/Finish calls, in a loop of 50 calls with a 10ms sleep. Little surprise this didn't work since I couldn't find examples in the firmware of a correct sequence.
    Yeah, that's hard. On the sx280, a very large part of these functions is unreferenced, a small subset is actually used. I also managed to crash Zico by sending two XimrExe messages in a row (the second one caused the crash).

    Since D6 DSLRs use the same Xtensa firmware (I found a 750d dump somewhere), it might be possible to get some more information from their fw.
    I'm assuming I can find your message logging code somewhere up this thread?
    Not yet, just the hint (the point where it can be hacked). You also might need to find and disassemble the Xtensa blob(s) to get the message list.

    edit:
    I attached the research-hack I used on the sx280. Almost every bit of it will need to be adapted if somebody would like to use it on another camera.
    « Last Edit: 18 / July / 2017, 14:47:39 by srsa_4c »

  • Publish
    Re: Display (bitmap overlay)
    « Reply #97 on: 18 / July / 2017, 19:50:56 »
    Quote
    I'm curious if anyone else sees what I'm seeing on g7x, with the menu flashing after leaving alt mode.
    I tried a few times an SX60 to reproduce this in Auto mode (shoot) with ALT and menu.  The screen is flickering quite a bit, but leaving Alt mode seems to just behave normally.  No ghosts.
    Ditto for the G16.

    Tried various video and shooting modes - with Set/Func and Menu screens selected as I went in & out of <ALT> or <ALT>+CHDK menu.  Nothing unusual or ghosted images.

    But maybe I'm not looking for the right thing?
    Ported : A1200  SD940  G10  Powershot N  G16*


    *

    Offline reyalp

    • ******
    • 10668
  • Publish
    Re: Display (bitmap overlay)
    « Reply #98 on: 20 / July / 2017, 00:07:15 »
    But maybe I'm not looking for the right thing?
    On G7 X, it happens if I
    1) Have the camera is in auto mode, where the AF frame (often) continuously wanders around the screen
    2) Enter alt and the CHDK menu
    3) Leave alt

    The ghost of the CHDK menu then sometimes flash until the canon firmware updates something other than the AF frame.

    Strangely, this doesn't happen with face tracking continuous AF in P mode, but it's a bit intermittent in the auto case too, so maybe I just didn't manage to reproduce it.

    I believe the AF frame is drawn directly on the YUV bitmap rather than the RGB buffer. I suspect this may explain why other Canon UI elements updating make the problem go away.
    Don't forget what the H stands for.

    *

    Offline srsa_4c

    • ******
    • 3435
  • Publish
    Re: Display (bitmap overlay)
    « Reply #99 on: 20 / July / 2017, 11:39:49 »
    I believe the AF frame is drawn directly on the YUV bitmap rather than the RGB buffer.
    Yes and no. Explained below.

    Looks like I was wrong about that double RGBA buffer. I have made several dumps of it (on the M10), and it definitely does not look like the overlay buffers (yuv, opacity) that are actually displayed.
    A typical dump is attached.
    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.

    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);

     

    Related Topics