Modern Android aggressively kills applications in the background. Android apps have to be designed around this paradigm: That is the app can be killed at any moment when in the background, and must be able to seamlessly restart and pick up where things were left off
OK that makes a certain degree of sense and explains some things I’ve seen.
However–android really ought to remove the thing from the task list if the process has been killed. It certainly gives me the wrong impression as to what is going on. I’m left wondering why, if Firefox has been running, why it has to reload the damned page! (Which is excruciatingly slow 90% of the time.) It’s a lose-lose for Firefox that way (I complain that it won’t quit and I complain that it thinks it has to reload the pages, when in fact it DID quit, which would be a good thing, and therefore MUST reload the page, which is understandable at that point). What makes that even worse is that Firefox is one of the very few things I deliberately leave up, just so this doesn’t have to happen (and yet it does anyway!)
I have no idea if this is feasible, but for Firefox the ideal might be to have it stay resident, but have its access to the antenna be cut off while it is “minimized” (not the top process). That way a page like one on Wikipedia or anything that doesn’t do a lot of donkeying around with constantly hitting the internet to run movies of dancing kittens (or whatever the heck) while just being looked at doesn’t need reloading.
Every inactive tab can be paused.
Every minimized app can also be paused, but it’s not even necessary.
Native apps can just be made well-behaving.
Flatpaks over which you don’t have control could be paused.
the Librem 5 v2 (2021+) is going to have a magnetic decoupling system for the usb type C connector similar to the Apple mag-safe that prevents accidental tripping and forceful-projection of your expensive-brand-new L5 v2 through the window while your children play around while you are in convergence mode trolling the forums like a bo$$ …
The magnetic thing you may have seen in the librem 5v2 was the tinfoil suit connection. The librem 5 allows you to wear the tinfoil suit while using your phone from the outside transmitting you the sound via vibration.
They still use RAM, but the SIGSTOP and SIGCONT signals do exactly this for programs on Linux, completelly freezing the program to be re-started later in exactly the same state. I have used it to pause renders before, at least until I found the undocumented button in BlendLuxCore to pause renders natively.
Also, these stopped programs would probably move to swap memory very quickly if it was needed, given that while they are stopped they are not doing anything.
Simply correct (comes from Tina Turner: “Simply the Best”)! From now on NXP offers i.MX 8M Plus: Quad Cortex-A53 @ 1.8 GHz based on 14 nm LPC FinFET, 15 x 15 FC-BGA 0.5 mm pitch (instead of 17 x 17 FC-BGA).
The problem of the 14nm i.MX 8 seems to be the smaller GPU. iMX8 Nano and Plus only have a GC7000UltraLite 3D GPU (2 shaders). This looks like half the size ~performance then the 8M in the Librem5. Nano doesn’t have PCIe and the Plus only 1x PCIe.
Beside Vivante GC7000UltraLite 3D GPU there is added separate GC520L 2D GPU (8 x Single Pass Composition Blending). In my non-expert opinion, NXP i.MX8M Quad is great when performing on a steady (condition) external power supply. For example we have devices (like SolidRun Ltd CuBox Pulse) that are capable of using dual display on i.MX8 including 4k decoding. New to i.MX8M Plus is Tensilica HiFi 4 DSP with 448 KB OCRAM and 64 KB TCM, is this disadvantage as well? Also, is there something that I missed when this Forum talked about “some kind” of heat (thermal) problems with the current processor option?
Not being in batch Dogwood I might say that I’m patient. I just think this is great news from NXP (even if not related to Librem 5).
i.MX8M Plus belongs to NXP Semiconductors’ EdgeVerse platform brand:
The i.MX 8M Plus is a whole different chip than the i.MX 8M Quad. It depends on what you want to do with Librem 5 whether you think that Fir will be better or worse than Evergreen.
Improvements:
Shrinks from 28nm HPC to 14nm LPC FinFET process node, so more energy efficient
Shrinks from a 17x17 mm package to a 15x15 mm package, so saves space
Increases max CPU clock from 1.5 to 1.8 GHz
Adds a neural processing unit (2.3 TOPS)
Adds a dual camera image signal processor (2x HC/1x 12 MP) with HDR and dewarp
Improves the Cortex-M7 subprocessor from 266 to 800 MHz and increased its tightly coupled SRAM from 256 to 512 KB.
Adds video hardware encoding (H.264 and H.265 at 1080p60), whereas the i.MX 8M Quad has to do software encoding
Adds a HiFi 4 DSP for audio and natural language processing
Adds Immersiv3D audio with Dolby Atmos® and DTS:X®
Increases promise to produce the chip from 10 years to 15 years
Improves things that aren’t used by the Librem 5 (increases number of USB interfaces from 2 to 3, increases number of Ethernet interfaces from 1 to 2, increases PCIe from version 2.0 to 3.0, etc.)
Improves the PMIC (hopefully for better power efficiency)
I think that it increases the number of video interfaces from 2 to 3 (so potentially could have dual screen video out if Purism decides to implement it, but I haven’t read the docs to know how this works)
Disadvantages:
Decreases the L2 cache from 1MB to 512KB.
Reduces the GPU from GC7000Lite (4 shaders) to GC7000UltraLite (2 shaders)
Decreases the max video out from 60 to 30 frames per second and gets rid of HDR (4Kp60 HDR -> 4Kp30)
Decreases max video hardware decoding from 4Kp60 HDR to 1080p60 (no HDR)
The i.MX 8M Plus looks a lot better, until you dig into the details. Its image signal processor only supports a max resolution of 12 MP, which isn’t enough to support the 13 MP back camera in the Librem 5, so it probably won’t be used by the back camera, but the front camera might use it. We probably won’t have any software that will take advantage of the neural processing unit and the audio digital signal processor for quite a while. I doubt that the 3D audio in the i.MX 8M Plus will be used, since the Librem 5 already has an advanced audio chip. The Cortex-M core might be great as a processor in low-power mode, but I doubt that will be supported any time soon.
The real advantages I see are that the CPU in Fir will be 20% faster and it will consume less energy than in Evergreen. Also video hardware encoding will make Fir a lot more energy efficient and cooler when shooting video (but it will only be 1080p max resolution video).
However, the tradeoff is that the GPU in fir will be less powerful and the smaller L2 cache probably will hurt performance to some degree. If you play 3D games or want to use the Librem 5 as a PC, you probably are going to prefer Evergreen over Fir. In theory the hardware in Evergreen will support 4Kp video out so it can take advantage of the 4K video decoding whereas Fir is limited to 1080p hardware video decoding. Of course, we don’t know the thermal limits or what will be supported in Evergreen, so its better GPU and better video out might be meaningless in the real world.
Over the long term, we might get the software to take advantage of the NPU and DSP and the better Cortex-M core in fir and it is awesome that NXP is guaranteeing 15 years of production, because that means 15 years of Linux driver updates from NXP. Fir will probably be supported for longer than any phone in the world, but I do have to wonder if anyone will want to carry around the clunky thing 15 years from now.
Thank you very much for this easy to understand overview! IMO, it is definitively to early to have any expectations concerning the i.MX 8M Plus as Librem 5v2 main processor. It might be that Purism (if and when able to get first samples) decide to go with the MIMX8ML6xVNxZAA variant without NPU, but not necessary (I’ve no clue). 1080p60 H.265/4 HW video decode and encode is just fine for my next smartphone, as I’m accustomed “in the real world” usage. As you already determined and compared all necessary, here is just quick view into several product derivatives of this brand new NXP processor:
In a sense, you can already do that, as everything is under your control.
You could probably do something like “if the microphone kill switch is off, then use the volume buttons to do x and y instead of volume control”
I’d also be interested to see how hard it is to use the gyro-sensor to detect gestures like “double tap on the back” or so.
Sure. That’s why I linked it with the state of a killswitch, so you could switch how the volume control behaves. You could also link it with other states (home screen, screen is tapped) or activities (zoom in camera apps is common).
Admittedly, an additional button has more freedom.
That’s why gryo senser patterns are also interesting.
Or hey, the proximity sensor Double tap it to take a picture or something like that.
On Pinephone, SXMo operating system uses “volume up/down” and “power” buttons for navigating the menu (up/down and enter). It works amazingly well and is quite convenient.
“I would like to accept an incoming call via enabling microphone kill switch” - that was what I thought some month ago. Owning the phone seams to make a huge difference in how we mind about device functionality.
But “double tap on the back” sounds really nice. You tell your friends you phone PIN to unlock screen and let them try to unlock. Nothing happens. You take the phone, enter same numbers, double tap the back and your friends don’t even realize, that this double tap is an “enter” command.
I can imagine that gryo sensor patterns could be really nice for some better use cases. But how difficult is it to design different pattern to avoid using wrong commands or using commands when you didn’t want to do anything?
Double tap it to take a picture or something like that.