Otherwise the new UCM will unconditionally favor wired microphone
input even if none is connected.

Requires linux!583

It appears that BM818 is applying some kind of gain on its own, leading
to distorted sound on the other end even when the local microphone
volume isn't anywhere near being clipped. Provide it with quieter audio
to avoid clipping at the modem end.

This is a bigger overhaul of the profiles inspired by studying WM8962
datasheet and debugging issues with PulseAudio.

Aside of a general cleanup, it changes several things aimed to improve
audio quality on both inputs and outputs.

The new profile:
- allows PulseAudio to use hardware volume control and makes sure that
  PGA gains are user-configurable
- makes sure Zero-Cross feature is enabled for all relevant input and
  output paths
- enables High-Pass Filters to protect the speakers from potential damage,
  get rid of DC offset and to improve input speech legibility
- minimizes the amount of gains used in various paths
- makes "Speaker" profile use both speakers, each with the same downmixed
  mono signal, which improves volume and frequency response
- uses HD Bass feature for improved lower frequency response of internal
  speakers
- uses only the bottom microphone by default and duplicates it into both
  stereo channels (and creates a new "stereo microphones" device, so users
  can still access both microphones when desired)
- duplicates analog microphone signal into both stereo channels
- enables High Performance modes for better signal to noise ratio
- uses Dynamic Range Control for input path to control signal level
  and attenuate background noise

Sparklan cards require the FW

Signed-off-by: Angus Ainslie <angus@akkea.ca>

Guido Gunther authored 2 years ago and Guido Gunther committed 2 years ago

With that we get

  PIN code for L5 built-in SmartCard Reader 00 00:

for pin prompt and for `--card-status`:

    $ gpg --card-status
    Reader ...........: L5 built-in SmartCard Reader 00 00
    Application ID ...: D2760001240103030005000091000000
    Application type .: OpenPGP
    Version ..........: 3.3
    Manufacturer .....: ZeitControl

rather than

  PIN code for TTXS serial 00 00:

which doesn't give much information in case of multiple SC readers.

It's not launched automatically atm but we can pull it in so people can
find it.

The default of 4 fragments of 25 ms results in 100 ms latency, which is
noticeably high, especially when moving audio between two cards (SoC and
modem) as the latencies add up. Librem 5 appears to be perfectly capable
of dealing with lower latencies, so let's reduce it to 32 ms.

This is a somewhat conservative choice, as there are lower values that
still appear to work well, but going lower increases the chances of
underruns happening under load, so we may want to wait until we scale
DRAM frequency up dynamically to not regress on playing audio with screen
locked use-case.

When lockdown mode (all hks enabled, hardware for sensors disabled) is
entered, unload modules for lsm9ds1 and unbind vcnl4000. If one hks is
disabled and sensors become available again load lsm9ds1 modules and
bind vcnl4000.

Background: the drivers do not detect the hardware being disabled and
re-enabled. This leaves the sensors for proximity, light and acceleration
in an unsusable state.

This commit fixes:
* linux#436
* linux#431

This commit removes the work by @martin.keppling for vcnl4000 only and
integrates it into the new lockdown-support.sh script.

**/etc/modprobe.d/librem5-lsm9ds1.conf** blacklists the lsm9ds1 modules to
be not loaded on boot. Otherwise the sensors will become unsuable if
during boot lockdown mode had been enabled.

**lockdown-support.sh** checks for the state of the hks before loading the
lsm9ds1 modules and binding vcnl4000 when any hks is disabled and
unloads the lsm9ds1 modules and unbinds vcnl4000 if all hks become
enabled.

**librem5-lockdown-support.service** is started on boot to run
lockdown-support.sh once.

**librem5-lockdown-support.udev** calls lockdown-support.sh each time a hks
is toggled

Thanks a lot to @evangelos.tzaras, @guido.gunther and @martin.kepplinger
for leading me through the process of generating a clean commit and all the
corrections and help to improve this commit.

Sebastian Krzyszkowiak authored 3 years ago and Angus Ainslie committed 2 years ago

This will be handled by a separate package.

This reverts commit 6e5434be.

With epiphany currently having problems we should *additionally* install
firefox-esr. We should install it by default especially because FF does
not show up in PureOS Store causing users having to install from the
terminal which is not the best out of the box experience.

For the PureOS issue see
https://tracker.pureos.net/T1108

Closes: #63

This configures USBGuard to only accept allowlisted USB devices
appearing on the internal bus, and to accept everything on the
external bus.

Since g-s-d has USBGuard support that rejects devices attached
while the screen is locked, let's disable it by default for now
to not introduce potentially breaking UX changes. It can be
reenabled once it's properly configured and well-tested for our
use cases.

This makes the smart card reader operational out-of-box.

Currently, pcscd doesn't shut down automatically when used
in conjuction with scdaemon, which keeps the reader powered
on even if unused, but this happens only when there's
a valid card inserted and after the first use of the reader,
so it's been decided that it's an acceptable price for having
it work out-of-box right now.
See: OS-issues#263

This creates a swap device backed by compressed RAM with size
of 50% available RAM.

Martin Kepplinger authored 3 years ago and Guido Gunther committed 2 years ago

the light sensor is being cut off when wwan-hks, wlan-hks and camera-hks
are being switched off. it's powered again when only one of these 3
hks are being switched on again - any one of them.

Since I couldn't come up with a simple rule that does such an "OR"
relationship, this runs a script on every HKS on-switching. That
script then checks whether only 1 or 2 rfkill devices are unblocked
(the wifi HKS or the camera/mic HKS each unblock 2 rfkill devices).

In that case, it reloads the vcnl4000 driver to make illuminance and
proximity values work again.

Using the terminal on the phone with no tab completion is painful,
let's make it a bit easier out-of-box.

Locale generation on Librem 5 is slow enough that the default of
3 minutes can kick in pretty easily with just a few locales
added over the default, causing locale selection in g-i-s and
g-c-c to not work for new locales anymore. Bump it up to 10 minutes
which should be generous enough.

Seems like a good idea.

Aside of spi_nor, imx_sdma is needed for NOR to probe at all; and
ofpart is needed for it to create separate partitions as defined
in the device tree.

Sebastian Krzyszkowiak authored 3 years ago and Martin Kepplinger committed 3 years ago

Based on https://source.puri.sm/firmware/ttxs-firmware/-/blob/purism/PURISM.md

Sebastian Krzyszkowiak authored 3 years ago and Guido Gunther committed 3 years ago

With older mesa, enabling 3D acceleration in XWayland causes
massive synchronization issues.

Sebastian Krzyszkowiak authored 3 years ago and Guido Gunther committed 3 years ago

This complements !270 to enable XWayland acceleration, as phoc
itself does not pick up variables set in profile.d.

Steve Stevens authored 3 years ago and Guido Gunther committed 3 years ago

This patch increases the volume from calls (incoming volume, so from the
person calling you) by 50% to bring the call volume to be similar to
that of what you get from the system volume.

the settings are all based on a discussion with Charles:
https://lore.kernel.org/alsa-devel/20220207142129.GB112838@ediswmail.ad.cirrus.com/

Currently we don't get any signal from the external mic. These settings
result in at least a usable signal (we can try to further improve later).

There are 3 Volume controls for the analog parts, all before the ADC.
In order from Jack to ADC, they are:

numid=10,iface=MIXER,name='Capture Volume'
   ; type=INTEGER,access=rw---R--,values=2,min=0,max=63,step=0
   : values=63,63
   | dBscale-min=-23.25dB,step=0.75dB,mute=0

"Input PGA Volume Control". 31=0dB. We use 39=+6dB.

numid=7,iface=MIXER,name='MIXINR PGA Volume'
   ; type=INTEGER,access=rw---R--,values=1,min=0,max=7,step=0
   : values=7
   | dBrange-
     rangemin=0,,rangemax=1
       | dBscale-min=0.00dB,step=6.00dB,mute=0
     rangemin=2,,rangemax=2
       | dBscale-min=13.00dB,step=13.00dB,mute=0
     rangemin=3,,rangemax=4
       | dBscale-min=18.00dB,step=2.00dB,mute=0
     rangemin=5,,rangemax=5
       | dBscale-min=24.00dB,step=0.00dB,mute=0
     rangemin=6,,rangemax=7
       | dBscale-min=27.00dB,step=3.00dB,mute=0

"Right input PGA to Right input Boost-Mixer Gain"
0=0dB. we use 1=+3dB.

numid=8,iface=MIXER,name='MIXINR IN3R Volume'
  ; type=INTEGER,access=rw---R--,values=1,min=0,max=7,step=0
  : values=6
  | dBscale-min=-15.00dB,step=3.00dB,mute=0

we don't use that since we can either route from PGA or IN3R to MIXINR.

("quotes" are from the datasheet)

Guido Gunther authored 3 years ago and Martin Kepplinger committed 3 years ago

dev-tools is not installed often so move to non-gnome-recommends
for e.g. support to gather data with.

5.16.11pureos2 has the audio card name change.

This should work with old and new ucm2

Code lives upstream now

This reverts commit 697a7420 that
disabled system sleep like "systemctl suspend" via systemd since
the kernel had not supported it (The system would in most cases
suspend, but never be able to resume).

Since kernel version 5.16.3pureos1 the kernel supports resuming
from suspend so people can at least start to do tests.

So this simply *allows* to test system sleep via systemd. It doesn't
change any default behaviour.

Keep in mind that

 * there can still be bugs around suspend and resume in general.
   Let's find them together.

 * System suspend means that no data connection is kept alive:
   No receiving of email, xmpp and so on.

 * While the goal is that cellular calls and SMS would wake up
   the system and work normally, that is currently disabled
   on many of the shipped modems. We're working on it and Linux
   supports it already.

 * All policies how to "transparently" use suspend in the future
   are open questions, see for example
   OS-issues#237

 * Compared to "display off standby" we currently have (using runtime pm),
   we can say that system suspend will always save power. How much though
   is highly dependent on what is running and enabled on the system:
   - If the modem is enabled, it stays enabled and can use quite some power
     depending on signal strength. That would *reduce* the amount of power saved.
   - If there are applications running, they will be freezed during
     system suspend, so more open applications would *increase* power saved.