Set EVSHIM_BASE_PATH in the host process so gamepad shm is not hardcoded to app.gamenative - #1818
Open
faux123 wants to merge 1 commit into
Open
Set EVSHIM_BASE_PATH in the host process so gamepad shm is not hardcoded to app.gamenative#1818faux123 wants to merge 1 commit into
faux123 wants to merge 1 commit into
Conversation
…ardcoded to app.gamenative
libevshim.so builds its gamepad shared-memory directory in a C constructor
(initialize_all_pads, __attribute__((constructor))) that runs at library load,
from getenv("EVSHIM_BASE_PATH") and otherwise a hardcoded
"/data/data/app.gamenative/files". EVSHIM_BASE_PATH is exported to the guest
(wine) process but not to the host process that loads libevshim and calls
notifyStateChanged. On any build whose applicationId is not exactly
"app.gamenative" -- the release-gold flavor (app.gamenative.gold) or any
fork/rename -- the host's shm setup targets the stock app's data dir, which it
cannot create or mmap, so host shm[i] is null, notifyStateChanged logs
"missing shm for slot=N", and no controller input reaches any game.
Set EVSHIM_BASE_PATH = filesDir in PluviaApp.onCreate, before any evshim load.
Package-agnostic: on the stock package it equals the hardcoded fallback, so
there is no behavior change; on renamed/gold builds the host now uses the
correct data dir. Verified on a renamed build (applicationId app.gamenative.mali,
RK3588/Mali-G610): before, continuous "missing shm for slot=0" and no pad input;
after, the host mmaps all player slots and controller input works in-game.
Contributor
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthrough
ChangesEVSHIM path setup
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to This is a localized initialization change that sets the shared-memory base path for renamed builds; no actionable merge-blocking risk remains beyond normal checks and review. Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment Warning |
faux123
added a commit
to faux123/GameNative-Mali
that referenced
this pull request
Aug 15, 2026
…VK-Sarek ceiling, software BCn, DX12=no, wrapper/box64 baked-in, UE4->D3D11 default, evshim controller fix + PR utkarshdalal#1818) Corrects the PRD premise: rebuilding the wrapper does not unlock modern DXVK on Mali; the missing core Vulkan features are silicon limits, so the DXVK 1.x Sarek line is the ceiling. Claude-Session: https://claude.ai/code/session_01JZcRjgSzRJdaCCWKnBk2mE
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
2 issues found across 1 file
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="app/src/main/java/app/gamenative/PluviaApp.kt">
<violation number="1" location="app/src/main/java/app/gamenative/PluviaApp.kt:59">
P3: The added comment states that EVSHIM_BASE_PATH is set for the guest (wine) process in BionicProgramLauncherComponent, but the codebase never sets this variable for the guest (only EVSHIM_WINE and EVSHIM_SHM_NAME are there). The fix relies on the guest inheriting the host process's environment, not on BionicProgramLauncherComponent. Reword the comment so it doesn't assert a mechanism that isn't in the code.</violation>
<violation number="2" location="app/src/main/java/app/gamenative/PluviaApp.kt:68">
P1: On renamed builds, the guest still resolves the shared-memory directory to the hardcoded `app.gamenative` path. This host-only setting makes the host and Java sides use `filesDir` while Wine's evshim uses the fallback, so controller input remains disconnected; add the same `EVSHIM_BASE_PATH` value to the explicit guest environment before launching Wine.</violation>
</file>
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
| // resolves to the same path the hardcoded fallback uses, so there is no | ||
| // behavior change there. | ||
| try { | ||
| android.system.Os.setenv("EVSHIM_BASE_PATH", filesDir.absolutePath, true) |
Contributor
There was a problem hiding this comment.
P1: On renamed builds, the guest still resolves the shared-memory directory to the hardcoded app.gamenative path. This host-only setting makes the host and Java sides use filesDir while Wine's evshim uses the fallback, so controller input remains disconnected; add the same EVSHIM_BASE_PATH value to the explicit guest environment before launching Wine.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At app/src/main/java/app/gamenative/PluviaApp.kt, line 68:
<comment>On renamed builds, the guest still resolves the shared-memory directory to the hardcoded `app.gamenative` path. This host-only setting makes the host and Java sides use `filesDir` while Wine's evshim uses the fallback, so controller input remains disconnected; add the same `EVSHIM_BASE_PATH` value to the explicit guest environment before launching Wine.</comment>
<file context>
@@ -53,6 +53,23 @@ class PluviaApp : SplitCompatApplication() {
+ // resolves to the same path the hardcoded fallback uses, so there is no
+ // behavior change there.
+ try {
+ android.system.Os.setenv("EVSHIM_BASE_PATH", filesDir.absolutePath, true)
+ } catch (e: Exception) {
+ android.util.Log.w("PluviaApp", "Failed to set EVSHIM_BASE_PATH for host process", e)
</file context>
Comment on lines
+59
to
+62
| // That env var is set for the guest (wine) process but not for THIS host | ||
| // process, so on any build whose applicationId is not exactly | ||
| // "app.gamenative" (e.g. the release-gold flavor -> app.gamenative.gold, or | ||
| // a fork/rename) the host builds the pad shm under the wrong app's data |
Contributor
There was a problem hiding this comment.
P3: The added comment states that EVSHIM_BASE_PATH is set for the guest (wine) process in BionicProgramLauncherComponent, but the codebase never sets this variable for the guest (only EVSHIM_WINE and EVSHIM_SHM_NAME are there). The fix relies on the guest inheriting the host process's environment, not on BionicProgramLauncherComponent. Reword the comment so it doesn't assert a mechanism that isn't in the code.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At app/src/main/java/app/gamenative/PluviaApp.kt, line 59:
<comment>The added comment states that EVSHIM_BASE_PATH is set for the guest (wine) process in BionicProgramLauncherComponent, but the codebase never sets this variable for the guest (only EVSHIM_WINE and EVSHIM_SHM_NAME are there). The fix relies on the guest inheriting the host process's environment, not on BionicProgramLauncherComponent. Reword the comment so it doesn't assert a mechanism that isn't in the code.</comment>
<file context>
@@ -53,6 +53,23 @@ class PluviaApp : SplitCompatApplication() {
+ // libevshim.so sets up its gamepad shared memory in a C constructor at
+ // library load, deriving the directory from getenv("EVSHIM_BASE_PATH") and
+ // otherwise falling back to a hardcoded "/data/data/app.gamenative/files".
+ // That env var is set for the guest (wine) process but not for THIS host
+ // process, so on any build whose applicationId is not exactly
+ // "app.gamenative" (e.g. the release-gold flavor -> app.gamenative.gold, or
</file context>
Suggested change
| // That env var is set for the guest (wine) process but not for THIS host | |
| // process, so on any build whose applicationId is not exactly | |
| // "app.gamenative" (e.g. the release-gold flavor -> app.gamenative.gold, or | |
| // a fork/rename) the host builds the pad shm under the wrong app's data | |
| // libevshim.so never sets this var for the guest; the guest (wine) | |
| // process is forked from this host and inherits its environment, but the | |
| // host process that loads libevshim and calls notifyStateChanged has no | |
| // EVSHIM_BASE_PATH of its own, so it falls back to the hardcoded path. |
Owner
|
is this not included in #1810 ? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
On any build whose
applicationIdis not exactlyapp.gamenative, no controller input reaches any game. This includes this repo's ownrelease-goldflavor (app.gamenative.gold) and any fork/rename.Root cause
libevshim.sosets up its gamepad shared memory in a C constructor (initialize_all_pads,__attribute__((constructor))) that runs at library load.build_gamepad_dir()derives the directory fromgetenv("EVSHIM_BASE_PATH"), otherwise falling back to a hardcoded"/data/data/app.gamenative/files".EVSHIM_BASE_PATHis exported into the guest (wine) process env inBionicProgramLauncherComponent, but it is not set in the host process that loadslibevshimand callsnotifyStateChanged. On the stock package the host'sgetenvis unset so it uses the hardcoded fallback, which happens to be correct. On a renamed package that fallback points at the wrong app's data dir, which the app cannot create ormmap, so:shm[i]is null;evshim: notifyStateChanged missing shm for slot=0;WinHandler) writes pad state togetFilesDir()/gamepad_shm(correct dir) while native reads the stock dir, so they never meet and no game sees the pad.Stock
app.gamenativeis not affected. Therelease-goldbuild type (applicationIdSuffix = ".gold") is.Fix
Set
EVSHIM_BASE_PATH = filesDirinPluviaApp.onCreate, before any evshim load. Package-agnostic: on stock it equals the hardcoded fallback (no behavior change); on renamed/gold builds the host now uses the correct data dir.Verification
On a renamed build (
applicationId app.gamenative.mali, RK3588 / Mali-G610): before, continuous "missing shm for slot=0" and a dead controller; after, the host mmaps all player slots (java P0-P3 mmap'd), zero "missing shm" errors, and controller input works in-game.(Issues are disabled on the repo, so filing this as a PR with the full report.)
Summary by cubic
Ensure host process sets the gamepad SHM base path so controllers work on renamed builds. Previously the host defaulted to
/data/data/app.gamenative/fileswhenEVSHIM_BASE_PATHwas unset, breaking input on builds whoseapplicationIdisn’tapp.gamenative; now it sets the env var tofilesDirat startup with no behavior change on stock.Review notes
EVSHIM_BASE_PATHviaandroid.system.Os.setenv(filesDir.absolutePath, overwrite=true)inPluviaApp.onCreatebefore any evshim load.app.gamenativethis matches the fallback path; failures only log a warning.Written for commit 72753e4. Summary will update on new commits.
Summary by CodeRabbit