Linux USB Auto-Suspend for FTDI

As I was playing with a few FTDI devices of mine, I noticed each was pulling 100 mA or more. Considering they were intended for use in a laptop, that made me worry a bit. Darn IC should have suspend and these numbers should not be the norm. So I went to investigate on how to reduce this a bit.

The first tool is, of course, lsusb. Using lsusb -tv I got the following output:

/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 10000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M`
    ID 1d6b:0002 Linux Foundation 2.0 root hub
    |__ Port 3: Dev 60, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M
        ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC
    |__ Port 7: Dev 3, If 0, Class=Video, Driver=uvcvideo, 480M
        ID 0bda:5634 Realtek Semiconductor Corp.
    |__ Port 7: Dev 3, If 1, Class=Video, Driver=uvcvideo, 480M
        ID 0bda:5634 Realtek Semiconductor Corp.
    |__ Port 9: Dev 4, If 0, Class=Vendor Specific Class, Driver=, 12M
        ID 27c6:609c Shenzhen Goodix Technology Co.,Ltd.
    |__ Port 10: Dev 5, If 0, Class=Wireless, Driver=btusb, 12M
        ID 8087:0026 Intel Corp. AX201 Bluetooth
    |__ Port 10: Dev 5, If 1, Class=Wireless, Driver=btusb, 12M
        ID 8087:0026 Intel Corp. AX201 Bluetooth
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 10000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub
    |__ Port 3: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M
        ID 0bc2:ab30 Seagate RSS LLC
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub

Device I wanted to analyze was at bus 3, port 3. This knowledge allowed me to check its power level.

cat /sys/bus/usb/drivers/usb/3-3/power/level

Value on that was returned immediately confirmed what I suspected. The port standby was disabled. Another test was to write auto inside the same file and current consumption fell down after 2-3 seconds (essentially, USB standby timeout), as expected.

Unfortunately, as soon as the device was plugged back in, it reset its behavior to always-on. Well, udev rules to the rescue.

Only, I already had FTDI udev rules present on my system (/etc/udev/rules.d/99-libftdi.rules). It seems that one of the tools I used (ftdidev library being the prime suspect) already installed some rules. Any rules I add to that file might get overwritten eventually. So, I decided to create a new file for both FT232R and X Series chips.

cat << EOF | sudo tee /etc/udev/rules.d/42-ftdi.rules
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTR{power/control}:="auto"
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6015", ATTR{power/control}:="auto"
EOF

This will turn on auto standby handling for my FTDI devices while making sure that subsequent rule doesn’t overwrite it (thus :=). Exactly what I needed to make my laptop battery happy.

To apply this without reboot, you can use the following command:

sudo udevadm control --reload-rules && sudo udevadm trigger

Avalonia Workaround for ShowDialog Focus

As I was working on a Linux C# application, I was kinda annoyed with the new dialog not having keyboard control. The window would actually display correctly on top of its owner, but it would never take the keyboard focus onto itself. Thus, no keyboard control. A bit of searching also showed that this was already a known issue, sitting pretty for a while now.

But thankfully, the workaround is rather simple. From within your code, just attach (or override) to your Activated event and manually select the button.

Activated += delegate { button.Focus(); };

With this, Avalonia will switch focus to the new window, and everything else will work as expected.

Reading DDR4 SPD Information on Supermicro M11SDV

Viewing DIMM SDP data under Linux is usually a trivial affair. On my Framework (gen 11) laptop, this went something like this:

sudo apt install i2c-tools
sudo modprobe eeprom
sudo modprobe i2c-i801
sudo decode-dimms

However, on my Supermicro M11SDV server with AMD Epyc 3000 processor, this didn’t work. No matter what I did, nothing would show. After messing around a bit, I found the solution on Unraid forum.

First, I needed to find where is SPD actually listening. The easiest way to determine this is to first list all I2C buses and then search for devices between I2C addresses 0x50 and 0x57:

sudo i2cdetect -l
sudo i2cdetect -y 0 0x50 0x57
sudo i2cdetect -y 1 0x50 0x57
sudo i2cdetect -y 2 0x50 0x57

For my motherboard, I actually found output on bus number 2. It looked something like this:

Warning: Can't use SMBus Quick Write command, will skip some addresses
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:
10:
20:
30:
40:
50: 50 51 52 53 -- -- -- --
60:
70:

Once the bus is found, we just need to load the ee1004 module that works on AMD board. This has to be repeated for each I2C address that was found. Do note that the path contains the I2C bus number (in my case i2c-2).

sudo modprobe ee1004
echo ee1004 0x50 | sudo tee /sys/bus/i2c/devices/i2c-2/new_device
echo ee1004 0x51 | sudo tee /sys/bus/i2c/devices/i2c-2/new_device
echo ee1004 0x52 | sudo tee /sys/bus/i2c/devices/i2c-2/new_device
echo ee1004 0x53 | sudo tee /sys/bus/i2c/devices/i2c-2/new_device

And now finally we can run decode-dimms again and read all that lovely SPD data.

Driving the Plunger (part 3)

This is part 3 out of 3 in the series (see part 1 or 2).

Well, if after reading previous posts you were curious as to how it all looks, wait no more. Below is a quick video showing its usage. And yes, it was a minimum effort video so sound is not there.

First is the mounting method. Just place syringe around the plunger and rotate to fix in place. If you used another syringe before this, you might need to move the plunger ahead until it makes contact. In the video, you can see that I reverse it a bit and then I move it forward just to illustrate this point.

After dealing with the initial paste surge, you get to control the syringe using either the button in the top-left corner or the foot pedal. As I use a foot pedal, you won’t directly see my presses, but you’ll notice the LCD flashes.

As you can see in the video, this thing actually works. However, it’s not without its issues. The most noticeable one is speed and drooping. Every push creates pressure and, no matter how many pull-back tricks I’ve tried, it will not squirt paste fast and without excess. Each profile was essentially a balancing act between how much paste I push and how quickly.

Firmware development for this was actually quite easy and really depended on two programming exercises I already had made from before: OLED and rotary button. The rest of the firmware was just reading the button status and pushing text to an OLED. You can check how I did it on GitHub but I will probably also make a separate post on each.

Would I use it? Well, maybe. While it actually does what I intended to do, the whole process is just too slow. I can do non-paste soldering much faster. Also, different paste will react differently and will need adjustments.

It’s not great for regular work but it’s actually quite okay if you need repeatable solder paste dispensing for special components.

DaVinci Resolve 18 on Ubuntu 23.10 with Intel GPU

While I successfully installed DaVinci Resolve 18 on my Ubuntu 23.10 machine, I simply couldn’t make it start. Quick excursion to the command line, showed the following error:

$ /opt/resolve/bin/resolve
/opt/resolve/bin/resolve: symbol lookup error: /lib/x86_64-linux-gnu/libpango-1.0.so.0: undefined symbol: g_string_free_and_steal

Yep, something was wrong with libraries. Fortunately, after checking quite a few wrong advices on Internet (I know, who would have thought), I solved it by a simple file copy:

sudo cp /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 /opt/resolve/libs/

While this did solve the non-starting issue, I now got Unsupported GPU processing mode error. After searching a bit around the net, consensus seemed to be that you have to have external GPU for Resolve to work under Linux. But that didn’t seem right. Why would DaVinci Resolve require external GPU under Linux while being happy with internal GPU under Windows?

This seemed unreasonable so I tried installing OpenCL for my Intel GPU.

sudo apt install intel-opencl-icd

And with this simple change, I got to run Resolve to start. But I still couldn’t edit.

So I tried installing Intel’s own Open CL drivers:

mkdir neo
cd neo
wget https://github.com/intel/intel-graphics-compiler/releases/download/igc-1.0.14828.8/intel-igc-core_1.0.14828.8_amd64.deb
wget https://github.com/intel/intel-graphics-compiler/releases/download/igc-1.0.14828.8/intel-igc-opencl_1.0.14828.8_amd64.deb
wget https://github.com/intel/compute-runtime/releases/download/23.30.26918.9/intel-level-zero-gpu-dbgsym_1.3.26918.9_amd64.ddeb
wget https://github.com/intel/compute-runtime/releases/download/23.30.26918.9/intel-level-zero-gpu_1.3.26918.9_amd64.deb
wget https://github.com/intel/compute-runtime/releases/download/23.30.26918.9/intel-opencl-icd-dbgsym_23.30.26918.9_amd64.ddeb
wget https://github.com/intel/compute-runtime/releases/download/23.30.26918.9/intel-opencl-icd_23.30.26918.9_amd64.deb
wget https://github.com/intel/compute-runtime/releases/download/23.30.26918.9/libigdgmm12_22.3.0_amd64.deb
sudo apt install ./*.deb

Nope - start but doesn’t allow any editing.

After tryign a few more things, I decided to give up. :( I guess you really cannot run DaVinci Resolve on Intel Xe.