Coding Alignment of Focus Peak/Zebras on HDMI ouput

[dpjpandone]

Hey guys, can someone point me toward the line(s) in the source where the position of overlays (pertaining to HDMI output) is coded? I want to work on getting proper alignment of focus peaking and zebras on an external monitor

[names_are_hard]

Probably somewhere in src/zebra.c.  How overlays are drawn depends on a few factors I think, including which cam.  Some overlays are done by ML in software, some are done by triggering Canon code.

[dpjpandone]

The funny thing is I realized last night that these should not be drawn at all when hdmi is attached. I discovered this when I tried to enable them with the hdmi monitor connected, and they did not draw. Turns out the only way they show up on external display is if you enable them first the connect the display. So I guess I found a bug.... I supposed the intended behavior is they should be disabled when hdmi is connected, but this doesn't happen until you cycle ML menu. So I guess I have a different question now:

Why are display filters not drawn on hdmi output? It seems the zebras are properly working and aligned. Focus peaking is misaligned, Is it too much overhead? Were they disable because no one wanted to sort out the alignment issue? Does the peaking code need to be revised to adapt to the different resolution of external monitor? Anyone who has some knowledge about this please share.

[names_are_hard]

Now it's sounding more like a proper list of requirements   I don't know what the intended behaviour should be.  Would most people like their LCD overlays to transfer to HDMI if they switch to that?  Or do people want HDMI monitor to be clean by default, so they shouldn't transfer unless explicitly configured?

I don't know why display filters aren't drawn in your scenario.  You will probably have to do what I do when I'm working on a feature; read a lot of forum posts and code, and try to work it out.  Determining intent is very hard, there are rarely good comments in the code.

[kitor]

GUI on HDMI output works differently, it doesn't cover the whole output.
IIRC in the past different models handled HDMI differently, and there are multiple possible HDMI resolutions. HDMI liveview (image) resolution is not tied to GUI resolution directly.

I assume this is a limitation of Magic Lantern source code that assumes all cameras have the same display resolution, which is not true.
Funny is that except LiveView, Canon does the same assumption (example: SX740 that scales gui horizontally to fill the lcd)

[names_are_hard]

Definitely the code tries to pick a small number of output sizes to simplify things.  It's not quite true that we assume all cams have the same resolution, HDMI being bigger is sometimes managed via BMP_H_MINUS and related constants, and bmp.h defines these differently for VxWorks cams (digic 3 and earlier?) compared to everything else.  E.g.:

Code: [Select]

#define BMP_HDMI_OFFSET ((-BMP_H_MINUS)*BMPPITCH + (-BMP_W_MINUS))

In theory I guess you could define those constants per cam, or per digic gen, but it's not a simple change and testing it may be hard (does qemu emulate HDMI out resolution?).

[dpjpandone]

Definitely the code tries to pick a small number of output sizes to simplify things.  It's not quite true that we assume all cams have the same resolution, HDMI being bigger is sometimes managed via BMP_H_MINUS and related constants, and bmp.h defines these differently for VxWorks cams (digic 3 and earlier?) compared to everything else.  E.g.:

Code: [Select]

#define BMP_HDMI_OFFSET ((-BMP_H_MINUS)*BMPPITCH + (-BMP_W_MINUS))

In theory I guess you could define those constants per cam, or per digic gen, but it's not a simple change and testing it may be hard (does qemu emulate HDMI out resolution?).

Code: [Select]

#define BMP_W_PLUS 840
#define BMP_W_MINUS -120
#define BMP_H_PLUS 510
#define BMP_H_MINUS -30

#define BMPPITCH 960
#define BMP_VRAM_SIZE (960*540)

#define BMP_HDMI_OFFSET ((-BMP_H_MINUS)*BMPPITCH + (-BMP_W_MINUS))

Is this correct!?  H minus and W minus are already negative integers, this = 28,290 ?wtf?

[names_are_hard]

840 + 120 = 960, 510 + 30 = 540.  Total display size is 960*540, but this is not all used, depending on display mode.  Stepping back 28,290 pixels moves you back close to 30 rows (960 * 30 = 28,800).

[dpjpandone]

Is this:

Code: [Select]

if (lv_dispsize != 1) return;
the line that prevents magic zoom from drawing on HDMI ?

Code: [Select]

Draw Magic Zoom overlay
 */
static void draw_zoom_overlay(int dirty)
{   
    if (zoom_overlay_size == 3) return; // fullscreen zoom done via digic
   
    //~ if (vram_width > 720) return;
    if (!lv) return;
    if (!get_global_draw()) return;
    //~ if (gui_menu_shown()) return;
    if (!bmp_is_on()) return;
    if (lv_dispsize != 1) return;
    //~ if (get_halfshutter_pressed() && clearscreen != 2) return;
    if (RECORDING_H264_STARTING) return;

[names_are_hard]

Looks plausible, try it and see.

[dpjpandone]

nope. Theres about a million conditions that are not allowing filters on hdmi......ughhhh

[names_are_hard]

Sounds about normal.  You might be able to work out some idea of the intent by what conditions you're failing.  You may be able to log which conditions via qemu, but I'm not sure how it will handle HDMI stuff.  If not you could log to card on a physical cam (or use uart if you have that).

[dpjpandone]

Ok, maybe this will help. zebras are properly aligned. false color and peaking are not. why? Is zebra already canon/digic display filter and not ML code like the ones that are misaligned?

[names_are_hard]

I don't know, I haven't looked at this code and I don't have the same cam as you.  Is it possible to repro the issue in qemu?  If so I could look at it.

Some cams can optionally display zebras via Canon code.  Is yours doing that with whatever build you have?  I don't know.

[dpjpandone]

I have actually never used QEMU

I've always tested everything in camera.

It seems a lot of the guides are outdated. What is the best tutorial/thread to follow for setting up QEMU on a windows machine in 2022?

[names_are_hard]

It's well worth learning how to use Qemu, especially for risky changes (e.g. memory subsystem, boot code, properties).  It can't do everything phys cam can, but at least you can gain some confidence in advance.

I don't know how to do setup on Windows.  I also don't use qemu 2 anymore, but my qemu 4 port.  It will probably build easily in WSL, use Debian if you want to be closest to what I use (I use Debian Bullseye, but I'd expect Debian Testing to work).  I believe getting qemu GUI working is a little annoying with WSL, you need some extra thing to get X Windows support, something like that.  You can give that a go if you want: https://github.com/reticulatedpines/qemu-eos/tree/qemu-eos-v4.2.1/magiclantern

Be aware that all the existing guides will be weird and mildly confusing, since I'm rewriting the tooling around qemu, too, as I improve qemu 4 support.  So you might not want to choose this option.  It is maintained though and I will respond to bug reports etc.

[dpjpandone]

It's well worth learning how to use Qemu, especially for risky changes (e.g. memory subsystem, boot code, properties).  It can't do everything phys cam can, but at least you can gain some confidence in advance.

I don't know how to do setup on Windows.  I also don't use qemu 2 anymore, but my qemu 4 port.  It will probably build easily in WSL, use Debian if you want to be closest to what I use (I use Debian Bullseye, but I'd expect Debian Testing to work).  I believe getting qemu GUI working is a little annoying with WSL, you need some extra thing to get X Windows support, something like that.  You can give that a go if you want: https://github.com/reticulatedpines/qemu-eos/tree/qemu-eos-v4.2.1/magiclantern

Be aware that all the existing guides will be weird and mildly confusing, since I'm rewriting the tooling around qemu, too, as I improve qemu 4 support.  So you might not want to choose this option.  It is maintained though and I will respond to bug reports etc.

Code: [Select]

dpjpandone@MSI:/mnt/d/DEVELOPMENT/QEMU$ git clone https://github.com/reticulatedpines/magiclantern_simplified
Cloning into 'magiclantern_simplified'...
remote: Enumerating objects: 95443, done.
remote: Counting objects: 100% (6429/6429), done.
remote: Compressing objects: 100% (1565/1565), done.
remote: Total 95443 (delta 4922), reused 6236 (delta 4846), pack-reused 89014
Receiving objects: 100% (95443/95443), 247.70 MiB | 3.01 MiB/s, done.
Resolving deltas: 100% (71237/71237), done.
Updating files: 100% (2326/2326), done.
dpjpandone@MSI:/mnt/d/DEVELOPMENT/QEMU$ git clone https://github.com/reticulatedpines/qemu-eos
Cloning into 'qemu-eos'...
remote: Enumerating objects: 581415, done.
remote: Counting objects: 100% (373/373), done.
remote: Compressing objects: 100% (169/169), done.
remote: Total 581415 (delta 189), reused 324 (delta 170), pack-reused 581042
Receiving objects: 100% (581415/581415), 337.27 MiB | 2.84 MiB/s, done.
Resolving deltas: 100% (473044/473044), done.
Updating files: 100% (8706/8706), done.
dpjpandone@MSI:/mnt/d/DEVELOPMENT/QEMU$ cd qemu-eos; git switch qemu-eos-v4.2.1; cd ..
Updating files: 100% (7680/7680), done.
Branch 'qemu-eos-v4.2.1' set up to track remote branch 'qemu-eos-v4.2.1' from 'origin'.
Switched to a new branch 'qemu-eos-v4.2.1'
dpjpandone@MSI:/mnt/d/DEVELOPMENT/QEMU$ mkdir qemu-eos-build
dpjpandone@MSI:/mnt/d/DEVELOPMENT/QEMU$ cd qemu-eos-build
dpjpandone@MSI:/mnt/d/DEVELOPMENT/QEMU/qemu-eos-build$ ../qemu-eos/configure --target-list=arm-softmmu --enable-plugins --disable-docs --enable-vnc --enable-gtk

ERROR: pkg-config binary 'pkg-config' not found
thats as far as I got...

[names_are_hard]

It's a fairly clear error (from qemu's configure, nothing special to do with ML).  What happens after you install pkg-config?

[dpjpandone]

that got me a little further, now I'm haviung an issue with gtk?

Code: [Select]

dpjpandone@DESKTOP-E5GJN3G:/mnt/c/QEMU/qemu-eos-build$ ../qemu-eos/configure --target-list=arm-softmmu --enable-plugins --disable-docs --enable-vnc --enable-gtk

ERROR: User requested feature gtk
       configure was not able to find it.
       Install gtk3-devel
i tried "sudo apt-get install gtk3-devel"

but it cant find it

[names_are_hard]

Try:

Code: [Select]

apt search libgtk|grep dev

It's probably libgtk-3-dev or similar.  You probably want flex and bison too.  Not required for qemu but it prefers it.

[names_are_hard]

Oh yeah and if you have libvte-X.YY-dev installed at the time you run configure, your qemu serial console will have proper scrollback and a larger screen size.