Display (bitmap overlay)

62ndidiot

596

Re: Display (bitmap overlay)

« Reply #70 on: 02 / April / 2017, 23:26:48 »

Advertisements

I think @ant s version of edge overlay and mine were equivalent. In hindsight, ant's is easier to maintain and verify since it cleanly separates digic 6 code form pre digic 6 with little intermingling.

As for erasing, that needs to be worked on I guess. I confess to not really understanding how edge overlay is used. It may be as simple as adding a call to the new gui_draw routine "set_transparent" at the appropriate point.

Logged

reyalp

14110

Re: Display (bitmap overlay)

« Reply #71 on: 02 / April / 2017, 23:39:37 »

Quote from: 62ndidiot on 02 / April / 2017, 23:26:48

I think @ant s version of edge overlay and mine were equivalent.

Attached is the one I tried. It still applies and builds cleanly with the current code.

Quote

As for erasing, that needs to be worked on I guess. I confess to not really understanding how edge overlay is used.

It's confusing, I had to go back to the manual. But it definitely shouldn't fill up the screen with old edges when you have half-press held for the first shot. This may not be obvious if the canon firmware OSD is updating frequently too, since it would blow away the stale edges.

edgeoverlay-d6-ant-1.patch (5.99 kB - downloaded 24 times.)

Logged

Don't forget what the H stands for.

srsa_4c

4451

Re: Display (bitmap overlay)

« Reply #72 on: 03 / April / 2017, 20:05:03 »

Quote from: reyalp on 02 / April / 2017, 22:28:00

Quote
- decisions based on font size are inconsistent
core/gui_draw.c draw_icon_cmds()
modules/gui_osd_edit.c
I'm not sure I follow. Do you mean using #ifs vs runtime, or something else?

Unfortunate wording.

In draw_icon_cmds() I used this:

Code: [Select]

if (FONT_HEIGHT > 16)to choose between doubled or unchanged coordinates. Perhaps a separate #define would be more appropriate.

In modules/gui_osd_edit.c, I put in a bunch of #if's like this

Code: [Select]

#if (FONT_HEIGHT <= FONT_REAL_HEIGHT)which will need to be fixed if the default font is changed to a native resolution one (if that ever happens).

Logged

reyalp

14110

Re: Display (bitmap overlay)

« Reply #73 on: 08 / April / 2017, 00:55:54 »

The edge overlay drawing issue happens because draw_get_pixel_unrotated is noop in digic, and the edge code uses this to erase pixels that don't correspond to edges.

I checked in Ant's code, since I don't see an obvious quick fix and it works reasonably well if you don't move the camera around when edge is live.

Logged

Don't forget what the H stands for.

reyalp

14110

Re: Display (bitmap overlay)

« Reply #74 on: 16 / April / 2017, 19:14:16 »

I've noticed occasional crashes on G7x that appear to be related to drawbusyonscreen

These seem to happen switching between play and rec over ptp. Haven't had time to look into it yet.

Example romlog attached.

edit:
Added a second romlog I annotated previously

romlog-g7x-100d-ptp-play-2017-04-16.log (6.2 kB - downloaded 24 times.)

dlgitem-romlog.log (3.11 kB - downloaded 22 times.)

« Last Edit: 17 / April / 2017, 02:03:58 by reyalp »

Logged

Don't forget what the H stands for.

waterwingz

12140

Re: Display (bitmap overlay)

« Reply #75 on: 16 / April / 2017, 19:32:05 »

Quote from: reyalp on 16 / April / 2017, 19:14:16

I've noticed occasional crashes on G7x that appear to be related to drawbusyonscreen These seem to happen switching between play and rec over ptp. Haven't had time to look into it yet.

I think that I've finally tracked down some pseudo-random G16 crashes (usually when entering ALT) to vid_bitmap_refresh(). It uses _displaybusyonscreen() and _undisplaybusyonscreen().

If I comment out those routine things seem to be much more stable but the screen gets messy.

edit : take this with a "grain of salt" - early port with lots of other stuff broken

« Last Edit: 16 / April / 2017, 21:06:00 by waterwingz »

Logged

Ported : A1200 SD940 G10 Powershot N G16

srsa_4c

4451

Re: Display (bitmap overlay)

« Reply #76 on: 16 / April / 2017, 20:11:37 »

Quote from: reyalp on 16 / April / 2017, 19:14:16

I've noticed occasional crashes on G7x that appear to be related to drawbusyonscreen

These seem to happen switching between play and rec over ptp. Haven't had time to look into it yet.

Example romlog attached.

Looks like a failed sanity check on a pointer to a dialog item, bit0 is set -> corrupted or invalid pointer.
The busy dialog does have a few dialog items: an icon and the "busy" text (there might be other components that qualify as dialog items).

I realize that getting rid of the busy screen hack would be a major step forward, but I, unfortunately, still have no idea about a good replacement.

Logged

reyalp

14110

Re: Display (bitmap overlay)

« Reply #77 on: 04 / July / 2017, 21:14:58 »

I (re?) discovered another feature of the drawbusyonscreen hack. The Canon firmware ignores key presses generated when the busy dialog is shown.

This means that if CHDK does something that generates a key press and also refreshes the screen (like sending a click in chdkptp), it is likely to be ignored. Worse, in some cases only the release is missed, making the Canon firmware think the button is held down.

Initially I thought g7x just needed CAM_KEY_PRESS_DELAY, but increasing it up to 140 didn't make the problem go away. It does help a bit.

With displaybusyonscreen/undisplaybusyonscreen commented out of lib.c, key presses work fine using the standard delay, but of course screen refresh is totally hosed.

Logged

Don't forget what the H stands for.

srsa_4c

4451

Re: Display (bitmap overlay)

« Reply #78 on: 15 / July / 2017, 12:47:04 »

Some research on DIGIC 6 overlay (sx280).
I have managed to log all messages sent to the 'graphic core'. Also logged the messages' content.
Unfortunately, none of this did uncover anything usable.

Sending messages consists of two phases:
- creating the message (uses a message ID (3rd argument in the sx280 version), message length, a handle (or pointer) and a message type(?) ).
I named the function that is used to do this 'mzrm_createmsg'. It can be recognized by the "[Mzrm]CreateWait" debug string.
The function allocates the requested message area and returns a pointer to it.
The returned area starts with a mandatory header, 3 words: ID, type(?), length, which adds to the requested size.
- sending the message (uses the same handle as 'mzrm_createmsg' plus the pointer returned by 'mzrm_createmsg')
Can be identified by looking for "[Mzrm]SendWait". I named it 'mzrm_sendmsg'.
It also returns a value (I'm not sure yet how longer responses are retrieved).

All messaging functions call the above 2 functions.
The message ID - message name translation requires the message name table from the Xtensa blob - related post is https://chdk.setepontos.com/index.php?topic=11316.msg129104#msg129104 .
sx280 version is attached here: https://chdk.setepontos.com/index.php?topic=11316.msg129051#msg129051
g7x version is here: https://chdk.setepontos.com/index.php?topic=11316.msg129344#msg129344

Both mzrm_createmsg and mzrm_sendmsg start with a call to TakeSemaphore, which is located in RAM - can be hacked.

My current guess on the MZRM acronym is: [M]arius (main ARM core), [Z]ico (graphic core), [R]?, [M]essaging

Captures are attached, showing the sx280 booting up to playback mode with a photo displayed, plus CHDK activity caused by its (Un)DisplayBusyOnScreen calls.
Both captures include a USB cable insertion which erases the screen without showing "ScreenLock" and its friends in the camera log.
Line structure of the basic (shorter) capture is: system tick, message, LR (return address), task name
The longer capture adds more info (call stack, message content).

Messages have more and less obvious parts.
Framebuffer addresses and dimensions (640, 480) are recognizable. ROM addresses are also present, which may indicate that the Xtensa also sees the ROM.

A stream of messages usually ends with these 3 messages:
GraphicSystemCoreFinish, JediFinish, XimrExe

Unless I missed something, the addresses of 'our' overlay buffers (YUV+opacity) only show up in XimrExe messages. That X might mean 'transfer'.

Camera log during the detailed capture:

Code: [Select]

00000320: UI:LogicalEvent:0x5006:adr:0,Para:0
00000400: UI:Initialized WindowSystem.
00000400: UI:ScreenLock
00000400: UI:ScreenUnLock
00000410: UI:LogicalEvent:0x300a:adr:0,Para:0
00000410: UI:DispSwCon_TurnOnBackLight
00000410: UI:TurnOnBackLight
00000420: UI:CECConnectCnt
00000420: UI:HDMIConnectCnt
00000420: UI:MuteOffPhysicalScreen
00000420: UI:LogicalEvent:0x3139:adr:0,Para:0
00000460: UI:PB.Create
00000640: UI:LogicalEvent:0x301c:adr:0,Para:0
00000650: UI:PB.CreateE
00000650: UI:AC:StartPB
00000650: UI:DispSwCon_TurnOnDisplayDevice
00000650: UI:AC:EBtn
00000650: UI:PB.Start
00000650: UI:ScreenLock
00000650: UI:DSIC:47,0
00000650: UI:CC_CompFlhJpg
00000650: UI:_CompFlhJpg
00000650: UI:PB.Flash
00000650: UI:PB.S_Meta
00000650: UI:DSIC:47,0
00000650: UI:LogicalEvent:0x3201:adr:0,Para:0
00000650: UI:ScreenUnLock
00000660: UI:LogicalEvent:0x320b:adr:0,Para:0
00000660: UI:PB.StartE
00000660: UI:DisplayPhysicalScreenCBR
00000660: UI:DispSw: Unlock
00000660: UI:DispSwCon:Unlock
00000660: UI:DispSwCon_TurnOnBackLight
00000660: UI:DispSwCon_MuteOffPhysicalScreen
00000660: UI:Window MuteOff
00000660: UI:MuteOffPhysicalScreen
00000660: UI:DSIC:ed,0
00000660: UI:AC:EnryPB
00000660: UI:AP:ChkCnctUSB
00000660: UI:PB.DPOF
00000660: UI:DisplayPhysicalScreenCBR
00000670: UI:LogicalEvent:0x3221:adr:0x194b080,Para:26521728
00000670: UI:PB.MAX_ID
00000670: UI:PB.RefPB
00000670: UI:ScreenLock
00000670: UI:DSIC:47,0
00001060: UI:PB.DrawI
00001120: UI:LogicalEvent:0x3220:adr:0,Para:0
00001120: UI:PB.CTG
00001190: UI:LogicalEvent:0x666f:adr:0,Para:0
00001250: UI:LogicalEvent:0x3204:adr:0,Para:0
00001250: UI:PB.Check
00001260: UI:PB.DcdCBR
00001260: UI:DSIC:48,0
00001260: UI:PB.RfrsI
00001260: UI:PB.F_Dec
00001260: UI:LogicalEvent:0x3202:adr:0,Para:0
00001260: UI:ScreenUnLock
00001330: UI:DSIC:48,0
00001330: UI:DispSw: Unlock
00001330: UI:DispSwCon_TurnOnBackLight
00001330: UI:DispSwCon_MuteOffPhysicalScreen
00001330: UI:Window MuteOff
00001330: UI:MuteOffPhysicalScreen
00001330: UI:DisplayPhysicalScreenCBR
00002300: UI:ScreenLock
00002320: UI:ScreenUnLock
00002370: UI:DisplayPhysicalScreenCBR
00004140: UI:Button:0x000010B3:ConnectUSBCable
00004140: UI:IsWirelessConnect?:0
00004140: UI:ChkStoreLens
00004140: UI:IntPcCnct
00004140: UI:DlvrUSBCnct
00004140: UI:_CnctUSBCBR
00004190: UI:LogicalEvent:0x3138:adr:0,Para:0
00004200: UI:LogicalEvent:0x5005:adr:0,Para:0
00004200: PTPRspnd.StartUpPTPFrameworkClient
00007570: UI:ScreenLock
00007590: UI:ScreenUnLock
00007650: UI:DisplayPhysicalScreenCBR
00008220: UI:ScreenLock
00008240: UI:ScreenUnLock
00008300: UI:DisplayPhysicalScreenCBR
00009210: System.Create
00009210: StartRedirectUART
00009230: Printf
00009230: ShowCameraLog

shortcapture.txt (50.23 kB - downloaded 24 times.)

longcapture.txt (399.31 kB - downloaded 22 times.)

Logged

srsa_4c

4451

New screen refresh method on DIGIC 6

« Reply #79 on: 16 / July / 2017, 10:34:23 »

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.

I'm currently test-driving this method, but have not found any glitches so far.

I'd like to note that the functions involved are heavy stack users, but so were the busy dialog functions.

I think this might enable us to use the RGBA buffer directly, but I'm not sure yet.

edit:
g16 101a: 0xFC15A05B
m3 101a: 0xFC37ECA3 (looks a bit different, but the m3 is newer codebase)
sx60 100f: 0xFC337089 (also looks newer)
g7x 100d: 0xFC36168B (also newer)

Confirm address by using disasm before using, though.

sx280_newscreenrefresh.diff (2.34 kB - downloaded 27 times.)

« Last Edit: 16 / July / 2017, 10:59:24 by srsa_4c »

Logged