Some issues specific to the iOS platform #14240
Comments
|
I cannot jailbreak my iOS device. If you know a reliable way of detecting jailbreaks, please let me know! Hm what, does that entitlement really enabled jit on any iOS version? or only any iOS version with jailbreak? |
If you are using A11 or earlier device, use Checkra1n (https://checkra.in) |
These two tools use different methods to jailbreak the device. If you need help about specific tool, please tell me. |
|
Well, my device is an iPhone 12 on iOS 14.4. So no possible paths right now, and I don't really want to jailbreak, I want a mainstream configuration so that I'll experience what most users will. Again, detecting jailbreaks is key. I really want to disable the JIT for non-jailbroken 14.4 and higher users since otherwise it's an absolutely awful user experience (the app disappears when you try to start a game). |
|
Regarding the compilation problem, haven't seen that. What I do is simply ./b.sh --ios-xcode , then I open the generated xcode project, set up autosigning and run. Please let me know the command line that errored like that. |
|
Well, how about that sbingner@73bf609 |
|
See my latest post above |
|
I don't see how that sbingner commit helps at all in detecting jailbreaks |
|
if (get_debugged() || iOS.version < 14.4)
|
|
in that case get_debugged is severely misnamed. It seems to be more like try_to_fool_ios_into_thinking_we_are_debugged_if_were_not() , returning true if either debugged or it got fooled, and there'd then be no need to also check the version, if its return value is accurate? |
|
|
Back to the compilation issue. How did you generate the xcode project? Does it help to just wipe the build-ios folder and start again? Did you update submodules? |
I think it should be like this？ |
./b.sh --ios-xcode; yes; yes |
This contains a warning and an error. Because the -include parameter is used twice, a warning is thrown: the second -include parameter will be ignored; and the error is that the value file of the second -include does not exist, so Throws an error. |
In fact, Apple's attitude towards whether applications should be allowed to enable jit is vague and changeable. It is very unreliable to judge whether an unjailbroken device can enable jit based on version checking, so it may be necessary to use other methods to check. But anyway, if get_debugged() returns true, then jit should always be available. |
|
Digression: @hrydgard Did you keep an old device you used before? checkra1n jailbreak only cares about the device model, regardless of the iOS version, because it uses hardware exploit for jailbreaking. |
|
The old device is an ipad that runs iOS 12 and no later. I guess that could be useful for jailbreak testing. |
|
if it's not allowed for |
|
I didn't even know we were using pch files at all on Apple. |
|
Did you run Not sure if something would be different with Xcode. We build every commit on a macOS container for iOS, but not through Xcode: https://github.com/hrydgard/ppsspp/runs/2003644190 It also has the "not first include" warning, but it's using cmake_pch_arm64.hxx. That's why I suspect your submodule is out of date. -[Unknown] |
Yes |
I noticed you are using Xcode12.4 on Github Action to build PPSSPP. That's interesting, because It will failed at running |
|
The behavior of xcode clean build is basically the same as the behavior of directly using xcode to running install on the device after using cmake to generate the xcode project. |
|
The effect of directly using gcc(clang) to compile is really good, and there is almost no difference from using xcode to compile. The only difference is that libMoltenVK.dylib will not appear in PPSSPP.app/Framework, but I think this is not a problem now |
|
Hm, https://www.viva64.com/en/b/0719/ - maybe this is affected by cmake version? Note that we're currently, on GitHub Actions, not generating an xcodeproj and not using xcodebuild, we're using the regular Makefiles generator. https://gitlab.kitware.com/cmake/cmake/-/issues/21825 Lines 308 to 313 in 45628cd I guess this is causing the duplicate include. Does commenting it out help anything? Probably won't. -[Unknown] |
|
Okay, now there are new problems. When the window shown likes in the figure appears, I can no longer close the window by clicking on the blank area around it. . . |
|
Hm, that's typical of a bug that's hard to notice on other platforms because for example Android always has a back button which will close it, while iPhone has no such thing. That will need fixing indeed. By the way, commenting out that line fixed it? Should also note that I am only testing with the very latest XCode. See no reason to use an older one, except maybe supporting very old iPhones. |
Not really, Apple does not value forward compatibility and encourages users to use the latest system. Apple even changed the abi of the arm64e chip on iOS. But since ppsspp now only build two kinks of slice armv7 and arm64 on iOS, so it doesn't matter for now. |
And yes it seems fixed. |
|
I guess I'll just remove that line then. I'll also attempt your suggested JIT detection method. |
Also add an escape route from games list settings without a back button. See #14240
|
I merged the suggested changes, and did a workaround for now for the click-outside issue (simply added a Back button at the end of the list). |
Disabling this line directly on iOS may have unexpected side effects. Now I cannot use Vulkan in the rendering engine (although this option does not actually work now), even though I have put libMoltenVK.dylib in the Frameworks directory. After re-adding this line and re-compile it will appear. |
|
For MSVC and Android via mk (which is what GitHub Actions does), I don't think we're force including that file. So I feel like we should fix any places that expect it to be included but don't explicitly include it. That's what its associated comment suggests was the plan anyway. -[Unknown] |
In the past, when you click the space around the window, you can close it directly. I think this is user-friendly. Now you need to scroll down to the bottom to find the close button, or select the current option repeatedly. . . |
|
Yes I intend to fix that properly, I was just not in the mood for a debug session. |
|
Is that affecting settings (where there are pop ups) too? I guess it must be related to the multitouch change then? Seems to still work elsewhere. -[Unknown] |
|
Probably. I'll check tonight. At least most settings popups are choosers where you can close by choosing a value, this doesn't work in the gamelist settings. |
That affecting settings elsewhere too. |
Status update: This bug seems to be limited to the iOS platform. On Windows, pop ups can still be closed by clicking the surrounding area as before. |
|
Well, I think #14240 (comment) should be fix it as soon as possible first and revent changes of #14240 (comment), after all, this really affects the experience of iOS users. |
The dialog code checks for touch.id != 0 to decide whether to close. Not sure if really necessary, but keeping it and just changing the IDs.
Change pointer ID allocation on iOS. Fixes part of #14240
|
#14387 should have fixed the dialog closing issue. |
Can confirm it fixed, and I think should also revert https://github.com/hrydgard/ppsspp/pull/14241/files#diff-a6de6710af502a186f9da920ff91217be542465ab7c9c4d2e95ab474d1482a20R1570. |
It seems that this link took me to strange places. . . So attach the picture: |
|
Yeah, you're right - it's not really necessary. |
|
Should we close this issue now? -[Unknown] |
|
okey |
Okay, this time I don’t want to follow the issues creation template because it may be messy, I’m here to write some thoughts about ppsspp.
I haven't paid attention to the update of ppsspp for a while, so I am going to clone the latest ppsspp and compile it for iOS. Unfortunately this time I encountered a compilation problem:
So I am going to take a look at the previous few commits to check if I can find some problems. Well I didn't find where the problem was, but I saw this:
bd7b283
#14196
Well, I think your judgment on whether jit is available is too rough. On jailbroken devices, jit should be enabled anyway. I saw this comment:
bd7b283#diff-0312b55b63103e2cbda96962d041c8bff0b444adf868ed954dda986f576b329bR220
I haven't got a deep understanding of the relevant code, but maybe we should find some other methods, (for example, is cs_debugger enabled?) to achieve this.
In addition, from here, I feel that @hrydgard himself does not seem to use a jailbroken device. Well, this may explain why the process of bringing vulkan to iOS has progressed so hard. But actually jailbreaking the device can avoid a lot of troubles in application installation and debugging. In particular, you can use checkra1n (checkra.in) to jailbreak on A11 and below devices, or use unc0ver (unc0ver.dev) to get jailbreak in any system below iOS 14.3 and it will not be difficult to achieve this for now.
Use this entitlement file(https://github.com/Halo-Michael/ppsspp-builder/blob/master/ent.xml) to allow ppsspp to enable jit on any iOS version and escape the sandbox.
Okay, that’s what I probably want to say, thanks for your work, and wish you luck.
The text was updated successfully, but these errors were encountered: