PTP changes and MLController support

Started by SztupY, June 16, 2015, 01:57:39 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.


So it looks like I'm going to have some more time again, and want to look at getting USB PTP support working again in the codebase, mainly so it can be used from within MLController (it was taken down from Play store for some weird reason, until I get it back again here is the source to build). But before I start on some (potentailly big) refactors in the codebase I would like to know what I should start on, that would hopefully result in the code getting merged in (and also made part of nightly / later stable builds)

My initial idea was, that as almost all important features of ML can be accessed from the ML menu system it would be wise to add some reflection support to the menu system, so each menu item can be checked and potentially the whole menu structure can be recreated outside of the app. My initial code (made some 3 years ago) basically just added a pre-generated ID value for all menu entries, so they can be addressed by ID later. The idea was that important menu entries (like setting ISO values, audio gain, etc.) could be set some specific IDs (that could be hard coded in clients), while others (like ones that are added by modules) will have some autogenerated ones, that could be discovered by reflection. Then some PTP actions were set up that could enumerate the menu system, and "click" on them via other PTP commands.

The advantage of this approach is that any changes in the menu system would be instantly reflected in the client apps, so they don't need to be synced  between ML and potential client apps. The drawback is that it is quite generic, so this would only be beneficial as a baseline for controlling ML features using PTP.

Some options I can think of:

1. Keep everything as is. Refer to menu items as either by name (which 1. might change, 2. can have duplicates), or their memory address (which is probably different across builds, and would make referencing a speicifc menu entry harder)
2. Re-add the initial ID code (see link above). This would just add a specific ID to each menu entry (autogenerated), so they can be addressed. Some important ML commands could actually get a pre-filled ID so it can be easily accessed by clients. This would only solve the issue of addressing the menu items by clients though, they still need a way to properly "click" it (modify it's settings).
3. Apart from doing step 2, also add additional reflection code to the menu items, that would return the min/max value, the available settings, etc. This would probably be a major work though, but would allow complete reflection over the menu from clients. Note that this reflection could also be used potentially by modules, lua scripts, etc. as well. Still this is potentally a big work.

The other issue is that it's not possible to add new PTP handlers from modules (at least 3 years ago when I tried it wasn't working). You can call the function that adds new ptp handlers after boot, and they do run, but they won't actually install the new handler, so it won't actually be available from USB clients. This is a problem as this generally means that (unless some workarounds are added) it is not possible for USB clients to just upload their server side PTP module, they need to be compiled into ML.


1. No modular PTP support. Have some basic PTP handlers with some basic commands and if a client needs a new one, it needs to create a pull request.
2. Modify the module loading code so it can load modules before the booting finishes, so the camer would still register it. This might be a big amount of work, and might still not work though.
3. Create some generic PTP commands, that would proxy requests through modules. Also have some basic commands (like uploading files, so clients could upload their latest module) I think this is the best option given the limitations.

I've created a pull request to store the initial changes I made, but I don't really want to work on major stuff unless it's general idea is pre-approved by the maintainers.


I prefer menus to be accessed by name (and, if there is ambiguity, by path). Why? I simply don't want to maintain menu IDs.

Currently, all submenus are registered as (hidden) top-level menus as well, so everything can be identified as (parent_name, menu_entry_name). For example, you can have say Zebras->Threshold and Peaking->Threshold without conflicts (but you can't have Zebras->Options->ABC and Peaking->Options->XYZ). To allow the second type of menus, we could reference a menu entry by full path, and also change the menu internals a bit.

Sure, menu names may change, but it's not something that happens often.

I'll let g3gg0 and maqs comment on the PTP issue, since I didn't really use it.


Cool, I'm happy with names given we can assure they won't clash (this might be a problem if modules / scripts can add their own entries). It also looks like the .min, .max and .select entries are all properly set up, I'll go over them and check if they can be called properly or not, and update the current PTP code to use them.

For the PTP part at the moment it is disabled in builds (from what I've seen CONFIG_PTP* is all set to nope), so probably not many people use it. It would be good to fix it to a point where it could be included in nightlies without fear of them decreasing stability




We were all waiting for you :)
I'm very happy.

I can't wait to try it!

Good work and good luck!

P.S. For every tests or something that I can help, don't hesitate to contact me.