Using .cfg files

[RodrigoPrestes]

I would like to configure some settings (like integer scaling, save location) but those are not defined on the addon settings.xml.
RetroArch have a cfg file where it stores all configurations, and we also have the possibility of creating a override, for example per core.

Is there any way to use a cfg file on the addon?
Or to configure options in some other way?

[garbear]

Kodi has a Settings window, which will apply to all add-ons, is that what you mean? If a setting is missing, it can be requested.

[RodrigoPrestes]

I believe the addon only has one setting.
I would like to request some options, looking at RetroArch's config file they are:

• video_scale_integer
• savestate_auto_save
• savestate_auto_load
• savefile_directory
• savestate_directory

Let me know if those should be a new issue, or even multiple issues.

[garbear]

I believe Kodi already has integer scaling: xbmc/xbmc#18194

As for the others, a good spot for new game settings would be Settings -> Games -> General. However, we should be aware of "settings proliferation" and rely on sensible defaults where possible. Currently, Kodi uses the "userdata" folder for all config and writable files. We would have to weigh the advantage of user-configurable save directories (especially when Kodi already has an existing directory structure) against settings proliferation.

Autosave/autoload toggles are valid requests. What would the labels be in the settings UI?

[RodrigoPrestes]

About integer scaling

Will test it!
Looking at the PR it should only affect games so this might do it.

---

About save locations

My problem with saves as they are now is that they use a single directory under userdata for saves of all cores.
It's very common to have it in other places like the RetroArch defaults on the ROM directory or by core like Onion OS (I could be mistaken but I believe RetroPie also works by system as well).

However, I don't want to break any established rule by Kodi, so let me know if this is something one would had to compromise when using the addon.

---

About auto save states labels

RetroArch uses the label "Auto Save State" and "Auto Load State".

[RodrigoPrestes]

About integer scaling

Could not test existing option, it was hidden at some point: linux.xml#L218

---

About save locations

What if the addon had a setting to save by system/core and then implement by just appending to the current save location?
That way we comply with Kodi rules by staying on the profile directory while still having the saves organized on separate folders.

---

About auto save states

Haven't tested this but it appears Kodi already have (at least a setting for) this: settings.xml#L2671

[smp79]

I believe Kodi already has integer scaling: xbmc/xbmc#18194

It was disabled by xbmc/xbmc@7f36caf and never enabled again. Any particular reason for this? The needed linux changes were merged ages ago.

[garbear]

Any particular reason for this?

Honestly I don't remember. I understood it worked at the time. Try re-enabling it, and we'll enable in core if you can get it to work.

[smp79]

I re-enabled it, trying with current LibreELEC master on Intel Tiger Lake. Selected 'Nearest neighbour' + 'Original size' +
'Display hardware scaling fitler' = on. Unfortunately only getting a black screen. But it definitely does something, according to drm.debug log:

Jan 17 08:25:13 LibreELEC kernel: i915 0000:00:02.0: [drm:skl_update_scaler] scaler_user index 0.1: staged scaling request for 256x224->2304x2016 scaler_users = 0x2
Jan 17 08:25:13 LibreELEC kernel: i915 0000:00:02.0: [drm:intel_plane_atomic_check_with_state] [CRTC:100:pipe A] with [PLANE:41:plane 2A] visible 1 -> 1, off 0, on 0, ms 0
Jan 17 08:25:13 LibreELEC kernel: i915 0000:00:02.0: [drm:intel_atomic_get_global_obj_state] Added new global object 0000000013fe3722 state 000000002a1023dd to 00000000703384e9
Jan 17 08:25:13 LibreELEC kernel: i915 0000:00:02.0: [drm:intel_atomic_get_global_obj_state] Added new global object 00000000574552ff state 0000000081d39fe6 to 00000000703384e9
Jan 17 08:25:13 LibreELEC kernel: i915 0000:00:02.0: [drm:intel_atomic_setup_scalers] Attached scaler id 0.0 to PLANE:41
Jan 17 08:25:13 LibreELEC kernel: i915 0000:00:02.0: [drm:drm_atomic_nonblocking_commit] committing 00000000703384e9 nonblocking
Jan 17 08:25:13 LibreELEC kernel: i915 0000:00:02.0: [drm:drm_atomic_state_init] Allocated atomic state 0000000000280f30
Jan 17 08:25:13 LibreELEC kernel: i915 0000:00:02.0: [drm:drm_atomic_state_default_clear] Clearing atomic state 00000000703384e9
Jan 17 08:25:13 LibreELEC kernel: i915 0000:00:02.0: [drm:drm_atomic_get_plane_state] Added [PLANE:41:plane 2A] 000000006a961258 state to 0000000000280f30
Jan 17 08:25:13 LibreELEC kernel: i915 0000:00:02.0: [drm:drm_atomic_get_crtc_state] Added [CRTC:100:pipe A] 000000005cd7d6fe state to 0000000000280f30
Jan 17 08:25:13 LibreELEC kernel: i915 0000:00:02.0: [drm:__drm_atomic_state_free] Freeing atomic state 00000000703384e9
Jan 17 08:25:13 LibreELEC kernel: i915 0000:00:02.0: [drm:drm_atomic_set_fb_for_plane] Set [FB:340] for [PLANE:41:plane 2A] state 000000006a961258
Jan 17 08:25:13 LibreELEC kernel: i915 0000:00:02.0: [drm:drm_atomic_check_only] checking 0000000000280f30

[garbear]

Well, you got a log showing the problem. That should let us fix it. I'm not an integer scaling expert, but you have a PR that added a feature, a feature that is broken, I think that's the place to start.