Display (bitmap overlay) - page 13 - General Discussion and Assistance - CHDK Forum supplierdeeply

Display (bitmap overlay)

  • 159 Replies
  • 48764 Views
*

Offline Ant

  • ****
  • 431
Re: Display (bitmap overlay)
« Reply #120 on: 21 / December / 2017, 14:11:43 »
Advertisements
I've shifted text strings rendered by SflwWrpDrawStringWithinRect, but some text stayed on the same positions.
So Canon OSD is rendered by JediDraw unlike menus.

*

Offline srsa_4c

  • ******
  • 3943
Re: Display (bitmap overlay)
« Reply #121 on: 21 / December / 2017, 14:17:08 »
I was about to write that
Quote
With JediDraw and SflwWrpDrawStringWithinRect messages blocked, all Canon drawings disappear from screen.
when I found out that I still get text on screen when I enter the shooting mode selection menu. So, apparently there are other ways to draw text (and make it move/disappear), still to be found out.
About the length of JediDraw messages: I suspect that it's this word in Ant's example: 000000c0. In some cases, certain bytes of the structure are not initialized, showing the usual uninitialized memory junk.

Some JediDraw messages refer to resources in ROM - my guess is that those are bitmap or vector images - unfortunately, in an unknown format.

edit:
The message used for drawing text on the shooting mode selection menu is OAE_PackerSeaflowDrawWithinRect. Maybe that's all, maybe there's more. This message can also be blocked without consequences.
« Last Edit: 02 / January / 2018, 15:09:41 by srsa_4c »

*

Offline Ant

  • ****
  • 431
Re: Display (bitmap overlay)
« Reply #122 on: 04 / January / 2018, 17:49:45 »
edit:
The message used for drawing text on the shooting mode selection menu is OAE_PackerSeaflowDrawWithinRect.

Older cameras (M3, G7X, SX60, SX280) don't have this message.

*

Offline srsa_4c

  • ******
  • 3943
Re: Display (bitmap overlay)
« Reply #123 on: 27 / August / 2018, 15:43:30 »
Parts of CHDK assume that viewport dimensions match the bitmap overlay dimensions. The ones I know of are
- zebra
- edge overlay

When HDMI output is active (and it is fullHD res), viewport and overlay dimensions are different - viewport is fullHD, overlay is quarter of that (960x540 on DIGIC 6).
Under these conditions, edge overlay simply misbehaves (blocks physw, no display), but current zebra code overflows the overlay buffers (which, depending on camera RAM layout, can cause a crash).
The above modules can probably be fixed(*), but until that happens, I'm considering to add checks to skip problematic parts of their code when viewport is larger than overlay.

*That fix is only "easy" when overlay size is quarter of viewport size. There are alternative viewport buffers in rec mode that are sized differently.


Re: Display (bitmap overlay)
« Reply #124 on: 27 / August / 2018, 19:53:56 »
Question: can HDMI output be active in shoot mode?

Re: Display (bitmap overlay)
« Reply #125 on: 27 / August / 2018, 23:43:59 »
Question: can HDMI output be active in shoot mode?
AFAIK, you could get HDMI (or at least some sort of live video?) on older Powershots but Canon disabled that feature several (?) years ago.
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline reyalp

  • ******
  • 12002
Re: Display (bitmap overlay)
« Reply #126 on: 28 / August / 2018, 00:44:12 »
Question: can HDMI output be active in shoot mode?
AFAIK, you could get HDMI (or at least some sort of live video?) on older Powershots but Canon disabled that feature several (?) years ago.
Many cameras, including recent models allow analog video out. Canon dropped this capability on lower end cameras.

The EOS M cameras are the only CHDK supported models which allow HDMI out in rec mode.
Don't forget what the H stands for.

*

Offline Ant

  • ****
  • 431
Re: Display (bitmap overlay)
« Reply #127 on: 19 / January / 2019, 17:05:21 »
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.

Emulating EOS M3 in QEMU I found better way to intercept MZRM messages.
Function 0xFC3F10D8 (pointer stored at 0xBFF00420) is always called inside mzrm_sendmsg (at 0xFC2FD87E). The number(n[0..31]) of current message to send is stored at 0xBFF00410. The pointer to it's buffer is stored at 0xBFF00468+4*n. The number of message accepted by MZRM is stored at 0xBFF00428.


*

Offline Ant

  • ****
  • 431
Re: Display (bitmap overlay)
« Reply #128 on: 05 / February / 2019, 13:18:06 »
Finally got this drawing using  JediDraw and SflwWrpDrawStringWithinRect


Some info about JediDraw and SflwWrpDrawStringWithinRect:
Code: [Select]
38310:39331627: PhySw:0x00000000:
Message: 0108: JediDraw, size:0044,addr:bff00500 [29-29]
bff00500[+000]: 0000006c
bff00504[+004]: 00000000
bff00508[+008]: 0000002c
bff0050c[+012]: bff0051c pointer to output buffer
bff00510[+016]: 006a6420 pointer to JediDraw structure
bff00514[+020]: 00000000
bff00518[+024]: 000000c0 size of this JediDraw structure
bff0051c[+028]: 5652414d VRAM signature
bff00520[+032]: 42541000 ARGB buffer address
bff00524[+036]: 00000000
bff00528[+040]: 05000004
bff0052c[+044]: 000003c0 width
bff00530[+048]: 000001e0 height
bff00534[+052]: 00000000

JediDraw structure at 0x006a6420:
006a6420[+000]: 00c00101 object type 0C00 - vector graphic, bits [8-11] - the position
of the object relative to the coordinates (1 - 4th quadrant, 5 - center, 9 - 2nd quadrant)
006a6424[+004]: 006a64e0 pointer to next JediDraw structure
006a6428[+008]: fd82d41c address of vector object (fd82d41c - filled rectangle)
006a642c[+012]: 00000000
006a6430[+016]: 006a64b8 pointer to drawing limits
006a6434[+020]: 00000004
006a6438[+024]: 00000000
006a643c[+028]: 00000000
006a6440[+032]: 000000c0 size of this JediDraw structure
006a6444[+036]: 00000001
006a6448[+040]: 00000000
006a644c[+044]: 00000000
006a6450[+048]: 000000ff
006a6454[+052]: 00000000
006a6458[+056]: 00000000
006a645c[+060]: 00000000
006a6460[+064]: 43480000 x position of object, float32
006a6464[+068]: 42ec0000 y position of object, float32
006a6468[+072]: 002a00b4 bits [16-31] object height, bits [0-15] object width   
006a646c[+076]: 00640064
006a6470[+080]: 00640064
006a6474[+084]: 00000000
006a6478[+088]: 00000000
006a647c[+092]: 006a64ac pointer to object color ???
006a6480[+096]: 00000000
006a6484[+100]: 00020001 bits [16-31] border thickness
006a6488[+104]: 000000ff border color RGBA
006a648c[+108]: 00640064 color coefficients ???
006a6490[+112]: 00640064 color coefficients ???
006a6494[+116]: 00000000
006a6498[+120]: 00000000
006a649c[+124]: 00000000
006a64a0[+128]: 00640100
006a64a4[+132]: 00000000
006a64a8[+136]: 0003f30c
006a64ac[+140]: 0000000c
006a64b0[+144]: 00000001
006a64b4[+148]: ff00a000 object color ARGB
006a64b8[+152]: 00000000 x position of drawing limits
006a64bc[+156]: 00000000 y position of drawing limits
006a64c0[+160]: 000002d0 width of drawing limits
006a64c4[+164]: 000001e0 height of drawing limits
006a64c8[+168]: afafafaf unused in 0C00 structure
006a64cc[+172]: afafafaf unused in 0C00 structure
006a64d0[+176]: afafafaf unused in 0C00 structure
006a64d4[+180]: afafafaf unused in 0C00 structure
006a64d8[+184]: afafafaf unused in 0C00 structure
006a64dc[+188]: afafafaf unused in 0C00 structure
38310:JediDraw [180,042] at [000,000-720,480] col:ff00a000 [0200:0118]

38310:39332640: PhySw:0x00000000:
Message: 0064: SflwWrpDrawStringWithinRect, size:0076,addr:bff00550 [30-29]
bff00550[+000]: 00000040
bff00554[+004]: 00000000
bff00558[+008]: 0000004c
bff0055c[+012]: bff0058c pointer to output buffer
bff00560[+016]: 00c80000 bits [16-31] x position of string
bff00564[+020]: 00940000 bits [16-31] y position of string
bff00568[+024]: 00000000 bits [16-31] string width
bff0056c[+028]: 00000000 bits [16-31] string heght
bff00570[+032]: bff00580 pointer to string
bff00574[+036]: 00000009
bff00578[+040]: 00000000
bff0057c[+044]: 00000000
bff00580[+048]: 4b444843 'CHDK'
bff00584[+052]: 31303220 ' 201'
bff00588[+056]: 00000039 '9'
bff0058c[+060]: 5652414d VRAM signature
bff00590[+064]: 42541000 ARGB buffer address
bff00594[+068]: 00000000 
bff00598[+072]: 05000004 
bff0059c[+076]: 000003c0 width
bff005a0[+080]: 000001e0 height
bff005a4[+084]: 00000000
SflwWrpDrawStringWithinRect [0200,0148]:[0000,0000] CHDK 2019

Probably it could be used for rendering CHDK GUI, but we need to synchronize somehow with Canon GUI drawing...
« Last Edit: 05 / February / 2019, 13:23:04 by Ant »

*

Offline srsa_4c

  • ******
  • 3943
Re: Display (bitmap overlay)
« Reply #129 on: 05 / February / 2019, 13:44:51 »
Nice reverse engineering work. My choice (for CHDK display) would be a method that draws a large bitmap, where we could write the bitmap's contents. But the main problem is this:
but we need to synchronize somehow with Canon GUI drawing...

 

Related Topics