Vive Focus 3 Android: Default mobile renderer does not start correctly on HMD

Godot version
4.0.2 stable
System information
Vive Focus 3 Release 5.5
Issue description
The current master godot-xr-tools sets the mobile renderer by default, but only gl_compatibilty starts correctly on the Vive Focus 3. Mobile results in a black start screen, then holding the controller trigger loads the first scene but as a corrupted 2d display.
Steps to reproduce
Import the godot-xr-tools master
Leave renderer as mobile
Install godot_openxr_loaders
Export as Android Khronos with Open XRKHR plugin selected
Run on the HMD
Corrupted display
Change renderer to gl_compatible and rebuild
Display is now correct.
Minimal reproduction project
N/A

It would be good to get some logs that may tell us more of what is happening. We are having issues with Vulkan on a number of android devices where there are issues potentially with multiview or other extensions.
One thing that would help is turning verbose on in your project settings and running the project using the remote debug function, this should provide a bunch more extra information in the log window in the Godot IDE.

Hi.
Probably me being thick. How do I export the debug error log text to a file or clipboard?
I can right click 1 entry and copy, but I can't find a way to do more than 1.
CTRL-A doesn't seem to select them all.
Anyway. Below are snippets I copied 1-by-1.
At the start I get this.
E 0:00:00:0807   interaction_profile_supports_io_path: OpenXR: Unsupported io path /interaction_profiles/htc/vive_focus3_controller/user/hand/left/input/system/click
  <C++ Error>    Parameter "io_path" is null.
  <C++ Source>   modules/openxr/openxr_api.cpp:264 @ interaction_profile_supports_io_path()

E 0:00:00:0807   interaction_profile_supports_io_path: OpenXR: Unsupported io path /interaction_profiles/htc/vive_focus3_controller/user/hand/right/input/trigger/touch
  <C++ Error>    Parameter "io_path" is null.
  <C++ Source>   modules/openxr/openxr_api.cpp:264 @ interaction_profile_supports_io_path()

E 0:00:00:0807   interaction_profile_supports_io_path: OpenXR: Unsupported io path /interaction_profiles/htc/vive_focus3_controller/user/hand/left/input/thumbrest/touch
  <C++ Error>    Parameter "io_path" is null.
  <C++ Source>   modules/openxr/openxr_api.cpp:264 @ interaction_profile_supports_io_path()

E 0:00:00:0996   find_interface: Interface not found.
  <C++ Error>    Condition "idx == -1" is true. Returning: nullptr
  <C++ Source>   servers/xr_server.cpp:227 @ find_interface()

W 0:00:01:0000   _update_swap_chain: The requested V-Sync mode Disabled is not available. Falling back to V-Sync mode Enabled.
  <C++ Source>   drivers/vulkan/vulkan_context.cpp:1899 @ _update_swap_chain()

W 0:00:01:0024   The function 'get_webxr_primary_action()' is a static function but was called from an instance. Instead, it should be directly called from the type: 'Node.get_webxr_primary_action()'.
  <GDScript Error>STATIC_CALLED_ON_INSTANCE
  <GDScript Source>demo_scene_base.gd:19

W 0:00:01:0054   open: res://addons/godot-xr-tools/hands/materials/cleaning_glove.material: In external resource #0, invalid UID: uid://c5cnjs0vgmwpb - using text path instead: res://addons/godot-xr-tools/hands/textures/cleaning_glove_baseColor.png
  <C++ Source>   core/io/resource_format_binary.cpp:1064 @ open()

W 0:00:01:0054   open: res://addons/godot-xr-tools/hands/materials/cleaning_glove.material: In external resource #1, invalid UID: uid://bpr3hcb5m0pkc - using text path instead: res://addons/godot-xr-tools/hands/textures/glove_occlusionRoughnessMetallic.png
  <C++ Source>   core/io/resource_format_binary.cpp:1064 @ open()

W 0:00:01:0054   open: res://addons/godot-xr-tools/hands/materials/cleaning_glove.material: In external resource #2, invalid UID: uid://dnlns2kfjkwhh - using text path instead: res://addons/godot-xr-tools/hands/textures/glove_normal.png
  <C++ Source>   core/io/resource_format_binary.cpp:1064 @ open()

E 0:00:01:0187   render_pipeline_create: vkCreateGraphicsPipelines failed with error -13 for shader 'SceneForwardMobileShaderRD:5'.
  <C++ Error>    Condition "err" is true. Returning: RID()
  <C++ Source>   drivers/vulkan/rendering_device_vulkan.cpp:6402 @ render_pipeline_create()

E 0:00:01:0187   _generate_version: Condition "pipeline.is_null()" is true. Returning: RID()
  <C++ Source>   servers/rendering/renderer_rd/pipeline_cache_rd.cpp:61 @ _generate_version()

E 0:00:01:0187   draw_list_set_push_constant: This render pipeline requires (0) bytes of push constant data, supplied: (128)
  <C++ Error>    Condition "p_data_size != dl->validation.pipeline_push_constant_size" is true.
  <C++ Source>   drivers/vulkan/rendering_device_vulkan.cpp:7307 @ draw_list_set_push_constant()

E 0:00:01:0187   draw_list_draw: No render pipeline was set before attempting to draw.
  <C++ Error>    Condition "!dl->validation.pipeline_active" is true.
  <C++ Source>   drivers/vulkan/rendering_device_vulkan.cpp:7324 @ draw_list_draw()

W 0:00:01:0252   open: res://addons/godot-xr-tools/hands/materials/labglove.material: In external resource #0, invalid UID: uid://bv21ei62pffeb - using text path instead: res://addons/godot-xr-tools/hands/textures/labglove_baseColor.png
  <C++ Source>   core/io/resource_format_binary.cpp:1064 @ open()

W 0:00:01:0252   open: res://addons/godot-xr-tools/hands/materials/labglove.material: In external resource #1, invalid UID: uid://bpr3hcb5m0pkc - using text path instead: res://addons/godot-xr-tools/hands/textures/glove_occlusionRoughnessMetallic.png
  <C++ Source>   core/io/resource_format_binary.cpp:1064 @ open()

W 0:00:01:0252   open: res://addons/godot-xr-tools/hands/materials/labglove.material: In external resource #2, invalid UID: uid://dnlns2kfjkwhh - using text path instead: res://addons/godot-xr-tools/hands/textures/glove_normal.png
  <C++ Source>   core/io/resource_format_binary.cpp:1064 @ open()

E 0:00:01:0364   render_pipeline_create: vkCreateGraphicsPipelines failed with error -13 for shader 'SceneForwardMobileShaderRD:5'.
  <C++ Error>    Condition "err" is true. Returning: RID()
  <C++ Source>   drivers/vulkan/rendering_device_vulkan.cpp:6402 @ render_pipeline_create()

E 0:00:01:0364   _generate_version: Condition "pipeline.is_null()" is true. Returning: RID()
  <C++ Source>   servers/rendering/renderer_rd/pipeline_cache_rd.cpp:61 @ _generate_version()

E 0:00:01:0364   draw_list_set_push_constant: This render pipeline requires (0) bytes of push constant data, supplied: (128)
  <C++ Error>    Condition "p_data_size != dl->validation.pipeline_push_constant_size" is true.
  <C++ Source>   drivers/vulkan/rendering_device_vulkan.cpp:7307 @ draw_list_set_push_constant()

E 0:00:01:0364   draw_list_draw: No render pipeline was set before attempting to draw.
  <C++ Error>    Condition "!dl->validation.pipeline_active" is true.
  <C++ Source>   drivers/vulkan/rendering_device_vulkan.cpp:7324 @ draw_list_draw()

E 0:00:01:0409   render_pipeline_create: vkCreateGraphicsPipelines failed with error -13 for shader 'SceneForwardMobileShaderRD:5'.
  <C++ Error>    Condition "err" is true. Returning: RID()
  <C++ Source>   drivers/vulkan/rendering_device_vulkan.cpp:6402 @ render_pipeline_create()

E 0:00:01:0409   _generate_version: Condition "pipeline.is_null()" is true. Returning: RID()
  <C++ Source>   servers/rendering/renderer_rd/pipeline_cache_rd.cpp:61 @ _generate_version()

E 0:00:01:0409   draw_list_set_push_constant: This render pipeline requires (0) bytes of push constant data, supplied: (128)
  <C++ Error>    Condition "p_data_size != dl->validation.pipeline_push_constant_size" is true.
  <C++ Source>   drivers/vulkan/rendering_device_vulkan.cpp:7307 @ draw_list_set_push_constant()

E 0:00:01:0409   draw_list_draw: No render pipeline was set before attempting to draw.
  <C++ Error>    Condition "!dl->validation.pipeline_active" is true.
  <C++ Source>   drivers/vulkan/rendering_device_vulkan.cpp:7324 @ draw_list_draw()

E 0:00:01:0410   get_width: Viewport Texture must be set to use it.
  <C++ Error>    Condition "!vp" is true. Returning: 0
  <C++ Source>   scene/main/viewport.cpp:111 @ get_width()

E 0:00:01:0410   get_width: Viewport Texture must be set to use it.
  <C++ Error>    Condition "!vp" is true. Returning: 0
  <C++ Source>   scene/main/viewport.cpp:111 @ get_width()

And then the same errors repeat until I hold the trigger to switch to the main menu scene. Then I get this.
E 0:00:10:0798   draw_list_draw: The vertex format used to create the pipeline does not match the vertex format bound.
  <C++ Error>    Condition "dl->validation.pipeline_vertex_format != dl->validation.vertex_format" is true.
  <C++ Source>   drivers/vulkan/rendering_device_vulkan.cpp:7331 @ draw_list_draw()

E 0:00:10:0842   render_pipeline_create: vkCreateGraphicsPipelines failed with error -13 for shader 'SceneForwardMobileShaderRD:5'.
  <C++ Error>    Condition "err" is true. Returning: RID()
  <C++ Source>   drivers/vulkan/rendering_device_vulkan.cpp:6402 @ render_pipeline_create()

E 0:00:10:0842   _generate_version: Condition "pipeline.is_null()" is true. Returning: RID()
  <C++ Source>   servers/rendering/renderer_rd/pipeline_cache_rd.cpp:61 @ _generate_version()

E 0:00:10:0842   draw_list_bind_render_pipeline: Condition "!pipeline" is true.
  <C++ Source>   drivers/vulkan/rendering_device_vulkan.cpp:7124 @ draw_list_bind_render_pipeline()

E 0:00:10:0843   draw_list_draw: Uniforms supplied for set (3):
Set: 3 Binding: 1 Type: Texture Writable: N Length: 1
are not the same format as required by the pipeline shader.  Returning: RID()
  <C++ Source>   drivers/vulkan/rendering_device_vulkan.cpp:6402 @ render_pipeline_create()

E 0:00:10:0875   _generate_version: Condition "pipeline.is_null()" is true. Returning: RID()
  <C++ Source>   servers/rendering/renderer_rd/pipeline_cache_rd.cpp:61 @ _generate_version()

E 0:00:10:0875   draw_list_draw: Uniforms supplied for set (3):
Set: 3 Binding: 1 Type: Texture Writable: N Length: 1
are not the same format as required by the pipeline shader.  Returning: RID()
  <C++ Source>   drivers/vulkan/rendering_device_vulkan.cpp:6402 @ render_pipeline_create()

E 0:00:10:0907   _generate_version: Condition "pipeline.is_null()" is true. Returning: RID()
  <C++ Source>   servers/rendering/renderer_rd/pipeline_cache_rd.cpp:61 @ _generate_version()

E 0:00:10:0908   draw_list_draw: Uniforms supplied for set (3):
Set: 3 Binding: 1 Type: Texture Writable: N Length: 1
are not the same format as required by the pipeline shader.  Returning: RID()
  <C++ Source>   drivers/vulkan/rendering_device_vulkan.cpp:6402 @ render_pipeline_create()

Which also then repeats until I stop the app.

I get this error trying to do something similar with a Pico Neo 3. Might be related.
`E 0:00:01:0809   render_pipeline_create: vkCreateGraphicsPipelines failed with error -13 for shader 'SceneForwardMobileShaderRD:5'.
<C++ Error>    Condition "err" is true. Returning: RID()
<C++ Source>   drivers/vulkan/rendering_device_vulkan.cpp:6403 @ render_pipeline_create()
E 0:00:01:0809   _generate_version: Condition "pipeline.is_null()" is true. Returning: RID()
<C++ Source>   servers/rendering/renderer_rd/pipeline_cache_rd.cpp:61 @ _generate_version()
E 0:00:01:0809   draw_list_set_push_constant: This render pipeline requires (0) bytes of push constant data, supplied: (128)
<C++ Error>    Condition "p_data_size != dl->validation.pipeline_push_constant_size" is true.
<C++ Source>   drivers/vulkan/rendering_device_vulkan.cpp:7316 @ draw_list_set_push_constant()
E 0:00:01:0809   draw_list_draw: No render pipeline was set before attempting to draw.
<C++ Error>    Condition "!dl->validation.pipeline_active" is true.
<C++ Source>   drivers/vulkan/rendering_device_vulkan.cpp:7333 @ draw_list_draw()
`

HI,
render_pipeline_create: vkCreateGraphicsPipelines failed with error -13 for shader 'SceneForwardMobileShaderRD:5'.
This error didn't occur in Godot 4.1.2.
In Godot 4.1.2 Vulkan, it can run correctly on the Focus 3, but there is a render issue.
This is root caused by the MSAA feature of the swapchain image. We have already fixed it, and the problem will be resolved in the next VIVE WAVE ROM update.


feat: Add Onboarding Screens + ask location + ask notification

feat: Add Onboarding Screens + ask location + ask notification

:tada: This PR is included in version 1.14.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Print info when expectations are not verified

Closes #31

Thanks :grin:
It will require a minor version bump, so I won't release it straight away. I have a few other improvements I want to make which might require breaking changes, so I'll group them together.


Switch to pip-compile-multi

Hi, Zulip developers!
I'm a maintainer of pip-compile-multi - tool, that is meant to replace tools/update-locked-requirements.
In this PR I added pip-compile-multi to requirements/dev.in and executed:
$ pip-compile-multi

Some packages were updated and some stayed as is. I had to relax cryptography constraint because of version conflict.
It works a bit different from tools/update-locked-requirements - instead of copying all packages from referenced files, it inserts a reference to compiled requirements file. Other than that, it's just a wrapper for pip-tools.
(It's first battle test for the pip-compile-multi outside of my projects.)

I tried to replace distutils import with setuptools and it solved the issue...

This should have been detected by pip-tools, but it would also suffice to detect the error and have pip-compile-multi handle the distutils case until the fix is delivered upstream?

pip-compile fails to generate .txt file because of this error, so I can't think of a way to work around it.
AFAIK python setup.py egg_info is the (only?) best way of getting a list of package dependencies, and it fails for pycurl.

I'll try to make a minimal working example and see why pip-compile handles it differently when running with and without pip-compile-multi

As I understand, pip-tools released a workaround for this problem. So I rebased my changes to see if it will work on CircleCI.
Now it shows different error:
Feb 09 03:12:28 Traceback (most recent call last):
Feb 09 03:12:28   File "/srv/zulip-thumbor-venv/bin/thumbor", line 7, in <module>
Feb 09 03:12:28     from thumbor.server import main
Feb 09 03:12:28   File "/srv/zulip-venv-cache/b81ca633007b175aa46374073a802cb70a297637/zulip-thumbor-venv/local/lib/python2.7/site-packages/thumbor/server.py", line 22, in <module>
Feb 09 03:12:28     from thumbor.console import get_server_parameters
Feb 09 03:12:28   File "/srv/zulip-venv-cache/b81ca633007b175aa46374073a802cb70a297637/zulip-thumbor-venv/local/lib/python2.7/site-packages/thumbor/console.py", line 13, in <module>
Feb 09 03:12:28     from thumbor.context import ServerParameters
Feb 09 03:12:28   File "/srv/zulip-venv-cache/b81ca633007b175aa46374073a802cb70a297637/zulip-thumbor-venv/local/lib/python2.7/site-packages/thumbor/context.py", line 13, in <module>
Feb 09 03:12:28     from concurrent.futures import ThreadPoolExecutor, Future

For some reason it uses python2.7...

I dug the tools and discovered, that thumbor runs under Python2.7 while everything else under Python3.x.
Since I compiled all requirements under Python3 thumbor.txt didn't get backport for concurrent.futures.
So, I recompiled thumbor.in under Python2.7 and got futures into thumbor.txt

Alright, now I get
    raise Exception("It looks like you have updated some python dependencies but haven't "
Exception: It looks like you have updated some python dependencies but haven't updated locked requirements files. Please update them by running `tools/update-locked-requirements`. For more information please refer to `requirements/README.md`.

which must be easy to fix. But I need some sleep.

I dug the tools and discovered, that thumbor runs under Python2.7 while everything else under Python3.x.
Since I compiled all requirements under Python3 thumbor.txt didn't get backport for concurrent.futures. So, I recompiled thumbor.in under Python2.7 and got futures into thumbor.txt

Yeah the thumbor system is in 2.7.

Hey guys, I didn't get your opinion on using pip-compile-multi verify inside tools/test-locked-requirements.
I explained changes in logic in a comment for https://github.com/zulip/zulip/pull/8079/commits/f018748f5e20e890f84a8e280a99493658235a76
Let's make a decision.
cc @rht @adnrs96 @timabbott @gnprice

@peterdemin I'm super busy right now.  Can you provide a bit more of a summary for (1) In what ways pip-compile-multi is better/different than the old system (other than getting the delete code, which is nice) and (2) why you need so many changes to our requirements files?  E.g. why the conversion to use ~= ?
As a sidenote, it's kinda not great that you have so many changes to the versions of individual packages mixed into this PR; ideally, the tooling change would be independent from the packages we end up with.  But maybe that's tied in with the ~= switch?

Right, this must be explained.

pip-compile-multi is a universal tool, that automatically discovers which requirements files need to be compiled (locked), thus it needs little to no configuration. It allows keeping references between requirements files, so that resulting files are smaller and don't have duplicates. It evolves and provides abilities that zulip might need in future, like adding packages hashes. pip-compile-multi verify runs faster (instantly) than old tools/test-locked-requirements because it doesn't recompile all .txt files, but just checks .in files hashes.
There are a lot of changes to requirements files because pip-compile-multi slightly changes a way of working with requirements. First - common.in is compiled to common.txt and then referenced from other files. Second - .in contain only direct dependencies, packages are unconstrained or constrained to avoid known incompatibilities, while packages in .txt files are hard-pinned. Using compatible release (~=) is a temporary measure to avoid major dependency updates while changing toolset.
Actually, I don't see much use in hard-pinning packages in .in files - it makes it harder to update them.

pip-compile-multi allows adding new workflow - periodic dependency update. Say once a month you create a branch and run pip-compile-multi there and check that CI tests are passing (and merge). That's the easiest way of not having to deal with backward incompatible releases while using the freshest packages with all the bug fixes and performance improvements.
I can separate this PR into two:

Change the toolset.
Execute new tools to update dependencies.
But I think it is better this way since you can see the change and the effect (and CI tests pass).

The story for using pip-compile-multi makes sense.

Actually, I don't see much use in hard-pinning packages in .in files - it makes it harder to update them.

This is important to provide predictability; with a project of Zulip's size, dependencies are constantly releasing breaking upgrades, and we need to manage that explicitly.  So our policy is to pin explicit versions everywhere.
I think if you just stuck with the hard-pinned versions in your PR, you'd be able to avoid merge conflicts (or material changes to the .in files), and that'd make it much easier to maintain this branch and eventually integrate it.  We can always switch from doing hard-pinning later; what's important for now is to ensure that we're not breaking anything, and having a bunch of effectively unrelated package version changes mixed in with the tooling change is a recipe for a PR that gets stuck.
Does that make sense to you @peterdemin?

Yeah, I hoped to make this in bulk, relying on the test suite. Ok, I'll revert to hard-pins in .in files.
However, I don't quite understand the argument on predictability.
Packages are installed from .txt files, that have hard pins, so the builds are predictable.
I'm a proponent of frequent updates - once a problematic dependency version is encountered, it should be constrained in .in files (along with the creation of an Issue for adopting new version).

Packages are installed from .txt files, that have hard pins, so the builds are predictable.

When we need to update one package (or add a new dep), we don't want updating the rest of our dependencies to be part of that PR.  So, instead, at least once a month, we do a big manual update like #8371.

I see. I want to automate this case with pip-compile-multi.
One way to solve this is to have --direct-only flag, that will leave only direct dependencies in the generated file.
Then zulip will have 3 layers of requirements files:

.unc - Unconstrained list of package names, except for known compatibility problems.
.prim - Primary hard-pinned dependencies - that's what currently stored in .in files.
.txt - a full list of hard-pinned dependencies.

For adding new dependency during feature PR it is added both to .unc and to .prim file and then a full list of dependencies is compiled in .txt files.
For the regular update of primary dependencies .unc files are compiled to .prim with --direct-only flag, .prim files are compiled to .txt.
I think it will make bulk dependency updates (like in #8371) easier to do.

Another option is to run pip-compile-multi with --no-upgrade, that will leave all satisfying dependencies as is.

To make this PR easier to review I removed all version updates.
Leaving only essential pieces:

Update tooling;
Add common.txt (with all common packages locked) that is referenced from other .txt files.

I added --no-upgrade option to pip-compile-multi and rebased the branch. So now it fully supports zulip's use case.
@timabbott, what do you think?

Hey @timabbott, do you have the time to review the PR and merge/close it?
If so, I'll resolve the conflicts.

Closing, since we're currently looking at direction of using nix to make our production environment even more portable, so we're unlikely to want to do further changes.
Thanks for all your work on this @peterdemin! I think pip-compile-multi is a cool project.

Sounds good. I'm curious, how does nix address this problem?

Regarding with portability, you can install nix on any *NIX systems, and the same nix expressions are used in all those systems. Code branching to address various distributions, as you can see in https://github.com/zulip/zulip/blob/5ee4f717019aaceb5408de807e351165bc3da497/puppet/zulip/manifests/common.pp#L3-L39 and lots of other places, is no longer required.


No License Specified

Please choose a license and upload it to the repo.

Thanks for letting me know, I just added it (MIT)