[Testannounce] Librem 5 Update: Shipping Estimates and CPU Supply Chain
testannounce at announce.puri.sm
testannounce at announce.puri.sm
Thu Jan 14 10:28:29 PST 2021
The Librem 5 Mass Production Shipping
Librem 5 Update: Shipping Estimates and CPU Supply Chain
------------------------------------------------------------------------
Librem 5 Packaging
It’s been a busy holiday and New Year’s season at Purism as we continue
to ship out Librem 5s to backers each week. We know for those who
haven’t received their Librem 5 yet, what they most want to know is when
their Librem 5 will arrive. In summary, *we will be providing shipping
estimates within the next week to the backers within the original
crowdfunding campaign (orders through October 2017), but not all backers
yet, based on our confidence in the estimates*. The rest of this post
will explain what is going into our shipping estimates, and why we can’t
yet provide shipping estimates to every backer.
When we published the shipping FAQ
<https://puri.sm/posts/the-librem-5-mass-production-shipping-faq/> we
explained some of the factors in the shipping calculation:
That calculation depends not only on their place in line, but also
on our knowing our average and maximum weekly phone throughput in
advance, which we don’t expect to know until we are at least a few
weeks into the process. We expect to have a good idea on these
projections by the end of the year, however.
Now we are happy to say that we not only have a good idea on our
shipping throughput, we actually *exceeded our expectations* for how
many we could ship! So hopefully by the end of this week, or possibly
the beginning of next week, we will be contacting a large group of
backers who we feel we can provide a reliable shipping estimate. Note
that this will be a separate email from the emails we already send out
each week to confirm shipping information to the next group of backers
who are ready to receive their Librem 5.
The Road to Shipping Parity
Back when we published the shipping FAQ, we expected that by this point
we would be able to provide every backer with an accurate shipping
estimate and be able to predict when we would hit shipping parity–the
moment when all of the backlog has cleared and a new order would be
fulfilled in our standard 10-business-day window. Once you know how many
Librem 5s you can ship in a week, it seems like it would be a relatively
straightforward calculation to apply that to a person’s place in line
and estimate a shipping date.
Making Librem 5 Just In Time
In our case the calculation is a little more complicated due to the fact
that we employ a “Just In Time” manufacturing process for the Librem 5s,
which is pretty common in the industry. We estimate our shipping
throughput and make slightly more Librem 5s than we think we can ship in
a period of time. The next manufacturing run of Librem 5s then arrives
around the time we complete shipping out the previous run. This has a
few benefits, but the main benefit is if we were to identify a hardware
problem in the existing Librem 5 manufacturing process (whether a
systemic flaw, or a flaw in a particular manufacturing run) it impacts a
smaller number of Librem 5s and can be fixed for future batches.
So when making these shipping estimates, we not only factor in our
shipping throughput, but also the size of future manufacturing runs,
which we now are increasing based on the fact we’ve exceeded our initial
estimates. We can then calculate which run a particular order would be
in, when we will make that next set of Librem 5s, and be able to
estimate when a particular Librem 5 will ship. We also factor in and
plan for events like Chinese New Year, which cause essentially
everything in China to shut down for a few weeks.
CPU Supply Chain
One downside to using Just In Time manufacturing is that you must factor
in all of the different lead times for all the different individual
components that go into the Librem 5. While some components have
relatively short lead times, others sometimes have lead times extending
out multiple months. You have to factor all of this in to ensure that
everything is ordered in advance so that it arrives just when you need it.
If you talk to anyone in manufacturing they will tell you that this has
been a particularly challenging year for the supply chain. Whether you
are talking about toilet paper, N95 masks, rubber gloves, or
semiconductors, the global pandemic has made supply chains less
reliable, and lead times and shipping times incredibly unpredictable.
It’s left everyone in the industry scrambling from source A to B to C
down to Z sometimes to find inventory. It even added a delay a few
months back to our Librem 14 timeline due to Intel having trouble
fulfilling all of their CPU orders.
Our customers have told us they want ever more information on what
happens behind the scenes of making a phone like the Librem 5, so in the
interest of transparency we are sharing what we’ve been hearing from our
own suppliers. The iMX-8 processor we use in our Librem 5 is also
popular in the automotive industry, and currently NXP has been hit with
a global semiconductor shortage due to a dramatic increase in demand
from auto makers
<https://todayheadline.co/car-manufacturing-hit-by-global-semiconductor-shortage/>.
This shortage has increased the lead times for CPU orders, which is of
course a critical component in the Librem 5. As we started getting word
about this shortage we were proactive in sourcing and purchasing all the
CPUs we can, and continue to do so, while also factoring these increased
lead times into future orders.
What Does This Mean For Me?
What does this mean for you? Based on our efforts thus far there’s a
good chance it will not affect your shipping time as we continue to
track down new CPU supplies and plan for future manufacturing runs. So
far it hasn’t caused a delay.
However we wanted to let everyone know about this potential issue far in
advance, because it /will/ impact how many people get shipping
estimates. We only want to send shipping estimates when we *know for
sure* we have the CPUs to fulfill them, so this week instead of sending
estimates to everyone like we had planned, we are only sending estimates
out up to the point we have CPUs that will arrive just in time. This
happens to coincide with all the orders placed through October 2017–the
end of our original crowdfunding campaign.
As we secure more CPU supply, and feel confident about the supply chain
for future manufacturing runs we will send out additional shipping
estimates. Hopefully soon we will be able to account for the whole
backlog and can calculate when we hit shipping parity.
Certification Update
We’ve also gotten some questions about the various hardware
certifications for the Librem 5 including Respect Your Freedom (RYF),
FCC and CE. While we designed the Librem 5 to qualify for each of these
certifications, we had to wait to start the certification processes
until we had the final mass-produced “Evergreen” Librem 5 since changes
in the hardware would require re-certification.
Each of these certification processes are under way. While the
transmitters in the Librem 5 (the removable cellular modem and WiFi
card) already have FCC and CE certification, we are seeking
certification for device as a whole. We are still in the middle of these
time-consuming certification processes and will post an update to our
site when there is any news on any of these fronts.
Thank You
We want you to have your Librem 5 as soon as possible and appreciate
everyone’s patience as we continue to process orders and get through our
backlog. It’s everyone’s support through this monumental process that
has made the Librem 5 a reality.
The Future of Software Supply Chain Security
All indications are that software supply chain security will be the
biggest issue for the security industry in 2021. The largest security
story of 2020 was the supply chain compromise of SolarWinds Orion
<https://us-cert.cisa.gov/ncas/alerts/aa20-352a> which allowed attackers
to ship malicious updates with backdoors to Orion customers with
perfectly valid signatures. Once these updates were applied and
attackers were in these networks, this access allowed a large-scale
attack of government agencies and tech and security companies, perhaps
one of the single largest attacks of US networks in history. In some
cases the level of compromise was so deep, including compromised
administrator credentials, that the general guidance has been for
victims to /rebuild infrastructure from the ground up/.
Supply chain security is not a new concept (I wrote about how Purism
protects the digital supply chain
<https://puri.sm/posts/protecting-the-digital-supply-chain/> over two
years ago) and many researchers have recognized it as a legitimate
threat for a long time. Yet the industry overall has been slow to
recognize the risk and in fact perverse incentives have led to many in
the industry doubling-down on security solutions that rely heavily (in
many cases rely entirely) on the exact kind of security measures supply
chain hacks defeat.
*The proprietary software industry can’t fix the software supply chain
problem* because they largely created it and depend on it to maintain
control over customers. In this article I’m going to explain how this
happened, and what the future of supply chain security looks like.
Perverse Incentives
The core problem with the security industry is the perverse incentives
that drive security architects to design solutions where security is a
secondary effect or sometimes even a marketing excuse, when the main
priority is to increase a customer’s dependence on the vendor. The
majority of professional security architects out there use the same
playbook, and are unable to design secure software without falling back
to chains of binaries signed with vendor keys.
There’s nothing wrong with code signing as a security measure when it’s
limited to its intended purpose: a “seal of approval” assuring a
customer that software has not been changed after it left a vendor. This
seal is especially important when you are shipping software in binary
form since you can’t as easily audit that software for malicious changes
like you can with source code. Code signing is a widespread practice and
even Linux distributions use it as a way for users to verify software
packages came from that project.
The problem with code signing is in how it has been extended to exert
control. In addition to verifying whether software has been modified,
those signatures are also used to enforce policies that only allow
software to be installed or to run
<https://puri.sm/posts/apple-users-got-owned/> that the vendor
explicitly approves. The proprietary software industry is dependent on
code signing with vendor keys as the foundation for most if not all of
its security, because it enables vendors to exert this control over
their customers in the name of security.
Exerting Control
Nowhere do these perverse incentives have a stronger impact than the
smartphone industry, which has become the test bed for the most advanced
applications of code signing to exert control, with Apple at the
forefront. In the name of security, every piece of software you install
or run on an iPhone must be approved by Apple. They act as the
gatekeeper over what’s allowed in the App Store and can revoke
previously-approved applications from competitors
<https://www.nytimes.com/2019/06/03/technology/apple-parental-control-apps.html>,
which has led to lawsuits
<https://en.wikipedia.org/wiki/Epic_Games_v._Apple> and anti-trust
hearings
<https://observer.com/2020/07/apple-ceo-tim-cook-congress-antitrust-hearing-app-store-iphone-monopoly/>.
In the beginning this control was enforced by comparing code signatures
in software, but as customers have gotten more sophisticated in their
ability to bypass this control (literally called /jailbreaking/ because
these controlled environments are called jails), vendors have
doubled-down on code signatures backed by specialized hardware. From the
moment the computer starts, code is sent to this hardware for
approval–only if signatures match vendor approval does this hardware
allow it to run.
While the explanations for these sophisticated measures is
security–stopping hackers and even governments from breaking into your
computer–the reality is that the majority of the time these measures
just prevent end users and competitors from doing something the vendor
doesn’t like. Worse, this approach anchors all security and all trust in
the vendor and their signing keys. Compromise a signing key and the
whole house of cards falls down.
The House of Cards
Most security experts agree that end-to-end (e2e) encryption (where only
the two endpoints control the keys) is the best way to secure
communication between two people. Experts also almost universally agree
that adding an /encryption backdoor/–an extra key controlled by the
vendor or handed over to authorities that can unlock e2e encrypted
messages–cannot be done securely. This is because there is no such thing
as a backdoor only authorities know about. Even if you trusted
authorities to have a key, eventually attackers will get access or
otherwise compromise that key and then the security of all of these
previously-secure messages is defeated.
This, by the way, is why the NSA is known tostore encrypted
communication automatically and indefinitely
<https://www.propublica.org/article/nsa-data-collection-faq>. Even if
they can’t decrypt it today, they might be able to decrypt it
eventually, due to a future flaw discovered in the encryption, or the
disclosure of the key.
Ironically, many of the same experts who speak out against encryption
backdoors, design security systems that *anchor all trust in their
company’s signing key*. Little effort is spent designing systems that
can detect and respond in the event a signing key gets compromised. Yet
we know these keys get compromised, and between the Stuxnet
<https://arstechnica.com/information-technology/2017/11/evasive-code-signed-malware-flourished-before-stuxnet-and-still-does/>
malware and the SolarWinds Orion supply chain compromise we have two
large-scale global examples of how high security systems can be
compromised for months without anyone knowing, when they blindly trust
key signatures.
This contradiction between what security experts say is secure and what
they design for their companies illustrates how perverse incentives
compromise secure design in favor of control. Improving supply chain
security requires giving up some or all of this control, which is why
you will likely not see real solutions come from proprietary software
vendors.
Canned Solutions
We could learn a lot about how to secure the software supply chain from
how we secure the food supply chain, and in my article Protecting the
Digital Supply Chain
<https://puri.sm/posts/protecting-the-digital-supply-chain/> I draw many
analogies between them:
The food supply chain is important. Food is sealed not just so that
it will keep longer, but also so that you can trust that no one has
tampered with it between the time it left the supplier to the time
it goes in your grocery bag. Some food goes even further and
provides a tamper-evident seal that makes it obvious if someone else
opened it before you. Again, the concern isn’t just about food
freshness, or even someone stealing food from a package, it’s about
the supplier protecting you from a malicious person who might go as
far as poisoning the food.
The supply chain ultimately *comes down to trust* and your ability
to /audit/ that trust. You trust the grocery and the supplier to
protect the food you buy, but you still check the expiry date and
whether it’s been opened before you buy it. The grocery then trusts
and audits their suppliers and so on down the line until you get to
a farm that produces the raw materials that go into your food. Of
course it doesn’t stop there. In the case of organic farming, the
farmer is also audited for the processes they use to fertilize and
remove pests in their crops, and in the case of livestock this even
extends to the supply chain behind the food the livestock eats.
If the food supply chain worked like the proprietary software supply
chain, we’d buy food in opaque jars with a factory tamper seal on them,
but without expiration dates, ingredient lists, food allergy warnings,
or nutritional information. The factories would never get inspected for
cleanliness or audited to see if they use spoiled ingredients or
processed peanuts in the same facility. Most importantly, we wouldn’t be
able to check the food ourselves beyond that tamper seal–we wouldn’t
have a sense of smell, taste, or sight. The only way we’d know if the
food was tainted is by eating it and waiting to see if we get sick.
The Future is Clear
To improve software supply chain security we need the ability to audit
software like we audit food and this requires much more
transparency–*transparency beyond what proprietary software vendors
allow*. Tamper seals (code signing) are important, but not close to
being sufficient to catch tainted software. As the SolarWinds Orion hack
shows, food can be tainted at the factory before it gets into those
tamper-sealed jars.
The software supply chain will get attacked, and third parties and
motivated customers must have the ability to detect tainted code
quickly, beyond simply relying on their vendor to notice, looking at a
tamper seal, or waiting to see if their network gets sick. The best hope
we have to improve supply chain security is in the combination of free
software and Reproducible Builds <https://reproducible-builds.org/>.
Free Software
At the initial level free software and proprietary software use similar
security measures to protect against supply chain attacks. A software
repository is owned by a limited list of maintainers who control what
source code and files are allowed in the repository and approve all
changes. Both free and proprietary software developers these days
typically sign their code changes with a personal signature verifying
that the change came from them. When the software gets packaged, that
binary package is also typically signed with a key owned by the company
or software project so the end user can verify that the package hasn’t
been modified by anyone else, before they install it.
Free software adds an additional layer of supply chain security that
proprietary software simply can’t, due to the freedom of the code. While
an attacker can try to sneak malicious code into the source code itself,
it’s much more challenging to hide that code long-term, given that code
changes are not only audited by the software maintainers themselves, but
any interested third party as well as security researchers and even
regular end users. While some security researchers are just as
comfortable auditing binaries as source code, for many it’s a lot easier
and faster to audit code for backdoors when the code is freely available.
This is one reason why Purism offers a 100% free software operating
system, PureOS
<https://puri.sm/posts/why-fsf-endorsing-pureos-matters/>, on our
computers. By only installing free software, all of the source code in
the operating system can be audited by anyone for backdoors or other
malicious code. For processed food to be labeled as organic, it must be
made only from organic sources, and having our operating system
certified as 100% free software means you can trust the software supply
chain all the way to the source.
Reproducible Builds
Unlike proprietary software, free software can also address the risk
from an attacker who can inject malicious code somewhere in the build
process before it’s signed. With Reproducible Builds you can download
the source code used to build your software, build it yourself, and
compare your output with the output you get from a vendor. If the output
matches, you can be assured that no malicious code was injected
somewhere in the software supply chain and it 100% matches the public
code that can be audited for backdoors. Think of it like the combination
of a food safety inspector and an independent lab that verifies the
nutrition claims on a box of cereal all rolled into one.
Much of PureOS is already reproducibly built, and we are working so that
ultimately all software within PureOS can be reproducibly built starting
with the base install and expanding from there. We not only intend on
publishing our own reproducible build results, but also tools and
guidance so third parties and customers can perform their own audits.
That way, customers aren’t limited to learning about supply chain
attacks from us, they can audit and detect attacks themselves.
Global Collaboration and Investment
While free software and Reproducible Builds don’t prevent supply chain
hacks entirely, they make those attacks much more difficult to hide and
provide valuable methods of detection you can’t find anywhere else. For
instance, in the case of the SolarWinds Orion supply chain attack, if it
had used free, reproducibly built software, third parties could have
compared the tainted binary against their own audit infrastructure and
detected the compromised software update within hours. Instead, the
attack was only noticed over a year later
<https://thehackernews.com/2020/12/new-evidence-suggests-solarwinds.html>
when FireEye was investigating a hack
<https://www.msn.com/en-us/money/other/fireeye-stumbled-across-solarwinds-breach-while-probing-own-hack/ar-BB1bVFWr>
that released their own internal tools.
If critical software were free and reproducibly built, even if companies
didn’t audit every binary they get from a vendor, they might at least
audit their highest-risk third-party software with the most access
inside their network. Given the cost of repairing the damage from these
kind of supply chain attacks on government and private infrastructure,
building this audit infrastructure for critical software seems like a
wise investment. The load could also be distributed among public and
private agencies across the world, starting with critical software
projects and expanding beyond that as resources allowed.
Over the next year or two you will likely see many vendors touting
proprietary solutions for supply chain security that coincidentally
require you to anchor all trust in them. *Solutions to this problem
won’t come from proprietary software and can’t come from any one
vendor*, it requires a collaborative approach that gives customers more
control over their software, and grants them and independent
third-parties the ability to audit the supply chain themselves.
Purism and Linux 5.8
Following up on our report for Linux 5.7
<https://puri.sm/posts/purism-and-linux-5-7/> this summarizes the
progress on mainline support for the Librem 5 phone and its development
kit during the 5.8 development cycle. That was already a few months ago.
We missed publishing this earlier and the recent development cycle
summaries will follow shortly.
Devkit updates
The Librem 5 devkit saw a minor update that will save some power:
arm64: dts: imx8mq-librem5-devkit: Use 0.9V for VDD_GPU
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76eceb0f3696a2021f407a5e649aa36d08a61be5>
arm64: dts: imx8mq-librem5-devkit: Don’t use underscore in node name
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9251dad3a3e5ed72cfb30ec27a4e569527e6f10f>
USB power management
Runtime power management in the USB stack is quite mature and well
supported. We added one piece for the Designware DWC3 hardware IP that
has been missing: support for runtime power management when devices are
connected and disconnected on an external bus:
usb: dwc3: support continuous runtime PM with dual role
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c2cd3452d5f8b66d49a73138fba5baadd5b489bd>
Librem 5 Light and Proximity Sensor
During a phone call, the Librem 5 naturally might be near the user’s
ear. We added a new interface to Linux to allow userspace to decide when
an object is close to the device and added support for the vcnl4000
proximity sensor:
Documentation: ABI: document IIO in_proximity_nearlevel file
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aa8cb0485594d8b3c9bfe7f4427b3ae26187c861>
iio: vcnl4000: Export near level property for proximity sensor
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f5a98e1fca15cbf79f50098ea30e84ce33da2fd6>
dt-bindings: iio: light: vcnl4000: Add proximity-near-level
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=138986062b50e7e24404e279d2e2c79c0291dac3>
dt-bindings: iio: Introduce common properties for iio sensors
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=445b16fb6bdc2cd3086a8d9018b4f325c89faa24>
dt-bindings: iio: vcnl4000: convert bindings to YAML format
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c194e2389d99be2fc69811693775b81f9ab88f6c>
Librem 5 Display stack
Certainly, our largest addition during this development cycle has been
adding support for the NWL MIPI DSI controller. For the devkit, this
marks the last piece that has been needed for the mainline kernel to
support the full display stack. The Librem 5 phone is one-panel driver
away from having the same:
drm/bridge: Add NWL MIPI DSI host controller support
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=44cfc6233447cb2cf47aeb99457de35826a363f6>
dt-bindings: display/bridge: Add binding for NWL mipi dsi host
controller
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6885e66bc0e7bb073246dde73ddf534102dd4533>
Code review
This round we contributed 6 /Reviewed-by:/ or /Tested-by:/ tags to
patches by other authors. Something we can still improve on for upcoming
cycles.
Purism and Linux 5.9 and 5.10
Following up on our report for Linux 5.8
<https://puri.sm/posts/purism-and-linux-5-8/> this summarizes the
progress on mainline support for the Librem 5 phone and its development
kit during the 5.9 and 5.10 development cycles.
Librem 5 updates
One of the most notable additions is a first devicetree description for
the phone. This is important to have upstream since it describes how the
hardware is wired up. Without that, it’s impossible to boot a mainline
kernel. We added descriptions for the various phone revisions themselves
(up to the Dogwood board) and also for the MIPI DSI controller of the
imx8mq SoC. From this point on, we’ll incrementally add the missing
pieces, for example from the display stack, just like we’ve done for the
devkit back in Linux 5.2.
* dt-bindings: arm: fsl: Add the Librem 5 phone
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=32b0aaa59da62a5b4c2f3e7ca44f10853259572b>
* arm64: dts: Add a device tree for the Librem 5 phone
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8f0216b006e5f553d28c4c1a991b5234693a49cb>
* arm64: dts: imx8mq: Add NWL MIPI DSI controller
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d0081bd02a037c1b867c4d3a5cb0878fb321cb08>
Librem 5 LCD panel
Speaking of the display stack: The phone includes a different LCD panel
than the devkit and we had to add a driver for it:
* dt-binding: display: Require two resets on mantix panel
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2580a493a97da4a302cb66251b558bfc04c16e68>
* drm/panel: mantix: Fix panel reset
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6af672523fe4bd71f5e70c50258fd0fc09663fae>
* drm/panel: mantix: Don’t dereference NULL mode
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=938f324e7df25e89226c6fe137028af73cd6160b>
* arm64: defconfig: re-sync DRM related defconfig bits
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6ab28d61fe45c9a0dc5da728091934dc40f9791f>
* drm/panel: Add panel driver for the Mantix MLAF057WE51-X DSI panel
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=72967d5616d3f0c714f8eb6c4e258179a9031c45>
* dt-bindings: Add Mantix MLAF057WE51-X panel bindings
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b9ab1248d801bfa4fb7c35762d172455cf3795f1>
* dt-bindings: vendor-prefixes: Add mantix vendor prefix
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=faa962bbae312eaf84838bbdc96ccc216ba248ef>
* drm/mxsfb: Make supported modifiers explicit
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f4b29bf77319df18348b56e9fd87bc7d4266220e>
Devkit updates
Another milestone we reached (and had promised earlier) is that the
devkits’ display now works with mainline Linux directly. All needed
drivers are there and the hardware is described accurately in the
devicetree upstream. It’s not only nice to be able to use a mainline
kernel without (m)any patches, it’s important in order to keep the
hardware supported for a long time. The hard parts had been done before
and that’s how the final pieces for the display look like:
* arm64: dts: imx8mq-librem5-devkit: Enable the LCD panel
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e8151ef3578c9529f1b69f08bfcfd1e67e676e82>
* arm64: defconfig: Enable imx8mq-librem5-devkit display stack
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c08ed48c9563d93dd4a64dada9d551c85e6cf0e>
* dt-bindings: panel: rocktech,jh057n00900: Add myself as maintainer
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5f374e63d214a1e1cfaff9575fa34f27b046d54c>
* dt-bindings: panel: rocktech,jh057n00900: Modernize
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=087e3d479155a18ff57f294c04e33c5ac7d6f50a>
Audio Codec
The wm8962 audio codec needed a small update to allow userspace to
utilize hardware mono downmix for cases where mono output to a single
speaker is desired only, like on a mobile phone:
* ASoC: wm8962: Export DAC/ADC monomix switches
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=89383a2707e54b39e01407fb611662d131551bb2>
Code review
During these rounds, we contributed 24 /Reviewed-by:/ or /Tested-by:/
tags to patches by other authors. Also, we would like to thank everybody
who reviewed our patches and helped us, especially Sam in the DRM layer
and Shawn and Krzysztof in the devicetree area. It’s supposed to be fun
but we know it not always actually is, so that’s much appreciated.
Sources
Have a look at our Linux tree
<https://source.puri.sm/Librem5/linux-next> to see what is currently
being worked on and tested (or help if you feel like joining the fun).
App Showcase: Weather
Weather apps are one of the few apps people use every day that needs a
location to work, but weather apps on most smartphones are notorious for
capturing and selling your location data
<https://www.vice.com/en/article/gy77wy/stop-using-third-party-weather-apps>.
The Librem 5 is designed to protect your privacy, and include a
privacy-respecting Weather app <https://wiki.gnome.org/Apps/Weather>.
When opened this retrieves weather data from the Norwegian
Meteorological Institute <https://www.met.no/en>, and only them.
The Norwegian Meteorological Institute has a free and open data policy
with the goal of benefiting society, in many ways similar to our ideals
at Purism.
Sorry, your client doesn't seem to support embedded videos. View the
video directly here <https://videos.puri.sm/promo/weather_v2.mp4?_=1>
Weather features an hourly overview, as well as a 10-day forecast.
As you would expect on a privacy device, you can disable automatic
location and enter your position by hand.
App Spotlight: Sound Recorder
Sound Recorder is simple to install and a powerful way to record in the
studio or on the go:
Sorry, your client doesn't seem to support embedded videos. View the
video directly here
<https://videos.puri.sm/promo/sound_recorder_v2.mp4?_=1>
The app itself is deceptively simple, it offloads all of the audio
device setup and selection to the OS layer, which can be managed in
settings:
With the brunt of the setup automatically handled by PureOS, you can set
up the basics from within the app menu.
Actually using the interface could not be more intuitive. Simply hit
record to record, and click a past entry if you want to listen to it.
A Quiet Solution:
Silence is ideal for any recording studio or sound room. The fans in a
standard x86 computer can impact the end result if kept too close to the
mic. When I first built my sound closet room I cabled long runs of USB
and power to prevent having to use a computer near my mic. This sucked
as I had to print out my script and I couldn’t check the recording
status during the session.
Being able to read the script off a screen and having access to the
audio controls drove me and my roommate to build this fanless monstrosity:
This did the trick for years but did suffer from major stability issues
which were endlessly frustrating to deal with mid recording. Now with
USB-C dock support getting better and better, using the Librem 5 has
solved all my recording issues and has now permanently replaced my sound
room computer.
Purism
Thanking you for your support,
— the Purism team (feedback at puri.sm)
------------------------------------------------------------------------
Note: contents of this email are CC-by-SA; feel free to forward it to
friends!
/To remove yourself from our announcements list, simply email
announce-leave at announce.puri.sm <mailto:announce-leave at announce.puri.sm>
and you will automatically be instructed how to unsubscribe./
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://announce.puri.sm/pipermail/testannounce/attachments/20210114/33160381/attachment-0001.html>
More information about the Testannounce
mailing list