detect current platform by reading "/system/build.prop" (android or libh...

[krnlyng]

...ybris powered devices) and set default values for that platform (currently only the Jolla Phone)

this is my second attempt at getting the default values for my phone into upstream, i hope this method is better than the previous (silly) attempt

[ricrpi]

The checking of Glide64Mk2 configuration section will throw errors to users that never use the glide plugin. (E.g. on Raspberry Pi).

Given littleguy77's comments on your previous commit, maybe just provide a mupen64plus.cfg in your repo, for your target platform.

It would however be handy if one could set default plugin's names via makefile input parameters which would help with half of your changes but wouldn't bloat the code.

[littleguy77]

maybe just provide a mupen64plus.cfg in your repo, for your target platform.

Agreed. This is a lot of hard-coding for something that is easily addressed in a platform specific config file. This is exactly why the config files exist, and why these are only default values. They're meant to be overridden by the user or downstream front-ends.

[Narann]

Those are 11 copy pasted lines. It's hard to maintain.

[Narann]

First question is why would you do this?

This look like a very intrusive commit for a very specific hardware that seems to only change default values. I don't think it should be handle like this. mupen64plus.cfg file is here for this. I know mobile has some limitation (@twinaphex discussed about file system on mobile device and why it can be a problem) but please explain why mupen64plus.cfg is a problem and what we could do to fix this.

It would however be handy if one could set default plugin's names via makefile input parameters.

I guess there is multiple ways to handle this. While the makefile solution shouldn't be too hard to do I really wonder why use the --gfx argument in the front end is not enough.

I've open the issue section for mupen64plus-ui-console repo to discuss this. @ricrpi, feel free to create a ticket exposing the problem. Anyone having a problem with the current config file is welcome to provide feedbacks.

I will close this PR, @richard42, feel free to reopen it if you consider it as relevant.

[krnlyng]

@Narann i just wanted to do this, because without these settings mupen64plus renders garbage on my phone. i wanted users to have a working solution when first starting mupen64plus instead of having them dig around in mupen64plus.cfg (because there might be users not so versatile in command line tools) also i wanted to avoid writing a new front-end just for that one platform. Another thing i thought about was, would it be reasonable to have a mupen64plus.cfg somewhere in $PREFIX/share/mupen64plus/platform which gets copied over to ~/.config/mupen64plus on first startup of mupen64plus?

[ricrpi]

tbh I don't see a problem/issue, only a 'potential' slight improvement in that users would not have to change the default plugin-names on first startup or if they delete a 'bad' .cfg file. Users will probably still need to modify other parameters though.

I have taken the approach of providing a script to download/install plugins (official and forked) to build a working system on my target platform. If defaults were such a problem for users then I would either start mupen64plus with the appropriate command line arguments in the build script (using -testshots to auto close it), provide an example .cfg file (current approach) or fork the appropriate repo, add the changes I require and configure the build script to use that repo instead.

If someone was to modify the makefiles so that a build script could pass in default plugin parameter values then I would make use of this but I feel this is a very low priority.

[Narann]

i wanted to avoid writing a new front-end just for that one platform.

But this PR add so much code which almost focus on one platform. I think it shouldn't be handle like this.

Which OS and hardware are we talking about?

@krnlyng I like the solution you provide. The idea would be:

• Look for the user value (~/.config/mupen64plus/mupen64plus.cfg).
• If it not exists, look for the platform specific value ($PREFIX/share/mupen64plus/platform)
• If it not exists, use the default value.

What structure would you see inside $PREFIX/share/mupen64plus/platform?

It add a level of indirection and add a file to check but it seems a fair trade of.

What do you think of it @richard42?

Notice a ticket has been created for this.

[richard42]

I think the config system is already complex enough (especially with the InputAutoCfg.ini), that I would like to avoid increasing the complexity by adding another fallback config file.

Is the ui-console front-end used on Android devices? I thought Mupen64Plus-ae had its own custom front-end application.

[littleguy77]

mupen64plus-ae has a java front-end that wraps ui-console. The java front-end is just a glorified settings manager, that writes mupen64plus.cfg, then launches ui-console. There are only a few lines of diff between upstream mupen64plus-ui-console and android edition's fork:
https://github.com/mupen64plus-ae/mupen64plus-ui-console/compare/mupen64plus:master...master

mupen64plus-ae's java front-end provides the functionality embedded in this PR, with much greater granularity. In other words, this PR is not needed for mupen64plus-ae.

[krnlyng]

The device i am trying to use mupen64plus on, is a linux device but not android, and i wanted to use the upstream front-end there. (it just uses some parts of an android system, thats why /system/build.prop exists there)