PTP black screen + unlock events (was Re: chdkptp - alternative ptp client) - General Discussion and Assistance - CHDK Forum supplierdeeply

PTP black screen + unlock events (was Re: chdkptp - alternative ptp client)

  • 21 Replies
  • 14299 Views
*

Offline reyalp

  • ******
  • 14118
Advertisements
Finally found a workaround for the long-standing "screen goes black, can't switch to rec after other software accesses the camera" triggered when the camera receives PTP_OC_GetObjectHandles.

On all my dryos cams from d10 (r31) to sx730 (r59), sending
Code: [Select]
=post_levent_to_ui(4482)
turns the screen back on, and rec switching and shooting work. Sometimes it appears to be necessary to click half press once to update the display and wake up the sensor actually switch to rec.

4481 enters black screen mode, and immediately stores the lens if it's out.

On vxworks (a540), the equivalent seem to be 4418 to turn screen on, 4417 to turn off.

These were found by looking at the camera log after sending PTP_OC_GetObjectHandles  (!con:ptp_get_object_handles() in chdkptp)

Bonus: The equivalent of the 4484 "unlock keyboard" event on dryos is offset by the same amount: post_levent_to_ui(4420) unlocks the keyboard while USB is connected on a540.

But wait, there's more!
On wifi enabled cameras (elph130, sx710, g7x at least) it turns out that sending PTP_OC_GetObjectHandles over PTP/IP allows getting past the "connecting" screen, and avoids having the connection time out the way it does if you just sit in the connection screen. The screen goes black like normal, but =post_levent_to_ui(4482) turns it back on, like it does for USB.

On elph130, this makes it possible to switch to rec over wifi, and even use live view. However, attempting to shoot crashes immediately with:
Code: [Select]
ASSERT!! ExMemMan.c Line 1158
in CtrlSrv  :(

The d6 cameras fail to switch to rec: The lens extends, but the display stays on playback, and attempting to shoot brings up a dialog about disconnecting wifi.

edit:
I got g7x to remoteshoot over wifi, by poking 0x8aa8 to 0 (based on code in fc0e03ae).  :o

One oddity: when this is used for rec mode, the camera menu + shoot sounds are enabled and the mute option in the canon menu is disabled.  I normally have them muted. It goes back to normal on reboot.
« Last Edit: 02 / April / 2021, 14:01:10 by reyalp »
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 14118
Wifi discussion moved to https://chdk.setepontos.com/index.php?topic=10724.msg145394#msg145394

I'd like to integrate the black screen fix into CHDK or chdkptp, since this would make it much more plug-and-play on linux, and remove the need to hack udev files. Up to now, I've discouraged people making distro packages of chdkptp because it didn't play nice with stock software.

My initial thought was to use the event if rec switching fails, but on at least some cams, the failed rec switch puts the cam in an unrecoverable state (on elph180, it sits with the LED blinking and I have to pull the battery).

The other options I see are:
1) Post the event from switch_mode_usb, only if the cam is in the black screen state.  This seems like the cleanest / safest solution, but unfortunately, IsControlEventActive doesn't indicate if it's needed. (It does return the status of 0x10b3 / ConnectUSBCable). There must certainly be variables that reflect this state.

2) Always post the event on mode switch, either in chdkptp or CHDK switch_mode_usb. From my testing so far, it seems to be harmless, but hard to be sure it's OK on all cams.

3) Optionally (perhaps by a chdkptp setting that defaults to on) post on chdkptp connect.

The keyboard unlock would also be nice to integrate. I don't have a way to detect if it's needed either. Something like #3 seems like the obvious option.

Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 14118
I found a variable that appears usable to detect the black screen state, and possibly useful for other reverse engineering.

On dryos up to r58, the call immediately after LogCameraEvent(0x60,"AC:PB2Rec") is to a function with an assert in "CameraConState.c". This function sets the variable, and also keeps a history of the last 10 values.
(thumb2 r59 cams have an additional call in between, which I think is actually related to bluetooth functionality rather than dryos version)

The function UI_ShowStateOfRecMode prints the state history, among other things.

There is a corresponding getter function, which on dryos is called immediately after log "DlvrUSBCnct"

Similar functions exist on vxworks except a couple very early models like ixus30.

On all my cameras (a540 through sx730), the state is normally 1 = rec, 2 = playback, 3 = PTP black screen (both USB and Wifi). The black screen unlock event updates the state.

From strings in disassembly, I believe 4 is direct print. The code uses additional values transitioning between states, which vary somewhat between models. These can be seen in the history but in my testing don't last long enough appear on a debug display.

I've added matches for these in finsig_thumb2 (trunk r5805), named
cameracon_set_state
cameracon_get_state
cameracon_state

In practice, only the variable or getter is required, but they're easy to match and seeing them in disassembly seems useful.

I'll work on adding them to the other sig finders later.

edit:
Here's a patch that adds logic for the event in switch_mode_usb. Currently enabled for THUMB_FW only

The waits are kind of ugly. The one after posting the event is definitely needed. The one before might not be needed in real usage, but should be harmless as long as all the states above 4 are short.

Additionally, it seems like the playback UI showing after switching to rec isn't just a UI issue. On sx710 (at least) the get_mode() still says it's in play until halfpress is clicked (the camera must briefly report being in rec, because chdkptp thinks it succeed). After clicking halfpress, it seems to really in rec, and subsequent mode switches seem to work normally. Maybe there's another event that needs to be sent, or a higher level function to call.
« Last Edit: 01 / April / 2021, 02:28:36 by reyalp »
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 4451
I tried two of my cams. Both use the constants mentioned, although the M10 never goes into blank screen mode (so I could not observe state 3). The patch works on sx280, it does not suffer from issues when switching to rec.


*

Offline reyalp

  • ******
  • 14118
(wifi specific discussion split to https://chdk.setepontos.com/index.php?topic=10724.msg145454#msg145454 - not sure it makes sense to try to split up. I'll try to keep things that are wifi only in that thread for now, but don't worry about replying in the wrong thread)

Here's patch that enables the black screen unlock for all models, except very early vxworks (ixus30, 40, 50, 700 and s2is). The cameras without support just have the additional code disabled, because the cameracon_state variable isn't found.

This works completely for me on a540, d10, sx160 and elph130. On my dryos >=r55 cameras (g7x, sx710, elph180, sx730) switching to rec using switch_mode_usb fails, but switching with half press after that works, and subsequent switches are OK.

I'm inclined to check this patch in roughly as is, because it seems to be a significant improvement for most cameras.

My test case is:
connect using chdkptp over usb
!con:ptp_get_object_handles()
rec
shoot
record video
play
rec


Poking the variable discussed earlier makes switch_mode_usb work as expected on the dry55+ cams. When connected to USB, I don't see the menu issues mentioned in https://chdk.setepontos.com/index.php?topic=10724.msg145470#msg145470 (on elph180, the variable is 0x23b4)

My current thinking is the menu weirdness on wifi isn't caused by variable, rather it's other state associated with wifi (perhaps because rec+wifi on these cams expects to run from the mobile app), and the variable just allows getting into rec in the first place.

I suspect the variable needing to be poked is a change between dryos r52 (elph130 and sx280 don't need it) and r55.  The same variable appears to be present on elph130 (0x2934) but it isn't set by con:ptp_get_object_handles().

It would be nice to know if it's required in r54 (r54 cams include ixus145_elph135, ixus150_elph140, ixus265_elph340, sx600, sx700), I wasn't able to tell for sure from disassembly.

The code related to cameracon_state and this variable seems to center around a function that has a switch on cameracon_state (elph130 ff0810e8, elph180 ff858684, g7x fc0dfe1c)
It appears to take 2 parameters that look like levent IDs (or 0), and transitions to the next cameracon_state. On the cameras the require poking the variable, it's set in the cases related transitioning to state 3 and state 4 (often cases 0xd and 0xe, but varies). The immediately following variable seems to often be set with it.

edit:
A couple more observations
Sending the black screen unlock 4482 / 4418 event when the screen isn't black seems harmless. It also unlocks the keyboard, like 4484 / 4420.
« Last Edit: 04 / April / 2021, 20:18:03 by reyalp »
Don't forget what the H stands for.

*

Offline Caefix

  • *****
  • 947
  • Sorry, busy deleting test shots...
Quote
It would be nice to know if it's required in r54 (r54 cams include ixus145_elph135, ixus265_elph340, sx600, sx700).
Compiled with patch2...
 ??? What to do to know how to do to do what??
// sx600  :blink: Have I missed a hidden port?
All lifetime is a loan from eternity.

*

Offline reyalp

  • ******
  • 14118
Compiled with patch2...
 ??? What to do to know how to do to do what??
Normally, when the camera receives PTP GetObjectHandles, the camera screen goes black and it's no longer possible to switch to rec. Up to now, this made it impossible to use chdkptp for shooting when after normal PTP software access the camera.

In chdkptp, you put the camera in this black screen state using !con:ptp_get_object_handles()

With the patch on dryos 52 and earlier, using rec after this has been done turns the screen back on and switches to rec mode.

On r55 and later cameras with the patch, the screen turns on and the lens extends, but then the camera goes back to play. Pressing half press switches to rec after that.

What I want to know is if r54 behaves like r52 or r55

Quote
// sx600  :blink: Have I missed a hidden port?
No, I was just looking at https://chdk.fandom.com/wiki/P-ID_(Table) and didn't check if there was a port  :-[
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 4451
What I want to know is if r54 behaves like r52 or r55
I tried ixus150, running CHDK patched with the work-2 patch. GetObjectHandles is issued by the gphoto gvfs module. I can connect to the camera while it's blacked out, pressing rec in chdkptp switches to rec with no issues (I see live view, etc).


*

Offline reyalp

  • ******
  • 14118
I tried ixus150, running CHDK patched with the work-2 patch. GetObjectHandles is issued by the gphoto gvfs module. I can connect to the camera while it's blacked out, pressing rec in chdkptp switches to rec with no issues (I see live view, etc).
Thanks. Sounds like it's r55 and later that has the issues.
Don't forget what the H stands for.

*

Offline blackhole

  • *****
  • 942
  • A590IS 101b
    • Planetary astrophotography
I have a code for the sx600 r54, fw 100d if you need to test, but I don't have a camera.

Poslano sa mog GT-I9301I koristeći Tapatalk


 

Related Topics


SimplePortal 2.3.6 © 2008-2014, SimplePortal