Google Login not working on ARM

[Alexmitter]

Tried on multiple ARM devices, different Linux distros. The Google login stops at the spinning circle thing.

Using the package from flathub.

[3:14:1022/175016.510816:ERROR:cert_verify_proc_nss.cc(969)] CERT_PKIXVerifyCert for accounts.google.com failed err=-8172
[3:13:1022/175016.512410:ERROR:ssl_client_socket_impl.cc(941)] handshake failed; returned -1, SSL error code 1, net_error -202

[ChristopherHX]

different Linux distros? please be more explicit, unique name of every distro.
I know this applies to manjaro linux aarch64, which I don't use. (no multilib)
This could be worked around by adding an very insecure, ignore certificate prompt if this error happens.
Or injecting chromium certificates into the flatpak.

The used framework for the webview is hosted here https://github.com/flathub/io.qt.qtwebengine.BaseApp/tree/branch/5.14, might be an issue with this dependency

login works on raspbian armhf on Raspberry Pi2 after this patch flathub/io.mrarm.mcpelauncher#3
login works on ubuntu arm64 on Raspberry Pi4 8g with my unusable aarch64 experiment flathub/io.mrarm.mcpelauncher#6 (comment) (https://github.com/flathub/io.qt.qtwebengine.BaseApp/tree/branch/5.15)

[Alexmitter]

@ChristopherHX Sorry I wasn't more specific.
Device 1 is a Pinebook Pro where I was running Ubuntu 20.04, same issue, same log.
Device 2 is a Pinephone running Mobian, that currently tracks Debian Bullseye, same issue, same log.

I currently try to get it working on the Pinephone.

[ChristopherHX]

Oh, Pinebook Pro.
I heard the flatpak arm32 has too old gpu drivers or broken drivers for armhf.
Althought now you can build it for arm64 on your device so you might have luck to get it running. (src https://github.com/minecraft-linux/mcpelauncher-manifest/tree/ng)

please also test the arm64 flatpak build of the arm64 version flathub/io.mrarm.mcpelauncher#6.
Login worked with Ubuntu 20.04 arm64, so it may work for you too?
To see if I get the same issue with the armhf flatpak I have to install it first., neverthingless armhf is already deprecated by freedesktop and will stop getting updates
I'm testing changes to fix some big bugs of my last test.

[ChristopherHX]

The current aarch64 versions is almost working, except launching the GUI has a very high crashdump rate, but I have no idea why.
Also it seems to prefer x86_64 for some reasons.

[Alexmitter]

It is working now since the last update. Thanks to it I did successful run it on the phone: https://mastodon.social/@Alexmitter/105227771367681447

Thank you

[ChristopherHX]

If you want touchinput then the flatpak is the wrong version for you.
Try the AppImage instead https://github.com/ChristopherHX/linux-packaging-scripts/releases/download/ng.appimage/Minecraft_Bedrock_Launcher-arm_aarch64.0.0.617.AppImage

don't forget chmod +x ./Minecraft_Bedrock_Launcher-arm_aarch64.0.0.617.AppImage
Then ./Minecraft_Bedrock_Launcher-arm_aarch64.0.0.617.AppImage

Touchinput is almost working there (tested with an x86_64 tablet ubuntu 20.10 live)
unless you move your mouse over the screen or connects a gamepad

[Alexmitter]

@ChristopherHX thank you for the tip, I will try that.

[Alexmitter]

@ChristopherHX Sorry to ask, but why is touch input broken on the flatpak?

[ChristopherHX]

flatpak is configured to use glfw which lacks touch support.
The appimage uses eglut with touch support.
I saw yesterday that only eglut calls touch callbacks.
glfw still doesn't have any touchinput code or support it is an external project.

I have choosen glfw for the flatpak, because it doesn't depends on barly supported libraries on flatpak, might have changed recently and would work now.

[Alexmitter]

@ChristopherHX trying out the appimage right now, for a weird reason, zlib1g does not satisfy it, zlib1g-dev was needed for whatever reason. Otherwise it fails with "./Minecraft_Bedrock_Launcher-arm_aarch64.0.0.617.AppImage: error while loading shared libraries: libz.so: cannot open shared object file: No such file or directory"

Also, it seems the Qt UI is only compiled with the xcb platform, missing the wayland platform plugin in the appimage. The flatpak has it and it is quite needed for this purpose. Sadly it seems to run like dirt with Xorg, it also crashes constantly.

[ChristopherHX]

Hmm, How does the x11 glfw even open on your device?
I will try building a full wayland only flatpak with touchsupport glfw/glfw#1736

[Alexmitter]

If I got you right, glfw is used on the flatpak version, that one I never tried with X11.

This behaviour is with the appimage that if I got you right uses eglut.
It runs over Xwayland but I have to force the qt platform to xcb. But it does not run well, the X server dies the whole time.

Lets see how that flatpak with touch will behave.

[ChristopherHX]

That gets ugly flathub/io.mrarm.mcpelauncher#14
Not even shure that this even work at all.

This build doesn't use x11 in any way and won't run without wayland.

[ChristopherHX]

It would be so easy if touch would be supported by glfw, but it isn't

[ChristopherHX]

Test it as long the test build is available for download

flatpak install https://dl.flathub.org/build-repo/31837/io.mrarm.mcpelauncher.flatpakref

You might need to remove io.mrarm.mcpelauncher to not end up figuring out how to start the test build

[Alexmitter]

Thank you for that build. Sadly the game crashes instantly after I pressed the PLAY button.

I am not sure if I got everything from the log displayed as it does not fit on screen:

#0 /app/bin/mcpelauncher-client(_ZN12CrashHandler12handleSignalEiPv+0x124) [0x6262b4]
#1 linux-vdso.so.1(__kernel_rt_sigreturn+0) [0x7fa95c7780]
#2 /app/bin/mcpelauncher-client(glfwSetInputMode+0xc8) [0x699184]
#3 /app/bin/mcpelauncher-client(_ZN14GLFWGameWindowC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEii11GraphicsApi+0x158) [0x62cf98]
#4 /app/bin/mcpelauncher-client(_ZN17GLFWWindowManager12createWindowERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEii11G

[ChristopherHX]

Hehe that was a fail, but this seems to work on my atom tablet
flathub/io.mrarm.mcpelauncher#14 (comment)

Warning don't send inputs during loading the game, It crashed for me two times.

[ChristopherHX]

Also never press f11, it fails badly

[ChristopherHX]

Ugh. I thought the sheep render issue is a macOS / angle only bug, but also in this wayland build on linux.
Are there some window creation hints missing?

flatpak install https://dl.flathub.org/build-repo/31845/io.mrarm.mcpelauncher.flatpakref

It even crashs if you alt-f4. Not anywhere for a non beta release.

[Alexmitter]

Sorry, I will not be able to check it out until I got home from work. Around 17 o clock Central European time.

[Alexmitter]

Okay, the new test build starts the apk.
But no touch inputs inside Minecraft, not even like with the original flatpak version. Just no reaction at all.

[ChristopherHX]

Thats weird, archlinux gnome x86_64 with mouse and ubuntu wayland 20.10 x86_64 live touch and mouse worked for me.
Not tested aarch64, my raspberry pi 4 has no touchscreen.
The original flatpak uses x11 for the game.

Only the window of the game was messed up for me.

[ChristopherHX]

You can skip the qt ui of the appimage and start the game downloaded via the flatpak
Then you could try out eglut touch

1. /path/to/AppImage --appimage-mount &
2. /path/returned/from/first/command/usr/bin/mcpelauncher-client -dg ~/.var/app/io.mrarm.mcpelauncher/data/mcpelauncher/versions/1.16.100.04/

[Alexmitter]

I did exactly what you described, and was able to start the game this way. But it behaves exactly like the appimage did on its own, it seems to launch via X and crashes exactly the same way.
But at least here is a log: https://gist.github.com/Alexmitter/91a74dc8c12a141b44e2f35097fcf424

I wonder if we miss something here, could it be that the library used in the appimge does somehow force X and the only thing that may be wayland or not with it is the qt launcher? Because MCPE runs on wayland for sure via the flatpak.

Could you check if it actually is using wayland on your side? You can check by using the xeyes and move your mouse over the MCPE window, if the eyes move it is running on X.

[ChristopherHX]

The normal flatpak uses x11 with glfw.
The only working version? even if it depends on x11?

The appimage needs x11, I thought you said the qt ui of the AppImage didn't worked. So I provided the cli method for the client.
eglut of the AppImage is written and compiled against x11, no wayland support.

Only version which utilizes wayland:
The wayland flatpak test builds doesn't run under x at all (I removed x11 socket permissions and added wayland), unless that it is pretty untested, buggy and sometimes had an input freeze.
If this would ran under x11 touch couldn't work either here.

[Alexmitter]

Yes, you are right. Somehow I thought I did disable the X socket for the standard and enabled the wayland socket....

Anyways back to the wayland build. I figured out that if I use mouse and keyboard to navigate the menu and get into a map without crashing, it actually starts to react to my touches. I could look around in a rather normal way, but not press the touch control buttons, same as in the menu. Did work around 10 seconds

Edit: Here a video https://youtu.be/pVRQ9Qr-Uuc

[Alexmitter]

@ChristopherHX Any idea why it reacts to touch when I look around ingame, but not react to any button presses?

[ChristopherHX]

Looking around has a much bigger area than any input controls

You can try to make touch controls larger in settings.
Do you have enabled splitted controls? for me there is no crosshair.
Eventually mouse events are still there and make it even harder to touch the controls, try starting without any mouse connected.

[ChristopherHX]

My test device has a 1280x800 10.1 inch 10 point touch screen, everything is much bigger there.

It wasn't easy to press the ingame touch controls, but it worked

[Alexmitter]

@ChristopherHX I made the buttons as large as possible, I deactivated the splitted controls that were enabled by default.
While I can run the game without any mouse connected, I can not click anything in the menu with touch as it does not react at all similar to the in game buttons. So I have to use the mouse at least once to get into the map.
What I did do was disconnecting the mouse as soon as I started to load the map. The touch controlls come up as soon as I touch the screen once, but the buttons simply do not react at all. But the look around works well, especially as long as only one chunk is loaded it reacts very fast and precise.

[ChristopherHX]

Hard to figure out why the touch controls won't respond. I have no linux arm device (other than my android, not that I would know how to run real linux there) with a touchscreen.

I could try changing the mouse input to simulate the single touch input to see if that works on arm64 or something else like the untested glfw wayland touch extention is defect.

[ChristopherHX]

Not that it must be related.
Here gets the touches queued to the game, from the modified glfw wayland
https://github.com/minecraft-linux/mcpelauncher-client/blob/951c238c87927a25fb3b956ab4d9432b0ee67198/src/window_callbacks.cpp#L71

Android seems to handle multitouch differently, this launcher sends one Motionevent with one touch every time. Android seems to bundle all touches in one event.
https://www.vogella.com/tutorials/AndroidTouch/article.html

I'm not the one who have written that part of the launcher, but it seems to work fine on intel64

Touch events for the mouse can be enabled (without pointer capture etc.), I don't know how well that works on arm64
https://github.com/minecraft-linux/mcpelauncher-client/blob/951c238c87927a25fb3b956ab4d9432b0ee67198/src/window_callbacks.cpp#L49

Would logging touch inputs to console log help?

[Alexmitter]

@ChristopherHX

Would logging touch inputs to console log help?

I guess its worth a try. I also got a x86 based 8 Inch tablet to try, if I get it to boot I will try the wayland flatpak with it.

[Alexmitter]

@ChristopherHX So, here are the results with the random x86 tablet.

https://youtu.be/d4tYtm1phJ0

Its sadly exactly the same as on the phone. Buttons do not react at all in the menu, so again I have to use the mouse to load a map. Again I can look around, but not a single buttons does react at all.

[ChristopherHX]

Do you have a link to that OS? live iso?
I only tested Ubuntu 20.10 on wayland (default desktop)

My tablet should be able to run this x86_64 based OS too, if it isn't specially modified

[Alexmitter]

@ChristopherHX it is Ubuntu 19.10 with gnome wayland, nothing special. It is just a pain in the A to update that tab.
I can try 20.10 if you think there is any reason.

[ChristopherHX]

I mean the desktop didn't look like gnome for me.
There was something like a taskbar

[ChristopherHX]

Your x86 tablet can run the appimage?

[Alexmitter]

I mean the desktop didn't look like gnome for me.
There was something like a taskbar

I customized it a bit to make it more usable on that tablet. Its mainly just dash to panel.

Your x86 tablet can run the appimage?

I will try that

[Alexmitter]

@ChristopherHX I tried the appimage now, but it was just regular X emulating touches as mouse movements.

[ChristopherHX]

Thats weird, your drivers behaves much different than mine.
Maybe because you use xwayland? need test that case

[ChristopherHX]

nope xwayland has multitouch support, I get 0% mouse emulation there under xorg and xwayland same full multitouch.

[Alexmitter]

@ChristopherHX I will update it to 20.10 and check again. That will take a bit of time...

[theotheroracle]

the appimage behaves pretty strangely on my x86_64 wayland setup ( fedora 34, gnome 40 ) ( it's running as xcb on xwayland )

touch works intermittently, and i really can't figure out why, i attached some screen records .

Kooha-2021-09-02-01.01.28.mp4

Kooha-2021-09-02-00.57.46.mp4