Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - SztupY

#1
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
#2
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.

Options:

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.
#3
Had the same issue with GCC 4.9.3 (autoexec.bin builds fine, but cannot deploy to camera: LED will remain flashing, and you need to remove the battery). Reverted back to GCC 4.8.4 and the build works fine
#4
I know myself enough to know that whatewer I do wouldn't end up good in a crowdfounded environment, as I usually cannot commit to pet projects on a long-term (unless it's my actual day job)

That said, I did revive my old dev VM, and started looking at all the changes ML received in the last 1.5 years so I could resume some work on ML controller. As with the last release I still plan on release all PC code as AGLP, while keeping the android one closed until it's stable enough. After that it's going to be AGPL as well.
#5
I haven't forgotten about the project, but I have to completely revisit the ML code, which has changed a lot since ML controller was built ages ago, and that takes a lot of time.
#6
Forum and Website / Re: OpenID accounts are locked out
November 16, 2012, 08:00:51 PM
Well, Google's OpenID usually breaks a lot of client implementations so that's no surprise. It doesn't support delegating either. Facebook's a bit better, but myOpenid is the one that usually works everywhere.
#7
Forum and Website / Re: OpenID accounts are locked out
November 16, 2012, 07:44:02 PM
It's fine again, thanks!