I did not try your method yet, however I debugged the problem in my method. It's something (I guess Lomiri itself) that is sending a signal when the window is paused while switching. It is killing xev. The fix is to use TweakUT to keep the terminal awake, then my method works whatever the launch mode (direct > or with starting a new task &>)

So I could repro the problem you have seen. No discrepancy here.

I have looked a bit at Firefox and Chrome under vanilla Linux (Kubuntu 24.04) and xev reports something very different than under UT. That is, no strange events, basically the system reports the menu being created and mapped and that's all.

I have also 'packaged' a recent version of Firefox freshly downloaded from the editor's site, that is, I did

env GDK_DPI_SCALE=2 MOZ_ENABLE_WAYLAND=0 DISABLE_WAYLAND=1 ./firefox

and the menus in the top bar display (if no scaling were done, I'd guess that the menu would display if by a stroke of luck I could hit the minuscule screen area)

So my guess is that's not a clever packaging trick, that's something that Firefox is doing differently than Chrome. I searched for a Chrome Linux arm64 build but it seems that Google has insufficient resources to generate arm64 Linux builds (it's not a joke, it's exactly what is said by a Google employee in the Chrome issue tracker).

I'd say that as under UT Chrome and Firefox are hitting XWayland that is hitting Mir, the problem could be all the way down to Mir. The version of Mir in current 24.04 UT is woefully outdated. When it will be updated, the way forward will be to switch to Wayland anyway and drop XWayland.

@Sentinel said in No GPS access from inside Waydroid:

properly install Waydroid & get GPS working?

I never 'installed' Waydroid, I used the version coming with the OS and it helped me to understand GPS because the SatStat application allowed me to see immediately the satellits 'hits'. So in a way GPS is working better under Waydroid than under UT.

@zubozrout said in Smooth Edges (name pending) - Let's Fix the Bugs That Drive You Mad:

the camera—it’s the main limitation for me. From what I understand, this isn’t something that can be fixed simply by creating a new camera app, as the issue seems to run through multiple levels of the system. As far as I recall, the core limitation is already present in Halium: shots take too long, not all features are exposed, higher resolutions can easily overexpose, and overall the photos look far worse compared to what Android delivers.

Not sure exactly what is the problem as there too many you cite; maybe the main problem is that you have high expectations and are an elite user about photo. That's a bit like judging of a computer system by a music expert, these guys can detect one tenth of second of delay, a fourth of a tone, minute details that beotians like me can't even perceive whatever effort they do. And I'm not so atypical from what I gather of the judgement of these music experts on the efforts of spontaneous singers in public events (they are utterly awful - however I never noticed it before being said so).

So what's wrong with photo app of UT for someone like me? the focus for near objects. When taking a photo and the subject is half a meter (let's say one foot for our US friends) away, the focus is terrible, like, the keys on a keyboard can hardly be deciphered, and waiting does not provide much relief. In contrast, a Waydroid photo on the same device in exactly the same setup looks correct.

This does not look like an unfixable problem, since switching to film, the focus at the same distance is correct. I just tried it and it seems that after taking a short film, the focus is then correct for taking a photo. While this is hardly a workaround, it make me think that for the photo app being usable for ignoramuses like myself (and I'd say 99% of users), it is probably not necessary to rebuild the whole system including Halium.