Wake me up before you go-go or better yet, don't

In the few months I have noticed my Fedora notebook wake up in my backpack.  It has also awakened in the middle of the night and by morning the battery was nearly depleted. I first noticed the wake up when I paired another laptop with it.  When the other laptop powered up in to the operating system, my Fedora notebook would wake up.  I made a connection between wake on demand and bluetooth.

Initially I figured I had a device in the house that was paired with it.  I fired up Wireshark on the bluetooth adapter and found that every time that laptop awakened, there was a broadcast event from an Apple device. 

I began to suspect that I had an Apple device paired with it.  I turned off bluetooth from all Apple devices and it still awakened a few seconds later.

However, just the other day I found it awakened readily even far away from my house.

I repeated a Wireshark/bluetooth capture and sure enough, another Apple device.

I investigated wakeup parameters in the /sys tree and found this works to keep the laptop from waking on bluetooth events.

As root: find /sys/devices -name wakeup | grep usb2/2- | while read F; do echo disabled > $F; done

UPDATE 2021-12-31 - I have recently replaced the operating system with a newer release. I will watch and see if the issue persists.

I cannot hear my BUDDY

BUDDY is the system (board) name of an Acer Chromebase.

In September 2021, I procured a Acer Chromebase 24 CA24-CT as a wall-mounted organizational assistant and intercom.  

The project started out nicely with easy hardware upgrades, but went downhill sharply upon discovering that the bdw-rt5650 makes no sound in Linux operating systems.

I started a quest to figure out whether this was pre module (like using a module parm to load specific CODEC parms) or post module, say a mapping from the sound service, like ALSA.

Using my chromegraphy skills from years tinkering with prepping Windows laptops with compatible official builds, I loaded the official latest BUDDY build on to the Chromebase already having flashed in the full MrChromebox UEFI (tianocore) ROM. 

As usual, after preparing a fresh /dev/sda1 (STATE), the recovery screen began the 5 minute countdown, and I chose not to wait, although a person could wait out the timer and it would reboot having applied the necessary STATE changes.

The next step was to unverity the volume.  Using live meda, I did this by loading zram and setting the disksize module parameter (find /sys/devices -name disksize) to the same size as blockdev --getsize64 /dev/{device}3. Then I formatted the zram0, mounted it, mounted /dev/{device}3  "ROOT-A" read-only to a makeshift mount point for /dev/{device}3, rsync -av from /tmp/sda3 to zram0, umount both zram0 and {device}3, and dd from zram0 to /dev/{device}3.

This netted a modifiable ROOT-A and absent verity, means an easy mount from Linux.

The next step was to see if my distro would produce sound with the official Chrome kernel.

I grabbed the kernel modules (4.14.228-37743-g49d2c603c1a5) and nested them under /lib/modules of my Linux distro.  I then rebuilt the initramfs using dracut and attempted to boot my distro, and grabbed vmlinuz.A from the /syslinux directory of /dev/{device}12 "EFI-SYSTEM". I added a boot entry to (EFI) grub and tried to boot but grub presented that the kernel did not accept EFI handover

I switched to using the grub that exists on /dev/{device}12 "EFI-SYSTEM" but all I got was a blank screen - the screen right before the kernel slurps in the boot screen (chrome logo) from the ROOT-A file system.

I did some research and found that Chrome kernels do not use initrds.  Therefore, although the kernel command line has boot=local rootwait ro noresume noswap loglevel=7 noinitrd console= , perhaps I should not expect an initrd to be passed off to the kernel.

Nonetheless, I unpacked the initramfs using skipcpio and dumped the contents on to an ext2 partition. I pointed root=/dev/{device}17 in the kernel command line, but got the same results

I then went to contemplate other ways I might verify if the sound is tied up on the kernel or a service.  I remembered Cloudready, and shimmed in the official kernel with Cloudready expecting sound.  

The shimming required again using the official Chrome grub loader to deal with booting the official non EFI kernel on the UEFI BIOS from MrChromebox.

Alas, no sound.  The same holds true for the 5.x kernel that Cloudready uses - no sound.  I verified that alsa was using the cras service and although there is volume control, in the Chromium setup interface, neither the welcome chime is heard, nor any sound curves "right parens" on the speaker symbol respective to the current volume level.

At this point, it suggests that the absence of sound is not likely a problem with the module or module parms, but potentially the sound mapping in a sound service.  Let's hope.  

UPDATE: November 24th, 2021

The driver in Linux works. In Fedora 35, the /usr/share/alsa/ucm directory is empty and the ucm2 directory has sound device configurations. By grabbing the bdw-rt5650 configurations from the /usr/share/alsa/ucm directory of the most recent recovery image*, and adding a header of Syntax 4 to the bdw-rt5650.conf file, then restarting pipewire-session-manager**, I was able to use aplay*** and hear sounds.  The first time the sounds were quiet, so before testing with aplay, invoke alsamixer and press F6 to switch to the bdw-rt5650 and max the master and speaker volumes.

* As root: modprobe zram; echo $(unzip -l chromeos_12239.92.0_codename.zip | grep "1 file" | cut -d' ' -f1) > $(find /sys/devices -name disksize); zcat chromeos_12239.92.0_codename.zip | dd of=/dev/zram0; losetup /dev/loop4 -P /dev/zram0; mkdir /tmp/root-a; mount /dev/loop4p3 /tmp/root-a -o ro; cp -av /tmp/root-a/usr/share/alsa/ucm /usr/share/alsa; umount /tmp/root-a; losetup -d /dev/loop4; rmmod zram

** systemctl --user restart pipewire-session-manager

*** aplay -D $(aplay -L | grep ^sysdefault) $(find /usr/share -name *.wav)

This does not produce sound through firefox/youtube, but the restart does appear to reload alsa's device configuration.  In order to hear sound through firefox/youtube, I duplicated Speaker details in HiFi.conf (of the same directory as bdw-rt5650) to match with another config.  Though the sound through firefox/youtube was extremely quiet, direct alsa sound was loud and clear.