USB Remote Switch in CHDK - version 2 implementation thread - page 22 - General Discussion and Assistance

waterwingz

12138

Re: USB Remote Switch in CHDK - version 2 implementation thread

« Reply #210 on: 09 / February / 2015, 22:44:51 »

Advertisements

Quote from: reyalp on 09 / February / 2015, 22:09:41

I wouldn't assume you get correct behavior by using switch_mode_usb and than toggling USB power later. switch_mode_usb has some side effects too, so it would probably be better to mask the USB power completely.

Yup - playing with the modified script some more It seems that using switch_mode_usb(1) is no better at preventing the camera going into playback mode when the 5V goes active.

I guess this means either going back to using set_ config_value(cfg.remote_enable,1) or adding another script function that masks/unmasks the USB bit?

Or maybe a new function that combines usb_force_active(), usb_sync_wait(), and usb_mask_pwr_bit() ?

« Last Edit: 09 / February / 2015, 22:50:28 by waterwingz »

Logged

Ported : A1200 SD940 G10 Powershot N G16

reyalp

14000

Re: USB Remote Switch in CHDK - version 2 implementation thread

« Reply #211 on: 09 / February / 2015, 23:27:27 »

Quote from: waterwingz on 09 / February / 2015, 22:44:51

I guess this means either going back to using set_ config_value(cfg.remote_enable,1) or adding another script function that masks/unmasks the USB bit?

Requiring remote_enable doesn't seem terrible to me, since you are using the remote, but if you can come up a new functions that do it more cleanly that would be fine with me.

If you were using it in conjunction with PTP, it might be annoying if the setting ended up getting saved.

It would be tempting to have something like usb_force_active that took three values: force active, force inactive, leave it alone. Not sure how you'd fit that with the existing functions though.

Logged

Don't forget what the H stands for.

waterwingz

12138

Re: USB Remote Switch in CHDK - version 2 implementation thread

« Reply #212 on: 10 / February / 2015, 08:28:00 »

Quote from: reyalp on 09 / February / 2015, 23:27:27

It would be tempting to have something like usb_force_active that took three values: force active, force inactive, leave it alone. Not sure how you'd fit that with the existing functions though.

Hmmm .. how about

usb_force_active = 0 : auto
usb_force_active = 1 : "active"
usb_force_active = 2 : "inactive"

The current definition will accept false/true or 0/1 so I think this would be backwards compatible Not sure what happens of you feed it a "2" today but its not like this has a ton of naive users (at least not yet).

And this is kind of how the set_nd_filter() function works.

Edit 1 : this will also likely require a simple mass edit of kbd.c for ever camera though
Edit 2 : we currently have CAM_ALLOWS_USB_PORT_FORCING as a platform_camera.h option. I think that was done "out of an abundance of caution" (as the lawyers say). Do we rid of that and build it in for all cameras ?

« Last Edit: 10 / February / 2015, 16:02:13 by waterwingz »

Logged

Ported : A1200 SD940 G10 Powershot N G16

reyalp

14000

Re: USB Remote Switch in CHDK - version 2 implementation thread

« Reply #213 on: 10 / February / 2015, 16:19:49 »

Quote from: waterwingz on 10 / February / 2015, 08:28:00

usb_force_active = 0 : auto
usb_force_active = 1 : "active"
usb_force_active = 2 : "inactive"

The current definition will accept false/true or 0/1 so I think this would be backwards compatible Not sure what happens of you feed it a "2" today but its not like this has a ton of naive users (at least not yet).

And this is kind of how the set_nd_filter() function works.

The meaning of true and false would not be very clear at this point.

Quote

Edit 1 : this will also likely require a simple mass edit of kbd.c for ever camera though
Edit 2 : we currently have CAM_ALLOWS_USB_PORT_FORCING as a platform_camera.h option. I think that was done "out of an abundance of caution" (as the lawyers say). Do we rid of that and build it in for all cameras ?

I think the main reason was just not wanting to edit all the files.

I would really like to make the generic parts of the keyboard code actually generic. It would make adding/changing features like this much easier, and moving most of the logic to thumb would probably save memory too. That would be good to do for 1.4, but whether I (or any other brave volunteer) will get to it is a another question. It's been bugging me for a while so I'll try to take a stab at it next weekend.

For the sync stuff, I'd suggest just sticking with set_config_value remote_enable and revisit if / when the keyboard code cleaned up.

Logged

Don't forget what the H stands for.

waterwingz

12138

Re: USB Remote Switch in CHDK - version 2 implementation thread

« Reply #214 on: 10 / February / 2015, 16:28:10 »

Quote from: reyalp on 10 / February / 2015, 16:19:49

The meaning of true and false would not be very clear at this point.

Well, we could change it or just leave it there for legacy reasons but not document it. Make the docs only say 0,1,2 as valid choices.

Quote

I think the main reason was just not wanting to edit all the files.

It would be a pretty easy SED macro with a few manual tweaks.

Quote

For the sync stuff, I'd suggest just sticking with set_config_value remote_enable and revisit if / when the keyboard code cleaned up.

It would still be nice to clean-up the sync logic and add the usb_sync_wait() function.

« Last Edit: 10 / February / 2015, 16:29:56 by waterwingz »

Logged

Ported : A1200 SD940 G10 Powershot N G16

reyalp

14000

Re: USB Remote Switch in CHDK - version 2 implementation thread

« Reply #215 on: 10 / February / 2015, 17:16:59 »

Quote from: waterwingz on 10 / February / 2015, 16:28:10

Quote
For the sync stuff, I'd suggest just sticking with set_config_value remote_enable and revisit if / when the keyboard code cleaned up.
It would still be nice to clean-up the sync logic and add the usb_sync_wait() function.

Yes, what I meant was apply the usb_sync_wait() patch and just require using set_config_value remote_enable for now.

Logged

Don't forget what the H stands for.

srsa_4c

4451

usb_remote_status_led()

« Reply #216 on: 03 / July / 2015, 17:53:31 »

I have no idea where to post this - so I'm posting it in the latest related thread.

usb_remote_status_led() in core/usb_remote.c is using hardcoded constants for LED control. This is fine up to (and including) DIGIC 4, but may not work on later DIGICs.
To make things difficult, DIGIC 5 ports usually seem to use a "read-modify-write" style direct LED control, so simply defining 2 constants (LED-ON/LED-OFF) may not be enough.

@WW
REMOTE_SYNC_STATUS_LED is defined for the S100, does it work as intended?

Logged

waterwingz

12138

Re: usb_remote_status_led()

« Reply #217 on: 03 / July / 2015, 18:50:40 »

Quote from: srsa_4c on 03 / July / 2015, 17:53:31

I have no idea where to post this - so I'm posting it in the latest related thread.

Probably a better fit here : USB Remote Switch in CHDK - version 2 implementation thread ?

Quote

usb_remote_status_led() in core/usb_remote.c is using hardcoded constants for LED control. This is fine up to (and including) DIGIC 4, but may not work on later DIGICs. To make things difficult, DIGIC 5 ports usually seem to use a "read-modify-write" style direct LED control, so simply defining 2 constants (LED-ON/LED-OFF) may not be enough.

So we probably need to move the function to the lib.c or kbd.c file in each camera's platform directory? That's how get_usb_bit() is handled now.

Quote

@WW : REMOTE_SYNC_STATUS_LED is defined for the S100, does it work as intended?

Not my port so I've actually never looked. It does not work - the S100 has only one LED (small green one down by the playback button) and an focus assist lamp. Neither illuminate when USB remote sync is enabled and a shot is taken. Normally one of them would while the camera waits for the USB signal to be released.

Logged

Ported : A1200 SD940 G10 Powershot N G16

srsa_4c

4451

Re: usb_remote_status_led()

« Reply #218 on: 03 / July / 2015, 19:36:00 »

Quote from: waterwingz on 03 / July / 2015, 18:50:40

Probably a better fit here : USB Remote Switch in CHDK - version 2 implementation thread ?

Thanks.
Can a mod move these posts please?

Quote

So we probably need to move the function to the lib.c or kbd.c file in each camera's platform directory?

Or we could do it with macros, so the code can stay thumb.

Quote

Quote
@WW : REMOTE_SYNC_STATUS_LED is defined for the S100, does it work as intended?
Not my port so I've actually never looked. It does not work - the S100 has only one LED (small green one down by the playback button) and an focus assist lamp. Neither illuminate when USB remote sync is enabled and a shot is taken.

Thanks for checking. The same LED address is used in the port's debug_led() function, in a completely different way, that's why I asked.

Logged

waterwingz

12138

Re: usb_remote_status_led()

« Reply #219 on: 03 / July / 2015, 19:41:31 »

Quote from: srsa_4c on 03 / July / 2015, 19:36:00

Quote from: waterwingz on 03 / July / 2015, 18:50:40
Probably a better fit here : USB Remote Switch in CHDK - version 2 implementation thread ?
Thanks.
Can a mod move these posts please?

reyalp should be along shortly ..

Quote

Quote
So we probably need to move the function to the lib.c or kbd.c file in each camera's platform directory?
Or we could do it with macros, so the code can stay thumb.

I'm easy either way. Not sure how we figure out which ports need fixing though? All DIGIC5s?

Quote

Thanks for checking. The same LED address is used in the port's debug_led() function, in a completely different way, that's why I asked.

I noticed that but didn't dig deep enough to find something that actually used debug_led( ). The camera_set_led( ) function is similiar and IIRC used by the script engines for set_led( ) so that should tell us. I can try a short Lua script when I get a spare minute.

Logged

Ported : A1200 SD940 G10 Powershot N G16