Open velickolb opened 2 years ago
I have the same problem, on Samsung Galaxy s22 camera feed is not showing up in google chrome with WebXR , i see a 3D model but the camera is black.
I have experienced the same issue on Galaxy S22 in WebXR, when i start an AR session the screen is black like the camera isn't working but the model gets placed.
Are there any updates on this topic, is this happening to anyone else?
@AdaRoseCannon @klausw This sounds like a Samsung / WebXR problem. Can you verify the issue?
Is dark mode on?
Yes, but after turning it off it was still the same.
I tried logcat to capture some logs and I got this error when trying to enter WebXR. Im guessing that it has something to do with the exynos cpu. I can not test the snapdragon version.
2022-06-05 11:08:23.075 8041-23236/? D/libEGL: ANGLE Info:Debug.cpp:183 (insertMessage): GL error: HIGH: External texture attached to framebuffer is not YUV.
2022-06-05 11:08:23.078 845-23407/? E/ExynosCameraRequestManager: [CAM(-1)][]-(hasStream[665]):Invalid Stream id (23)
That's helpful thank you!
Any update on this issue? Facing the same issue with S22 running Exynos
following, same issue here on s22 ultra
One of my client has the issue with s22 exynos. Whoever have device with an issue in hand, can you please investigate/debug farther. There are millions of these devices, and it would be unexplainable for them why AR on their hi end devices does not work....
I filed https://bugs.chromium.org/p/chromium/issues/detail?id=1355946 to follow up on the Chromium side.
Unfortunately we haven't been able to reproduce the issue - we don't have an S22 for testing, and it doesn't seem to be a general issue for Exynos devices, for example a Samsung Galaxy S7 Exynos appears to work normally.
@AdaRoseCannon - do you happen to know someone at Samsung who I could contact to borrow an Exynos S22 for testing? They aren't being sold in the US.
Bigger picture, it's unclear if this is a Chromium bug (i.e. misusing a GL texture), a GPU driver bug, or just an incompatibility (i.e., Chromium assumes that a texture format is available, but this device would require using a different one.)
@velickolb , would you be able to attach a longer logcat with more context to https://bugs.chromium.org/p/chromium/issues/detail?id=1355946 ? Specifically, it would help to know which of Chrome's processes (browser or GPU process) is emitting that error message. I've added more information about how to extract those logs in a comment there.
I added a speculative workaround that's now available in Chrome Canary >= 107.0.5303.2. I still haven't been able to reproduce the issue or seen more detailed logs, so this is a bit of a stab in the dark, but please let me know in case this changes anything.
I know this isn’t a model-viewer issue, but has anyone found the reason or a fix for this issue? I am using a S22 Ultra Exynos with Chrome/Samsung internet/Chrome Canary and I am facing the same issue, no camera feed whatsover after entering webXR’s AR mode. Unfortunately, @klausw ’s speculative workaround did not seem to do the trick for me. Any suggestions? Best, Julien
Thanks @djebel-amila for the feedback. I'll try to get access to an Exynos S22 phone for further testing. Just to confirm, are all the phones affected by this issue Exynos S22 variants? You mentioned the S22 Ultra specifically, are the others using a plain S22 or a S22 Plus?
Thanks @djebel-amila for the feedback. I'll try to get access to an Exynos S22 phone for further testing. Just to confirm, are all the phones affected by this issue Exynos S22 variants? You mentioned the S22 Ultra specifically, are the others using a plain S22 or a S22 Plus?
Hi,
Thanks for your answer. It’s my understanding from reading this thread and the one on the webXR repo that the issue exists on S22 (as @fabian-muff reported it) and S22 Ultra at least, no one posted about S22 Plus. Some people facing the issue with a S22 Ultra and webXR’s example model-viewer said they found a quick-fix by inverting the order of the ar-modes
parameters, from ar-modes="webxr scene-viewer quick-look"
to ar-modes="scene-viewer quick-look webxr"
but I’m not sure how relevant it may be.
Please let me know if I can be of help.
Hello, @klausw I tested the fix you added to chrome canary. With Version 108.0.... nothing changet at the problem. I debugged some sessions on the webxr example page and there are no errors. The only one is the following, which it seems has nothing to do with the problem:
I am using a Exynos S22 that I bought directly after the release in Switzerland.
Samsung s22 model: SM-s901b/DS (exynos). I confirm that Scene Wiewer is working. So it must be not a hardware problem, but the browser or os. I've tried in Samsung Browser and Chrome. In both browsers there is no camera background feed in webxr at. Everything else is still working, planes are being detected and I can place 3D scene on them.
Scene Viewer is not what I can use though. In my case the 3d scene is being composed dynamically by the web app so when I go to the AR I cannot use the model url. I've tried to change the code to generate url dynamically for the glb file prepared on the fly similarly as it is for Quick Look (usdz). It doesn't work, the scene viewer is launched and asks you to find the plane, when the plane is found and it tries to shows the 3d model it crashes immediately.
I am using a Exynos S22 that I bought directly after the release in Switzerland.
I am in Switzerland too. Imagine it’s just Swiss S22s 😳
I am in Germany and my S22 does not give the camera feed in webxr mode.
I am using a Exynos S22 that I bought directly after the release in Switzerland.
I am in Switzerland too. Imagine it’s just Swiss S22s 😳
@klausw can we provide any help?
I have the same issue with my Samsung S22 Ultra. How can I help?
Please see https://crbug.com/1355946#c7 for an update, I finally got an S22 and was able to reproduce it. In short, the root issue seems to be overzealous validation in the ANGLE-to-Vulkan layer that provides the native GLES driver on this platform. It does not allow use of a framebuffer color attachment backed by an RGB external texture, which is odd since this works fine on other devices including older Samsung Exynos phones. The specification is a bit unclear, but initial consensus seems to be that this is likely a bug and the validation check should be removed.
Unfortunately fixing this would need to happen at the GLES driver level, meaning that Samsung would need to ship an updated driver that includes an updated ANGLE library, this is a separate copy from the ANGLE library included in Chrome.
Doing a workaround in Chrome would be quite difficult. We can't use Vulkan directly since Chrome needs to share a GLES context with the ARCore library, and switching Chrome to using a YUV external texture is also tricky since it requires an extension and NDK support that I think we can't assume is generally present.
@klausw Thanks a lot for the update and identifying the issue. Someone mentions trying to patch the ANGLE API, would that imply there’d be a chromium build that may work (until Samsung offers a driver update of some kind)?
@djebel-amila wrote:
Someone mentions trying to patch the ANGLE API, would that imply there’d be a chromium build that may work (until Samsung offers a driver update of some kind)?
Sorry, that isn't possible in this case. Samsung ships their own copy of ANGLE to provide the system GLES driver, it's a wrapper around the native Vulkan API. Chrome's WebXR AR mode uses the system GLES driver and thereby Samsung's copy of the ANGLE library, and it's that system ANGLE library that would need to be patched. Changing Chrome's copy of the ANGLE library would have no effect on this issue since it isn't being used in WebXR AR mode.
And it's not possible to us Chrome's ANGLE library on top of the system Vulkan driver since the Chrome browser process and the ARCore library need to share an EGL context. Last I checked, there's no way to use ARCore with Vulkan directly, so we need to use the system GLES driver which uses the system ANGLE library.
(Apologies for being redundant here, I'm just trying to be as clear as possible since it's a confusing situation.)
@klausw Thank you for the explanation. So I assume the only thing we can do is to wait. I don't think that this will have priority on Samsung's side. It's a pity. I just bought a new phone for testing WebXR :(
@klausw Thanks for explaining, it’s very helpful. I‘ll try and reach some technical support service at Samsung, with little hope though.
@djebel-amila i already did. They told me to write to service_ch@samsung.com Maybe if you try it as well, they will do something ;)
For anyone affected by this, please note that my comments above are based on my current understanding of the issue, and it's possible that something else may also be going on or that I'm misunderstanding something. Please keep that in mind in case you're reaching out to Samsung. The Chromium bug tracker entry at https://crbug.com/1355946#c7 has more details about the investigation so far.
According to https://crbug.com/1355946#c11, Samsung acknowledged that this is a driver issue that should be fixed upstream, but also says that it's unlikely that this device will get the update.
On the bright side, I have a potential workaround for Chrome's WebXR AR device code. Basically, it pretends that this phone doesn't support shared hardware buffers and falls back to the less efficient Android N render path. This gets AR working, including DOM overlay, but is missing some advanced features such as raw camera access. I'll update this bug if/when that's available in Chrome Canary for testing.
The workaround is included in Chrome Canary >= 109.0.5402.0 which is available now on the Play Store. Assuming it doesn't cause any regressions, it should be available in stable Chrome 109 once that gets released around Jan 10 2023.
Thanks @klausw! Really appreciate the work-around.
Awesome! Works like a charm. Thank you very much @klausw. I can't emphasize how much this helped
Interesting. Thank you very much @klausw. As mentioned, raw camera access does not work. The experimental feature "image-tracking" works however 👍
@fabian-muff What is this experimental "image tracking feature" ?
@v-prgmr this is an alternative to raw camera access that allows to estimate the pose of images. (see https://github.com/immersive-web/marker-tracking/blob/main/explainer.md)
The workaround is [included] (https://chromiumdash.appspot.com/commit/3d181f693ec651bae7ea2229d7bd285657ad406f) in Chrome Canary >= 109.0.5402.0, which is now available in the [Play Store] (https://play.google.com/store/apps/details?id=com.chrome.canary).)) Assuming it doesn't cause regressions, it should be available in stable Chrome 109 once it's released around January 10, 2023.
Sorry to wake up the thread. With the newly released S24 Plus, which also has an Exynos processor, I now have the same problem. Is it possible to update this Canary? Otherwise I would need to return to my s23.
@LB31 , the described change was included in the stable Chrome 109 release as scheduled, and has not been reverted since then. However, the workaround is only applied to devices matching "gl_renderer": "ANGLE.*Samsung Xclipse 920.*"
according to gpu/config/gpu_driver_bug_list.json.
@bialpio - I haven't been following recent changes in this area. Should the workaround be extended to other related devices, for example by removing the "920" version number?
@LB31 - can you check chrome://gpu/ on your device and post your GL_RENDERER entry?
Hi @klausw thanks for your response.
My GL_Renderer entry says: ANGLE (Samsung Electronics Co. Ltd., ANGLE (Samsung Xclipse 940) on Vulkan 1.3.231, OpenGL ES 3.2 ANGLE git hash: 131b607622f4)
So Xclipse 940
@LB31 , thanks for the details.
I've submitted a Chromium change to expand the workaround, this should be available in Chrome Canary in a day or two. Check the "Releases" section of the tracking dashboard for status: https://chromiumdash.appspot.com/commit/f95ebc8ca80579cae37d0a4c1105a93ebbcd86db
@LB31 , thanks for the details.
I've submitted a Chromium change to expand the workaround, this should be available in Chrome Canary in a day or two. Check the "Releases" section of the tracking dashboard for status: https://chromiumdash.appspot.com/commit/f95ebc8ca80579cae37d0a4c1105a93ebbcd86db
Hi @klausw, thank you for your submission. It has now been released, and I was able to update the Chrome Canary app on my S24 phone. However, I'm now encountering an issue where clicking on 'START AR' does nothing, and the button doesn't disappear.
That sounds like a different issue - can you file a Chromium bug? Anything
relevant in the JavaScript console? If possible, please also attach
relevant adb logcat
output or a bugreport.
On Sat, Jan 27, 2024 at 5:29 AM Leonid Barsht @.***> wrote:
@LB31 https://github.com/LB31 , thanks for the details.
I've submitted a Chromium change to expand the workaround, this should be available in Chrome Canary in a day or two. Check the "Releases" section of the tracking dashboard for status: https://chromiumdash.appspot.com/commit/f95ebc8ca80579cae37d0a4c1105a93ebbcd86db
Hi @klausw https://github.com/klausw, thank you for your submission. It has now been released, and I was able to update the Chrome Canary app on my S24 phone. However, I'm now encountering an issue where clicking on 'START AR' does nothing, and the button doesn't disappear.
— Reply to this email directly, view it on GitHub https://github.com/google/model-viewer/issues/3495#issuecomment-1913156870, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKT5X2W2BPR6AWPOVMZGODYQT6NLAVCNFSM5W4HJNZKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJRGMYTKNRYG4YA . You are receiving this because you were mentioned.Message ID: @.***>
Description
I have issue with WebXR on Samsung s22 where camera feed is not showing up. Sometimes it completely black and sometimes its showing the web page from where AR is loaded. In both cases model is instantiated and all interactions are working. It affects all the AR pages where WebXR is used, example ones and all the others. Scene Viewer works fine. I have attached screenshot and video.
Demo
Version
Browser Affected
OS
AR