The new PM settings aren't compatible with kernels that don't
handle USB_PORT_QUIRK_NO_SUSPEND.

Set autosuspend delay to 500ms to improve battery life and disable
persist, since we don't gain anything from it as QMI state gets reset
with reenumeration.

PartOf= does not ensure ordering and ssh connections weren't
dropped before stopping this service. Before= does the thing.

Fixes #69

Some people reported that the new settings made the modem less
reliable on their phones. Since a better workaround is coming,
revert back to the old settings to not regress meanwhile.

Turns out that having the fragment size be larger than 22 ms
triggers a bug in Waydroid breaking it audio. Since this is
a balance between latency and possibility of underruns
occuring, let's reduce the recently bumped fragment size by
a tiny bit to make Waydroid happy, resulting in latency lowered
by 4 ms as a bonus.

Reencryption happens before resizing, so it only takes
about two minutes on the phone.

In order to use it, initial LUKS dump needs to be stored
on the rootfs:

    mkdir -p /var/lib/reencrypt
    LUKSDEV=$(cryptsetup status crypt_root | awk -F: '$1~/device/ {gsub(/^[ \t]+/, "", $2); print $2}')
    cryptsetup luksDump $LUKSDEV > /var/lib/reencrypt/dump

Citing Wikipedia [0]:

    Of these protocols [RNDIS, ECM, EEM and NCM] ECM could be classified
    the simplest - frames are simply sent and received without modification
    one at a time. This was a satisfactory strategy for USB 1.1 systems
    (current when the protocol was issued) with 64 byte packets but not for
    USB 2.0 systems which use 512 byte packets.

We're already using USB 3.0, so we should switch away from ECM.
Reasonable alternatives include EEM and NCM (RNDIS is a proprietary
Windows protocol, which - although supported by Linux - is considered
unsafe and may get removed [1]).

Bandwidth tests with iperf3 gave me these results:
 - ECM: 526 Mbits/sec
 - EEM: 761 Mbits/sec
 - NCM: 1.67 Gbits/sec

While NCM is newer, it's been supported in Linux since 2.6.37 already,
which is quite ancient by today's standards, so switching to it
should be safe for any kind of reasonably modern Linux host (plus we still
expose ACM serial that will be available even if NCM is not supported,
so basic communication with the device will still be possible).

It also has an added bonus of being supported in Windows 10 and
later, while ECM and EEM aren't supported there at all.

Therefore, switch the Ethernet gadget to use NCM.

[0] https://en.wikipedia.org/wiki/Ethernet_over_USB
[1] https://lore.kernel.org/lkml/20221123124620.1387499-1-gregkh@linuxfoundation.org/

This way it does not rely on the block device being named "sda".

This appears to reduce frequency of BM818's USB resets.

With 16ms the are occasional underruns happening when using
mpv with DRAM at 25MHz.

Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>

No functional change; this only prevents user changes from being
overriden at each UCM profile switch.

Full ALSA state reset is already performed when updating from
the old incompatible profiles, so that's not a concern here.

hciattach isn't aware that the card gets reset at system suspend, requiring
full reinitialization, so it needs to be restarted. Unfortunately,
I haven't found a way to describe such relation using systemd unit
relations alone that wouldn't break things, so a system-sleep hook
is added to stop the service before going into suspend.

The service itself is also tweaked to better handle errors and to make
it restartable (previously it would require the card to be reset before
hciattach could work again).

Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>

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

squeekboard 1.20.0-2 from Debian will use update-alternatives to manage
the /u/s/a/sm.puri.OSK0.desktop finally allowing us to obsolete
osk-wayland here.

We do so by making sm.puri.OSK0-legacy.desktop use update-alternatives
too and giving it a lower priority than squeekboards.

As older squeekboard in PureOS Byzantium doesn't worry about
sm.puri.OSK0 at all so an update of librem5-base-defaults won't change
anything for the user.

We can drop sm.puri.OSK0-legacy and osk-wayland for Crimson

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

Don't rely on what a debhelper snippet does

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

Otherwise we won't have debhelper snippets inserted

Fixes 664324e4

Now that `sensors` outputs reasonable values as well we can safely have
people remove  it. gnome-usage has a separate Recommends: releationship
so it's can be dropped completely for crimson.

It can be way too trigger happy, leading to lots of distortion.

module-echo-cancel already does HPF on its own for call audio, and
such a strong filtering is not desired in general use case.

Otherwise, systemd drop-ins aren't registered until a reboot
or manual reload.

This prevents the old asound.state file to be loaded with outdated
values that are potentially incompatible with the new UCM.

As an added bonus, allow the state to be reset when the user deletes
the librem5.state file manually and reboots - previously
alsa-restore.service would simply regenerate the state file on
shutdown, making it hard to intentionally reset the state.

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.