Conversation
…tion pointers successfully get thunked for ARM64EC and NVDA can correctly start on ARM64 again.
… Loader processes to start, to be more accurate and readable. The logic now groups by specific OS archetecture, making it very clear which ones apply to which OS archetecture. This rewrite also ensures that particular checks are no longer skipped if an earlier check succeeded. E.g. previously ARM64 remote loader was never started on ARM64 if NVDA was compiled as AMD64.
There was a problem hiding this comment.
Pull Request Overview
This PR fixes NVDA functionality on ARM64 devices by addressing compilation and architecture-specific loading issues. The changes enable AMD64 builds of NVDA to run correctly on ARM64 devices like Copilot PC by resolving thunking issues between ARM64EC and AMD64 code.
- Converts nvdaControllerInternal from C to C++ compilation to resolve ARM64EC thunking issues
- Refactors remote loader initialization logic to properly handle all architecture combinations
- Ensures ARM64 remote loader is started correctly when NVDA is compiled as AMD64
Reviewed Changes
Copilot reviewed 2 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| source/NVDAHelper/init.py | Refactored remote loader initialization logic with clearer architecture-specific grouping |
| nvdaHelper/local/sconscript | Changed nvdaControllerInternal compilation from C to C++ |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
|
@LeonarddeR mentioning you here so you are aware of this pr, as you did the ARM64EC stuff I believe and may have been running into some issues with running Github actions checks on ARM64 images? |
|
Thanks for testing this. I haven't been able to repro this issue on my ARm64 vm. Hopefully we can expand testing to arm64 soon. |
Link to issue number:
None
Summary of the issue:
AMD64 builds of NvDA are not currently functioning on ARM64 devices such as Copilot PC.
NVDA seems to crash when initializing NVDAHelper.
The crash seems to occur when trying to set the first nvdaControllerInternal function pointer for nvdaHelperLocal.dll in NVDAHelper.initialize. Yet all the previous function pointers for nvdaController are set correctly.
With the merging of pr #18570, for performance improvements NVDA loads ARM64EC dlls for AMD64 processes when running on ARM64. If NVDA itself is build as AMD64, this will include nvdahelperLocal.dll. There may be some kind of ARM64EC to AMD64 thunking issue going on here between nvdaHelperLocal.dll and Python ctypes callbacks. Though only specific to nvdaControllerInternal, not nvdaController.
Interestingly, nvdaController is c++, but nvdaControllerInternal is only c. Perhaps the compiler / headers only manage thunking for c++. Noting that with ARM64EC, I believe functions may get multiple entry points depending on whether being called with ARM64 or AMD64 code to appropriately handle arguments.
Description of user facing changes:
AMD64 builds of NVDA will run correctly on ARM64 devices such as Copilot PC.
Description of developer facing changes:
Description of development approach:
Testing strategy:
Known issues with pull request:
None known.
Code Review Checklist: