Speaking in Code

Blog

  • Sweat lodge – January 2019

    Saturday night Sterling texted me at 6:30pm to see if I wanted to go to a sweat lodge. I was about to ignore and/or say ‘no’ to him when I thought that I should continue this “yes man” approach to life and so I went with him.

    What to say about the experience? We stood outside in our swim suits, with towels around our top to keep somewhat warm in the 40 degree night; my bare feet were in the wet lawn/dirt/mud while we waited for the ceremony to start. Women went in first—first timers first—followed by men, first timers last. I was close to the end of the line of people. We stood around the large fire that heated the stones and I tried to keep my feet from going totally numb from standing in the cold mud by holding one foot up to the fire, then the other. By the time I got inside the lodge, they were both partially numb.

    I had forgotten about the “smudge pot” before entering. Wafting cedar smoke over myself, kneeling to the east, rotating clockwise, then crawling on hands and knees into the dark and low lodge. I was positioned in a sort of middle row—in front of Sterling but behind an experienced man who was at the edge of the pit where the hot stones would be put.

    Jerry, the shaman, spoke about the purpose of the lodge, the ancestors, the spirits. I don’t recall details as I don’t find that I believe much in that. I do feel the specialness of life, and the reverence shown by Jerry and others there for the sacred is something that I find some comfort in. There was a Native American woman there and Jerry asked her to talk and sing. She sang and chanted in her native language—Shoshone? I find it oddly nice to not know the words so I pay attention to the sounds.

    Inside the lodge were hanging strings of flowers or branches of some sort of plant with roundish leaves. I had taken my glasses off—no need for them in the dark and they’d fog over anyway—so I couldn’t really make out just what they were. But I liked the image of all these branches and leaves and flowers hanging down.

    They brought in ten stones from the fire pit and placed them in the central hole dug out for them. Glowing red orange from the inside. Jerry sprinkled dried ground up plants—maybe sage—onto the hot stones and pinpricks of orange lit up the surface as they were immediately burned. We could smell the smoke, though I don’t know what the plants were from the smell.

    Jerry splashed water onto the hot rocks—the tarp door was still open so it was still relatively cool even though there was steam immediately produced.

    Finally the door was closed and all was dark. After more words Jerry poured more water onto the rocks and the sweat part of the lodge began.

    This ceremony consisted of four “rounds”–one for each compass direction—and each round consisted of four songs. The first round was for the east and the prayer we offered prior to the third song was for ourselves. I wasn’t moved to pray—at least not out loud and certainly not specific wishes for myself—but many were. There was a Muslim man behind and to my left who spoke in Arabic–loud and long, long after Jerry started the third song in that first round. It made for an unusual experience: complete darkness, oppressive heat and steam, a general background murmur of prayers from the group, and a loud prayer in a different language. After what felt like too long of a time, the first round was done and the lodge door was opened and the cool night air came in to refresh us.

    I had forgotten how oppressive and strong the heat and moisture are in a lodge. I recalled the single session of “hot yoga” I had take a number of years ago and how hard that was and how I had at that time tried to keep close to the ground and still to minimize the heat transfer to myself. I never went back to that yoga but here I was in lodge, having made it only through one of the four rounds, wondering if I was going to be able to make it through all.

    When the steam first hits, droplets of water form quickly on your body and you don’t know what’s sweat from your skin and what’s from the water that was poured on the hot stones. You’re quickly drenched from top to bottom. I wiped droplets from my face and my body, foolishly hoping that doing so would provide some cooling and comfort. Trying to chant or sing along with the songs was the only thing that made it somewhat tolerable. I felt my heart beat faster as my body reacted to the heat and I wondered at what point it would be too much and I’d ask to be let out.

    The details of the rounds blend together. The south was for praying for our loved ones; the west to pray for our enemies. In each round I wondered how I would get through to the next. I counted songs, taking solace in the fact that this was the third song and there was just one more before the door was opened and I would be able to be cool. I’d recall meditation and feel my heartbeat and take a deeper breath and know that I’d made it through worse and that I’d be alright. I found coolness in the damp dirt I was sitting on so I moved so my leg was on it as much as possible. I recall early in the third round a new wonderful smell—Jerry must have put some new herb or plant on the rocks. Lavender maybe.

    I made it through all rounds, surprising myself somewhat. After the door was opened for the last time Jerry finished the ceremony by passing around the pipe of tobacco—always stem first to the next person. The tobacco smell in the lodge was pleasant—even the smoke from it was different from what I associate with tobacco. I chose not to take puffs of it when it came to me, but instead said “to all my relations” as Jerry instructed us to say if we chose that route.

    Finally we crawled out—clockwise—and “smudged” ourselves again and we were done.

  • First experience with a All-In-One (water) CPU cooler

    I’m finding out how sensitive I am to certain stimuli (and it does seem like I’m getting more sensitive over time) and one of those things I am sensitive to is the fan noise of my computer. This latest computer I built is less than five months old and when I built it I wanted to use the current generation of AMD’s Ryzen as my then-current computer was a couple of generations behind, so I went with a Ryzen 7900X knowing that they ran hot and that I’d need a good CPU cooler.

    I chose the Noctua NH-D15, with two towers and two fans. It has kept the CPU well within a reasonable temperature range, and I was happy with how low the idle temps were (around 39 C) but when compiling code it would make quite a noise even though the computer was across the room (with 35 foot HDMI cables…that was fun getting that that length to work).

    When I moved my office temporarily into a smaller room in the house I ended up putting the computer no more than 4 feet from me and that fan noise started to sound a lot louder. And it didn’t help that running (far too many) Chrome and Firefox processes and tabs ended up with the CPU running higher than normal idle and so there was a more or less constant fan noise.

    I decided to try an All-In-One (AIO) water cooler thinking it would cut down a lot on the noise, so I did my research and ordered an Arctic Liquid Freezer II 360 and a case that would it would fit in (yet another purchase…sigh). I knew it would be relatively straightforward to move all the components over to the new case, though it would take a few hours for me.

    So late one day this last week I started on it all. The new case (Fractal Design R5) is well designed and I did a test fit of the AIO cooler and then started moving the PSU and motherboard over. All was straightforward, relatively speaking as this was the first AIO I’ve worked with; I did have to make sure that it only used the CPU FAN header on the motherboard–I didn’t know a single header could drive the pump and the three fans, but that’s the setup.

    I got everything together and then plugged all the cables back in and turned it on. And, a POST failure on “VGA” LED. Along with a horrible sound from the PC piezo speaker that I’ve carried along from build to build (as no one seems to supply them anymore). Turn it off, unplug, check and reseat things. Back on, still VGA failure and buzzing, so now I’m thinking my RX6600 GPU somehow got fried (how??) so I put in my backup RX6600 and it also fails, so now I’m thinking it’s possibly the motherboard.

    Next step is to remove the GPU and rely on the iGPU in the Ryzen 7900x. Same VGA failure. Seems like it has to be the motherboard. But before I declare final defeat, I thought it wise to reset the CMOS so I do that, then boot up and still VGA failure, but the awful speaker buzz stops, so maybe progress?

    All except the first test had been without any cables (HDMI, USB, RJ45) plugged in (just easier to do) and I decided, for some reason, to plug in the HDMI cable just in case anything showed up on screen. It was then that I noticed that my KVM switch was off–I had forgotten that I had turned that off for some unknown reason before I started this whole side-grade process. I turned that on, made sure the display was on, rebooted the computer and it worked.

    Now, my perhaps wrong understanding from all my decades of building computers is that POST does not (or at least, usually doesn’t) require a display to be connected and turned on–memory and CPU of course, but other components? I’ve not used a Gigabyte motherboard before so maybe it’s specific to these boards. I don’t know, so while I’m quite happy all was working, I was grumbling about the cause of the apparent failure.

    So, word to the wise on this: when testing new/changed configurations at the motherboard level, make sure there’s a display plugged into the computer.

    Now for the results of my AIO side-grade. I’m mostly happy in that it’s definitely quieter in general, though when I do a build the three fans will kick in. The CPU temps are also good. The problem is that I sometimes hear a high pitched ringing that is coming from the AIO unit and that’s almost as annoying as the Noctua cooler was. I’ve tightened the screw and have adjusted the fan speed profile at the UEFI level but it still is occurring.

    Lastly, while I like the Fractal case, the USB header on the motherboard for the front-panel connector is a bit too close to the bend in the case for the pass-through to the cable management area on the backside of the motherboard tray and it was (still is) really hard to get the right angle to connect the cable to the header. So I bent a few of the pins and I can’t seem to get them unbent so I have no USB on the front panel of the case. This is not as bad as it could be from my perspective as the whole computer is squeezed into a modified shelf unit so there’s no room for me to plug anything into those USB slots. But still. I’m going to see if there’s anything I can buy that will help unbend those pins…

  • Setting up LUKS on a new SSD

    I’m not a linux OS expert even though I’ve been using linux for over twenty years (that said, I’d say that most anyone who installs and uses linux has to have a good amount of technical knowledge). It wasn’t until somewhat recently that I realized I really should have Full Disk Encryption (FDE) on the NVMe SSD drives that I’ve been installing on the last few computers builds I’ve done (and, for sure, it’s wise to use some encryption if there’s any private or important information on a drive–a simple delete of files doesn’t actually overwrite the data on the disk of deleted files usually; this advice applies regardless of NVMe or SATA form-factor). So, as I’ve been building newer systems and adding drives, I’ve been setting them up with with FDE using LUKS (Linux Unified Key Setup), and have been quite happy with the simplicity and the security of it all.

    This article goes over the steps needed to set up LUKS on a new, non-boot SSD drive–in this case it’s a new 1TB Crucial MX500 2.5″ SATA drive.

    I’m going to label Step 0 as “install the physical SSD drive in the computer” and not go into any details at all there. For my setup, I just plugged it into a SATA connector and confirmed via UEFI setup screens that it’s detectable at the hardware level.

    Step 1 is to locate the block device in linux itself. While a non-root user can do a few of these commands, you really need to be root, and I tend to just do a simple sudo bash and then do all the commands while in the root shell. So open up a shell:

    [scott] $ sudo bash
[root] #

    and list block devices:

    [root] # lsblk
NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda                                             8:0    0 931.5G  0 disk  
sr0                                            11:0    1  1024M  0 rom   
zram0                                         252:0    0     8G  0 disk  [SWAP]
nvme0n1                                       259:0    0   1.8T  0 disk  
├─nvme0n1p1                                   259:1    0   600M  0 part  /boot/efi
├─nvme0n1p2                                   259:2    0     1G  0 part  /boot
└─nvme0n1p3                                   259:3    0   1.8T  0 part  
  └─luks-822c7f1b-7d42-48ac-b2f6-3758ceecc5b3 253:0    0   1.8T  0 crypt /home
                                                                         /
nvme1n1                                       259:4    0 931.5G  0 disk  
└─nvme1n1p1                                   259:5    0 931.5G  0 part  
  └─crucialx                                  253:1    0 931.5G  0 crypt /crucial

    You can see the already-setup FDE on crucialx and luks-822c7f1b-7d42-48ac-b2f6-3758ceecc5b3–both have type crypt. The new MX500 is a SATA drive and it shows up as sda–not even partitioned, so the next step is to partition it.

    Note also that there’s another way to list the new device: fdisk -l, one advantage of which is that it also displays the full /dev path and the drive model info:

    [root] # fdisk -l
Disk /dev/sda: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: CT1000MX500SSD1 
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
...

    (output has been truncated to show just the new drive).

    Partitioning can be done with fdisk (or, if the device is more than 2TB, the GNU utility parted needs to be used) and the steps for this are to create a new primary partition (assuming all of the drive is to be part of the FDE process), write out the partition table, and then make sure the OS uses this new information:

    [root@titan scott]# fdisk /dev/sda

Welcome to fdisk (util-linux 2.38).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Device does not contain a recognized partition table.
Created a new DOS disklabel with disk identifier 0x0cbc7bb1.


Command (m for help): n
Partition type
   p   primary (0 primary, 0 extended, 4 free)
   e   extended (container for logical partitions)
Select (default p): p
Partition number (1-4, default 1): 
First sector (2048-1953525167, default 2048): 
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-1953525167, default 1953525167): 

Created a new partition 1 of type 'Linux' and of size 931.5 GiB.

Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.


[root] # partprobe

    Use lsblk to see the new partition:

    [root@titan scott]# lsblk
NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda                                             8:0    0 931.5G  0 disk  
└─sda1                                          8:1    0 931.5G  0 part

    The new partition is /dev/sda1. Now it’s time for LUKS setup.

    LUKS setup really requires that you understand a bit of the overall model of it before jumping in. The high level idea of how it operates here is that LUKS sits between the filesystem (such as btrfs or ext4) and the raw block device (like /dev/sda1) doing the encryption of data written and the decryption of data read. The LUKS command that manages this in-between part is cryptsetup and the basic operations needed for this management are as follows:

    • cryptsetup luksFormat: formats a raw block device so it can be used with the LUKS system
    • cryptsetup luksOpen: opens up a formatted LUKS block device and assigns a logical ID to id
    • cryptsetup luksClose: closes a device opened up with luksOpen
    • cryptsetup luksAddKey: adds a new encryption key to the device
    • cryptsetup luksDump: lists the encryption key info on the device

    As LUKS uses AES256 encryption, the question of how the keys are stored comes up. It turns out that there’s a single AES256 master key and it’s encrypted by secondary keys. LUKS provides 8 “slots” (slot storage is created during the luksFormat operation and are filled via the luksAddKey command) to store the keys used to decrypt the master key. The keys stored in these 8 slots can be created via a passphrase that’s stretched into the required number of bits (LUKS version 2 uses Argon2 for that), or via a good secure random number (bit) generator. Both of these methods will be used so that the FDE is automounted during bootup.

    The usefulness of the 8 slots is that you can specify a passphrase (or two) while having another secure random key of 256 bits that can be used for scripts or during bootup, all of which will allow decryption of the master key that is used for actual encryption and decryption. (And, having multiple slots allows multiple people to unlock, say, a boot drive that has FDE without sharing passwords.)

    Before jumping into the actual operations to use LUKS, it’s important to understand the logical ID that is required for some operations: this logical ID is the “handle” to a block device/partition that’s been opened by LUKS and it shows up in the file system (under /dev/mapper/). It must be unique across mapped/opened block devices and I’ve found it useful to have a convention of appending x to a useful name to indicate that it’s encrypted, like mx500x.

    Step 2 is to put it all together:

    [root]# cryptsetup luksFormat /dev/sda1

WARNING!
========
This will overwrite data on /dev/sda1 irrevocably.

Are you sure? (Type 'yes' in capital letters): YES
Enter passphrase for /dev/sda1: 
Verify passphrase: 

[root]# cryptsetup luksOpen /dev/sda1 mx500x
Enter passphrase for /dev/sda1: 
[root]# ls -l /dev/mapper/
total 0
crw-------. 1 root root 10, 236 Mar  5 06:50 control
lrwxrwxrwx. 1 root root       7 Mar  5 06:50 crucialx -> ../dm-1
lrwxrwxrwx. 1 root root       7 Mar  5 06:50 luks-822c7f1b-7d42-48ac-b2f6-3758ceecc5b3 -> ../dm-0
lrwxrwxrwx. 1 root root       7 Mar  5 07:53 mx500x -> ../dm-2
[root]#

    For the passphrase, choose a secure (long) one and do not forget it as you will lose access to all data on the FDE drive (well, not 100% true if you set things up for automount by using the secure random key generated during that process). And to show the effect of closing a logical ID:

    [root]# cryptsetup luksClose mx500x
[root]# ls -l /dev/mapper/
total 0
crw-------. 1 root root 10, 236 Mar  5 06:50 control
lrwxrwxrwx. 1 root root       7 Mar  5 06:50 crucialx -> ../dm-1
lrwxrwxrwx. 1 root root       7 Mar  5 06:50 luks-822c7f1b-7d42-48ac-b2f6-3758ceecc5b3 -> ../dm-0
[root]#

    At this point all the LUKS setup has been done and it’s time for Step 4 where the drive is formatted. The device does need to be opened (via cryptsetup luksOpen) and then it’s easily formatted; I have recently been using btrfs instead of ext4, so the following is what I did:

    [root]# cryptsetup luksOpen /dev/sda1 mx500x
Enter passphrase for /dev/sda1: 
[root]# mkfs.btrfs /dev/mapper/mx500x 
btrfs-progs v6.1.3
See http://btrfs.wiki.kernel.org for more information.

NOTE: several default settings have changed in version 5.15, please make sure
      this does not affect your deployments:
      - DUP for metadata (-m dup)
      - enabled no-holes (-O no-holes)
      - enabled free-space-tree (-R free-space-tree)

Label:              (null)
UUID:               8bc72d72-09f9-478a-b21e-dc0a76bf7eda
Node size:          16384
Sector size:        4096
Filesystem size:    931.50GiB
Block group profiles:
  Data:             single            8.00MiB
  Metadata:         DUP               1.00GiB
  System:           DUP               8.00MiB
SSD detected:       yes
Zoned device:       no
Incompat features:  extref, skinny-metadata, no-holes
Runtime features:   free-space-tree
Checksum:           crc32c
Number of devices:  1
Devices:
   ID        SIZE  PATH
    1   931.50GiB  /dev/mapper/mx500x

    and then to mount it:

    [root]# mkdir /mx500
[root]# mount /dev/mapper/mx500x /mx500/
[root]# df -h
Filesystem            Size  Used Avail Use% Mounted on
devtmpfs              4.0M     0  4.0M   0% /dev
tmpfs                  31G  736M   31G   3% /dev/shm
tmpfs                  13G  2.4M   13G   1% /run
/dev/dm-0             1.9T  267G  1.6T  15% /
tmpfs                  31G   45M   31G   1% /tmp
/dev/dm-0             1.9T  267G  1.6T  15% /home
/dev/nvme0n1p2        974M  318M  589M  36% /boot
/dev/nvme0n1p1        599M   18M  582M   3% /boot/efi
/dev/mapper/crucialx  932G  367G  565G  40% /crucial
tmpfs                 6.2G  2.4M  6.2G   1% /run/user/1000
/dev/mapper/mx500x    932G  3.8M  930G   1% /mx500

    At this point /mx500 is fully usable and all data written to it will be encrypted.

    For convenience I (strongly) suggest setting it up so that the FDE drive is automounted during OS bootup. This can be a bit more complicated than desired if you have more than one NVMe drive, as the assignment of /dev drive is dependent on the scan done during bootup and isn’t 100% predictable (as I found out later). If you do have more than one NVMe drive, read the section lower down also.

    Setting up automount during bootup requires the following:

    • create a secure random key, saved to a protected file
    • edit /etc/crypttab to add a line that will do an automatic open on the device during bootup
    • edit /etc/fstab to add a line that will do an automatic mount of the opened device

    I’ve put the the secure random key file under /root directory as that’s protected and isn’t likely to be mistakenly deleted or modified. It can be created like this:

    [root]# dd if=/dev/random bs=32 count=1 of=/root/lukskey.mx500x
1+0 records in
1+0 records out
32 bytes copied, 5.4303e-05 s, 589 kB/s

    If you haven’t used dd (“data duplicator”) before, what that command is doing is copying 32 bytes (bs=32 count=1: 1 block of size 32) from /dev/random to /root/lukskey.mx500x. It’s a very useful command (but can be dangerous if you don’t know what you’re doing as it can and will write to raw block devices (and totally destroy the data on them).

    Now the new 32-byte key must be added to one of the 8 slots:

    [root] cryptsetup luksAddKey /dev/sda1 /root/lukskey.mx500x
Enter any existing passphrase: 
[root]

    Once you’ve created the key file, add a line like the following to /etc/crypttab (which automates the luksOpen done manually above):

    mx500x   /dev/sda1  /root/lukskey.mx500x

    and finally a line like the following can be added to /etc/fstab (which automates the mount done manually above):

    /dev/mapper/mx500x   /mx500   btrfs   defaults  0 0

    And that’s all the setup needed if you don’t have more than one NVMe drive. At this point, double-check paths that were entered into /etc/*tab files as errors here will cause bootup problems. Reboot the computer to test it all out to make sure everything gets automounted.

    If you have more than one NVMe drive, then it’s necessary to use the UUID of the partition as the actual drive number (e.g., the 0 in /dev/nvme0n1) is assigned during a boot-time scan of devices. And there are actually two UUIDs that need to be used: one for use in /etc/crypttab and one for use in /etc/fstab. In order to get the UUIDs, use the following command (the important UUIDs are in bold):

    $ sudo lsblk -o +name,mountpoint,uuid
[root@titan scott]# lsblk -o +name,uuid
NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS NAME                  UUID
sda                                             8:0    0 931.5G  0 disk              sda                   
└─sda1                                          8:1    0 931.5G  0 part              sda1                  561e1265-0150-437c-b979-4bf4a5a1ff49
  └─mx1000x                                   253:1    0 931.5G  0 crypt /mx1000     mx1000x               8bc72d72-09f9-478a-b21e-dc0a76bf7eda
sdb                                             8:16   0   3.6T  0 disk              sdb                   
└─sdb1                                          8:17   0   3.6T  0 part              sdb1                  d8347463-e812-4293-ac9b-c9dae64d2992
  └─mx4000x                                   253:2    0   3.6T  0 crypt /mx4000     mx4000x               331eef2c-4ef9-47d7-a856-8ef28e928a90
zram0                                         252:0    0     8G  0 disk  [SWAP]      zram0                 
nvme0n1                                       259:0    0   1.8T  0 disk              nvme0n1               
├─nvme0n1p1                                   259:1    0   600M  0 part  /boot/efi   nvme0n1p1             B4CD-57EE
├─nvme0n1p2                                   259:2    0     1G  0 part  /boot       nvme0n1p2             c0d6df9c-9664-4174-99a3-4c207a52f318
└─nvme0n1p3                                   259:3    0   1.8T  0 part              nvme0n1p3             822c7f1b-7d42-48ac-b2f6-3758ceecc5b3
  └─luks-822c7f1b-7d42-48ac-b2f6-3758ceecc5b3 253:0    0   1.8T  0 crypt /home       luks-822c7f1b-7d42-48ac-b2f6-3758ceecc5b3
                                                                                                           66cead1d-0664-4f46-99a8-0b3ddb8891f5
                                                                         /                                 
nvme1n1                                       259:4    0 931.5G  0 disk              nvme1n1               
└─nvme1n1p1                                   259:5    0 931.5G  0 part              nvme1n1p1             40818881-4df8-45a2-8c34-390e1faaca5d
  └─luks-40818881-4df8-45a2-8c34-390e1faaca5d 253:3    0 931.5G  0 crypt /crucial    luks-40818881-4df8-45a2-8c34-390e1faaca5d
                                                                                                           2686e2f5-4a18-4be3-9340-79296349a7af

    The first UUID (that’s associated with the crypt type partition of the device) is used in /etc/crypttab like so:

    luks-40818881-4df8-45a2-8c34-390e1faaca5d UUID=40818881-4df8-45a2-8c34-390e1faaca5d /root/lukskey.crucialx

    and the second UUID (that’s associated with the mounted partition) is used in /etc/fstab like so:

    UUID=2686e2f5-4a18-4be3-9340-79296349a7af /crucial                btrfs   defaults        0 0

    (I haven’t verified the following but I think that it’s necessary to do a luksOpen and mount of the partition to get the second UUID.)

  • Webcams and USB cables on linux

    March 2023

    And here I thought USB was compatible (mostly) with itself. Apparently, I still have a lot to learn about USB even though I’ve been in the computer field for 40+ years.

    Last week I was so looking forward to getting Zoom to work on linux. I had just found out–and I don’t recall how this happened–that Zoom supports linux and given that I do 98% of my work on linux (Fedora, for-ever) with the other 2% being on macOS for all the video calls I’m on, I thought it would be so nice to not have to twist my body to face the macbook on one side of my desk. So I ordered what looked to be a reasonable webcam (Logitech’s Brio 300) and waited for it to arrive. I had to order a USB-C to A adapter as the goal was to plug it into my KVM switch so multiple machines could make use of it.

    When both parts arrived I plugged things in, somewhat naively expecting it all to just work. And, of course it didn’t. So I plug it in (with no C to A adapter) to my mac and all seems well, leaving me disappointed with linux and with my researching things prior to ordering.

    So I start digging into what might be the problem. I quickly find out that the subsystem in linux for video is v4l2 (Video 4 Linux 2, though I’m guessing that the “2” means major changes from “1”, but I didn’t look enough to verify) and I install v4l2 tools and start trying to get those to work. The computer can see the webcam device itself, but all I see is black for any video app.

    Eventually I give up (mostly) and let it sit for a few days. And I think about ordering a known compatible model but after clicking through so many links I’m not liking what I’m seeing (“discontinued model” showed up more than once). I eventually started searching again for possible problems with Brio 300 and linux and I finally hit upon a review written in German (which Google offered to translate) and when I read it (translated well enough, I suppose) there was as a mention of MJPEG and YUYV and native hardware operations not working if a USB 2 cable is used… and, of course that adapter drops it from USB 3 to 2 and so I thought that I should try going directly from the webcam into the motherboard USB 3 connector.

    And it worked and I was a bit (or more) surprised as the bandwidth used by a HD webcam at 30fps should *not* overwhelm USB 2. Okay, whatever. So then I start plugging in the cable+adapter (to type A) into USB 3.2, 3.1, and 2 ports and it becomes clear that it works only with 3.0/3.1 (blue/teal ports)–not 3.2 (red) as far as I can tell.

    So after ordering and using a 6ft USB 3.1 extension cable and plugging it into the 3.1 (A connector) ports with the adapter it all works.

    Thinking that maybe this little webcam is using a large amount of the bandwidth, I found out about usbtop and so I ran it, and it shows that it’s using only around 24Mbps, or a small portion of the USB 2 bandwidth (480Mbps). Sigh.

    Moral of the story is that backwards compatibility isn’t always, and that it’s good to bypass “transformations” of USB data (like those that come with downgrading to USB 2). I suppose related to this is my saga of having a really nice ASUS Republic of Gamers mechanical RGB keyword not work if it’s connected to a USB 2 KVM switch…

    Update (a few days after the above was written)… well, it’s not quite so simple as it turns out it is possible to throw USB 2 in the mix and have it work. Either the combination of adapters (and orientation of the C-to-C connection) or the particular USB 3.2 (?) port used on the motherboard is important (or both), as I was able to get the Brio working using a USB 2 female-to-male extension cable as long as the orientation of connections was correct and the USB type A connector was plugged into the right motherboard USB connector. The working combination requires the manufacturer’s logo on the connectors/cables and the generic USB “network” symbol to be on the same side of the connection. Sigh.