obsproject
libobs: Add Windows X64 Emulation on ARM64 and move Rosetta Detection
Description
Adds a check that detects if OBS is running on Windows ARM64 emulation and logs the result.
Motivation and Context
https://github.com/obsproject/obs-studio/pull/5644
How Has This Been Tested?
Running X64 OBS Studio gives the following log:
Windows:
23:10:09.304: CPU Name: Microsoft SQ1 @ 3.0 GHz
23:10:09.305: CPU Speed: 1670MHz
23:10:09.305: Physical Cores: 8, Logical Cores: 8
23:10:09.305: Physical Memory: 7718MB Total, 3202MB Free
23:10:09.305: Windows Version: 10.0 Build 22538 (release: 2009; revision: 1010; ARM 64-bit)
23:10:09.305: Windows ARM64: Running with X64 Emulation
23:10:09.306: Running as administrator: false
23:10:09.307: Aero is Enabled (Aero is always on for windows 8 and above)
23:10:09.307: Windows 10 Gaming Features:
23:10:09.307: Game Bar: On
23:10:09.307: Game DVR: On
23:10:09.307: Game DVR Background Recording: Off
23:10:09.317: Current Date/Time: 2022-01-25, 23:10:09
23:10:09.317: Browser Hardware Acceleration: false
23:10:09.317: Qt Version: 5.15.2 (runtime), 5.15.2 (compiled)
23:10:09.317: Portable mode: false
23:10:10.338: OBS 27.2.0-beta4-23-g026987a2b (64-bit, windows)
macOS:
17:58:05.833: CPU Name: Apple M1 Pro
17:58:05.833: CPU Speed: 2400MHz
17:58:05.833: Physical Cores: 10, Logical Cores: 10
17:58:05.833: Physical Memory: 16384MB Total
17:58:05.833: OS Name: macOS
17:58:05.833: OS Version: Version 12.1 (Build 21C52)
17:58:05.833: Rosetta translation used: true
17:58:05.833: Kernel Version: 21.2.0
17:58:05.842: hotkeys-cocoa: Getting keyboard keys failed
17:58:05.842: hotkeys-cocoa: Using layout 'com.apple.keylayout.Dvorak'
17:58:05.843: Current Date/Time: 2022-01-26, 17:58:05
17:58:05.843: Browser Hardware Acceleration: true
17:58:05.843: Qt Version: 5.15.2 (runtime), 5.15.2 (compiled)
17:58:05.843: Portable mode: false
17:58:05.965: OBS 27.2.0-beta4-23-g026987a2b (mac)
Types of changes
- New feature (non-breaking change which adds functionality)
Checklist:
- [x] My code has been run through clang-format.
- [x] I have read the contributing document.
- [x] My code is not on the master branch.
- [x] The code has been tested.
- [x] All commit messages are properly formatted and commits squashed where appropriate.
- [x] I have included updates to all appropriate documentation.
To be clear, this will print if the user is running the x86_64 binary on Windows ARM64, yes?
To be clear, this will print if the user is running the x86_64 binary on Windows ARM64, yes?
Yes.
This should be merged along with https://github.com/obsproject/loganalyzer/pull/91 .
If we ever want to add a dialog like originally proposed in #5644, this needs some kind of return value to the UI. I thought that’s something we still wanted once the native versions are released officially, since we don’t want to do universal packages, right?
You are right, I forgot the need to do the dialogue, in that case we do need something back from that function.
How about we take the detection logic out of log_emulation_status(), put it into a function like get_emulation_status()? This way we can avoid duplicating things.
But we also need to figure out where to put get_emulation_status() and should it be renamed to something else.
Libobs' util/platform.h header sounds like the right place to me (though I'm not really sure). Perhaps something like bool os_is_emulated() or bool os_get_emulation_status() (keep in mind this has to be implemented by every OS, but everything besides macOS and Windows could just return false)
This may not yet be relevant (although I suspect somebody will inevitably try it), but can we also detect https://github.com/ptitSeb/box86 emulation on *nix?
We can, it's as simple as adding the implementation to bool os_get_emulation_status(void)in libobs/util/platform-nix.c.
You can propose another PR with the said implementation either against with my forked repo or here in the upstream.
Thanks for proofreading, but I can't really do much about it right now, sorry for that. I'm extremely busy with schoolwork these days. I'll be back by approximately next month.
If I remember correctly, except the wording and typo issue, this PR is logically ready to go.
My other questions are still unresolved and this has merge conflicts. Aren't the macOS changes in the first commit here the same as the first commit in https://github.com/obsproject/obs-studio/pull/6622?
@gxalpha did the original Rosetta detection, but it was implemented in the UI layer instead of libobs.
They asked me to do it only for macOS, and that's what I did in #6622. In fact, #6622 is stripped from this PR. Because of this. merge conflicts are normal and expected.
One of the commit in #6622 reverts the original detection and the other commit re-implemented the Rosetta detection.
~~#6622 have some minor importance changes (e.g. ""an X64 binary") which is not yet backported to this PR. I'll do that once I got a chance.~~ It's already done.
@gxalpha did the original Rosetta detection, but it was implemented in the UI layer instead of
libobs.They asked me to do it only for macOS, and that's what I did in #6622. In fact, #6622 is stripped from this PR. Because of this. merge conflicts are normal and expected.
One of the commit in #6622 reverts the original detection and the other commit re-implemented the Rosetta detection.
~#6622 have some minor importance changes (e.g. ""an X64 binary") which is not yet backported to this PR. I'll do that once I got a chance.~ It's already done.
The first commits in each both modify:
- docs/sphinx/reference-libobs-util-platform.rst
- libobs/util/platform-cocoa.m
- libobs/util/platform-nix.c
- libobs/util/platform.h
with nearly identical changes. The main differences are:
- libobs/util/platform-windows.c
- the commit message
That's what I mean.
Okay, now it have 6 commits. The top 5 commits are related to logs, especially I did the log in libobs, not UI layer.
We'll see how it goes.