Display (bitmap overlay)

philmoz

3450

Re: Display (bitmap overlay)

« Reply #200 on: 29 / April / 2021, 02:28:24 »

Advertisements

@srsa_4c

In the current CHDK code the CHDK UI is drawn directly on the output YUV buffer so everything drawn is immediately visible.
This requires some way to notify CHDK that the screen needs to be redrawn which we have various solutions for.

If we move the CHDK UI to a new RGBA layer and insert it into the ximr context then our content won't be visible unless the firmware does a screen refresh.
So we need some way to force the firmware to update the display so our layer gets re-drawn.

Calling transfer_src_overlay seems to work; but I'm concerned their could be timing issues with the firmware and CHDK both calling this.

Have you come across any other way to tell the Canon code that a screen refresh is needed?

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)

kitor

20

Re: Display (bitmap overlay)

« Reply #201 on: 29 / April / 2021, 02:38:19 »

You need [1] to at least match layer resolution (resolution in MARV structure + buffer size for it) to layer size of Canon code.
After that it is all about manipulating coordinates/size of "rectangle to be transfered" (i mean src_x/y, src_w/h and dst_w/h).

You will probably need to adjust coordinates based on active display output. EOSR does this "accidentally" in Canon code for me.

200D does not, and with "default" offsets (120,30) (720x480) (0,0) it will go to 120x30 of layer buffer, fetch 720x480 rectangle starting from that point and draw it from 0,0 of visible output area.
So for HDMI output one need to switch from (120,30) (720,480) (0,0) to (0,0) (960,640) (0,0), and vice versa.

For cameras with EVF (if they are any) you will have similar third case for EVF.

[1]
As I said a few posts before, layers are not upscaled separately to fit the screen, but there's a single "scaling ratio" defined for whole XimrContext.
Canon code is keeping this scaling ratio "right" for their layers (and this is the reason why all of them have one resolution).

Technically you should be fine with any lower resolution as long as you keep Ximr drawn rectangle coordinates in that buffer - but you won't be able to draw over full screen due to how scaling ratio is handled globally.

As for "telling Canon to refresh", we don't.
In EOS roms there's a flag that we call refresh_display_needed. If set to 1 and refreshVrmsSurface() is called (this is the one that does XimrExe call in EOS), it will redraw everything.

If you just set the flag, you will wait forever, so I initially created own redraw() which set the flag, did caches sync (iirc it was necessary) and called refreshVrmsSurface().

Of course this is different for your codebase, but you can just trace how to properly call that function which does XimrExe inside.

Later we switched into another approach.
We just "steal" winsys semaphore, and guard our own XimrExe call with pointer to "old" (existing) XimrContext structure (as the buffer location used by Ximr in advance). That's it, done.
Winsys semaphore is used in EOS by refreshVrmsSurface() to guard XimrExe too. Not sure if you have any equivalent, and maybe it is not really needed.

The worst it can happen is short visual glitch when switching outputs (as your code might race Canon one, and try to render before Canon updated (in your case regenerated) structure to match HDMI settings)

« Last Edit: 29 / April / 2021, 03:02:42 by kitor »

Logged

Magic Lantern / EOS R / 200D

srsa_4c

4451

Re: Display (bitmap overlay)

« Reply #202 on: 29 / April / 2021, 12:44:42 »

Quote from: philmoz on 29 / April / 2021, 02:28:24

Calling transfer_src_overlay seems to work; but I'm concerned their could be timing issues with the firmware and CHDK both calling this.

Have you come across any other way to tell the Canon code that a screen refresh is needed?

I haven't found a variable that would do that. But I do have an idea for a workaround. If I recall right, most or all drawing operations are done by the CtrlSrv task. If we tell that task to execute transfer_src_overlay, chances for a clash should become pretty low. There is a firmware function for that, I called it exec_via_ctrlsrv in the m100 source. I don't think it's in the sigfinders yet, its address in m100 100a is 0xE033F5E8. Takes a function pointer and another argument which will be passed to the function in r0.
About the order of layers: I'm sure that can be fixed somehow (either by rearranging them or maybe there is priority/z-order info in the ximr struct).

edit:
We could also consider executing just ximrexe instead of the whole transfer_src_overlay.

« Last Edit: 29 / April / 2021, 12:47:55 by srsa_4c »

Logged

kitor

20

Re: Display (bitmap overlay)

« Reply #203 on: 29 / April / 2021, 12:50:22 »

Quote

maybe there is priority/z-order info in the ximr struct

@srsa_4c None that I'm aware of. Layers are always drawn starting from zero. They are always referenced by ID while being added to XimrContext in both EOS and what I saw in M10 ROM.

I guess you want to draw over LV (zebras, etc) but still allow Canon GUI to be drawn over that? As you already alter XimrContext by hand, reordering them should be simple.

[e]

Quote

We could also consider executing just ximrexe instead of the whole transfer_src_overlay.

This is almost exactly what we do currently in Magic Lantern, as mentioned in my previous post.
And it is also how our "April fools" Doom 200D port was redrawing screen in ~20 fps (render code was still the bottleneck)

« Last Edit: 29 / April / 2021, 12:54:12 by kitor »

Logged

Magic Lantern / EOS R / 200D

Ant

509

Re: Display (bitmap overlay)

« Reply #204 on: 02 / May / 2021, 07:01:11 »

Quote from: kitor on 23 / April / 2021, 17:45:52

Additionally, somewhere in XimrContext structure there is scaling ratio (or really two ratios - horizontal and vertical) set.

Yes. I upscaled my own layer. It also can be flipped, mirrored, shifted in 4 directions. But sometimes it disappears. Probably CHDK can draw in 360*240 buffer and then upscale it using XIMR.

chdkptp_scale.png (239.81 kB, 720x480 - viewed 200 times.)

« Last Edit: 02 / May / 2021, 07:10:49 by Ant »

Logged

kitor

20

Re: Display (bitmap overlay)

« Reply #205 on: 02 / May / 2021, 07:12:36 »

@Ant are you sure you upscaled only your layer? I see duplicated Canon GUI is upscaled too.

According to my knowledge you can set scaling ratio (multiplier) once for all layers. This is kind of confirmed by XCMStatus on R+ which displays scaling ratio in Output Chunk section, not per layer.

Which offset in XimrContext you used for that upscaling (and which camera?)

For reference, XCMStatus output (part of XimrContextMaker which is "userspace tool" for XCM on R+):
This should give you an idea what is set "per layer" and what "per context" (those in Output Chunk, XCM can manage 4 contexts at once, that have the same input layers but different output chunk - that's why there are 4 outputs listed).

Code: [Select]

K424[1]>XCMStatus
--- XimrContextMaker 0x00bce800 ---
[Input Layer] No:0, Enabled:1
  VRMS Addr:0x02e18500, pImg:0x02c1e100, pAlp:0x00000000, W:960, H:540
  Color:=0x05040100, Range:FULL
  srcX:0120, srcY:0030, srcW:0720, srcH:0480, dstX:0000, dstY:0000
[Input Layer] No:1, Enabled:1
  VRMS Addr:0x03012a00, pImg:0x02e18600, pAlp:0x00000000, W:960, H:540
  Color:=0x05040100, Range:FULL
  srcX:0120, srcY:0030, srcW:0720, srcH:0480, dstX:0000, dstY:0000
[Input Layer] No:2, Enabled:0
[Input Layer] No:3, Enabled:0
[Input Layer] No:4, Enabled:0
[Input Layer] No:5, Enabled:0

[OutputChunk] No:0, Enabled:1
  VRMS Addr: 0x412ff900, pImg: 0x41100100, pAlp: 0x00000000, W:1024, H:682
  Color:=0x11060200
  LayerEnabledBit:ffffffff, isActualSize:0, isSetToContext:1
  Output Offset X:0000, Y:0000
  Resize fromX:0000, fromY:0000, outputW:1024, outputH:0682
  Horizontal 64/45, filter:0, Vertical 341/240, filter:0
[OutputChunk] No:1, Enabled:0
[OutputChunk] No:2, Enabled:0
[OutputChunk] No:3, Enabled:0

[LUT] Addr:0x00000000 Type:LUT_RANGE_FULL
  LUT is not enabled.

[Ximr Context] No:0, Addr:0x00bce810, Size:0x0000031c, Eanabled:1
//here goes XimrContext structure hex dump, so I skippped it

« Last Edit: 02 / May / 2021, 07:17:20 by kitor »

Logged

Magic Lantern / EOS R / 200D

Ant

509

Re: Display (bitmap overlay)

« Reply #206 on: 02 / May / 2021, 07:40:04 »

Quote from: kitor on 02 / May / 2021, 07:12:36

@Ant are you sure you upscaled only your layer? I see duplicated Canon GUI is upscaled too.

Sure. As you can see my upscaled layer is rendered over Canon's layer and over focus frame. I just copied Layer0 descriptor and put it after Layer1 descriptor.

Quote

Which offset in XimrContext you used for that upscaling (and which camera?)

This should be Byte+0x07 in InputLayer descriptor. 0x06 means both coordinates to be upscaling x2. EOS M3. LCD display type.

« Last Edit: 03 / May / 2021, 03:51:03 by Ant »

Logged

kitor

20

Re: Display (bitmap overlay)

« Reply #207 on: 02 / May / 2021, 07:47:35 »

Quote

This should be Byte+0x07 in InputLayer descriptor. 0x06 means both coordinates x2 upscaling. EOS M3.

I need to test it on EOS, but this looks like a great find!

Logged

Magic Lantern / EOS R / 200D

philmoz

3450

Re: Display (bitmap overlay)

« Reply #208 on: 02 / May / 2021, 21:48:22 »

Thanks @Ant - that's a great find

This works on the G7X2 and works mostly ok on the G5X.

On the G5X when using the EVF the added RGBA layer gets clipped to 347 pixels wide.
In the attached screenshot the 4 blue boxes should all be the same size. The white line on the right is in column 346.

When using the LCD or HDMI the display is correct and the boxes are displayed fully.

Phil.

Screen Shot 2021-05-03 at 11.43.30 am.jpg (92.28 kB, 1026x682 - viewed 23 times.)
Software Used:Adobe Photoshop 22.3 (Macintosh) Color Space:sRGB

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)

pigeonhill

1164

Re: Display (bitmap overlay)

« Reply #209 on: 03 / May / 2021, 04:56:09 »

@reylay

I read in 5868:

Quote

Fix for CHDK menus to resize and position correctly if screen size is changed while menu is displayed. Can happen if switching between LCD, EVF and HDMI.

What I notice on the M3 is that when you switch between LV and EVF, the CHDK histogram does not get drawn in the 'correct' place, ie it seems to remain at its absolute (LCD based) position, rather than its position being scaled.

Just an observation.

Cheers

Garry

Logged