Ubuntu 20.04 Fujitsu FAREHT1 Mouse/Touch Screen Fixes
As previously noted, the touchscreen and pen input on my FAREHT1 under Ubuntu was inverted. By default this version of Ubuntu seems to be using Wayland and libinput. Wayland is pretty short on input configuration options and I tried to switch to Xorg, but also had various issues here.
Googling around it seems that you’re supposed to be able to configure libinput via UDEV rules (e.g. ENV{LIBINPUT_CALIBRATION_MATRIX}=”1 0 0 0 1 0″). For whatever reason this wasn’t working for me, libinput didn’t seem to be picking up the calibration matrix at all.
libinput itself support device/model quirks, but doesn’t have a quirk config that simply lets you enter a calibration matrix. So I decided to hack away at libinput. I grabbed the package source as follows:
vi /etc/apt/sources.list #Uncomment source packages in sources.list
apt-get update
apt-get install dpkg-dev
apt-get source libinput
cd libinput-1.20.0
apt-get install build-essential
apt-get install cmake
apt-get install pkg-config
apt-get install libudev-dev
apt-get install libmtdev-dev
apt-get install libevdev-dev
apt-get install libwacom-dev
apt-get install libwacom
apt-get install libgtk-3-devNext I needed to hack the libinput sources. To the function quirk_get_name(enum quirk q) in quirks.c I added a new quirk type in addition to the existing quirks (ModelInvertMouse below):
case QUIRK_MODEL_INVERT_HORIZONTAL_SCROLLING: return "ModelInvertHorizontalScrolling";
case QUIRK_MODEL_INVERT_MOUSE: return "ModelInvertMouse";
case QUIRK_MODEL_LENOVO_SCROLLPOINT: return "ModelLenovoScrollPoint";And the definition to quirk.h:
QUIRK_MODEL_HP_ZBOOK_STUDIO_G3,
QUIRK_MODEL_INVERT_MOUSE,
QUIRK_MODEL_INVERT_HORIZONTAL_SCROLLING,Then in evdev.c I added the following:
if (libevdev_has_event_code(evdev, EV_ABS, ABS_X)) {
evdev_extract_abs_axes(device, udev_tags);
if (evdev_is_fake_mt_device(device))
udev_tags &= ~EVDEV_UDEV_TAG_TOUCHSCREEN;
}
//CODE ADDED HERE
if (evdev_device_has_model_quirk(device, QUIRK_MODEL_INVERT_MOUSE)) {
//Invert pointer calibration matrix
float mat[6];
mat[0]=-1; mat[1]=0; mat[2]=1;
mat[3]=0; mat[4]=-1; mat[5]=1;
evdev_device_set_default_calibration(device,mat);
}
//ADDED CODE ENDS HERE
if (evdev_device_has_model_quirk(device,
QUIRK_MODEL_DELL_CANVAS_TOTEM)) {
dispatch = evdev_totem_create(device);
device->seat_caps |= EVDEV_DEVICE_TABLET;
evdev_log_info(device, "device is a totem\n");
return dispatch;
}
In the quirks directory I created a new file 50-system-fujitsu.quirks with the following contents:
[FAREHT1]
MatchName=WCOM0101:00 2D1F:009C
ModelInvertMouse=1
[FAREHT2]
MatchName=FTSC1000:00 2808:2922
ModelInvertMouse=1
I also had to go in and disable the libinput calibration interface. I think this is likely the fundamental problem. Something in gdm/wayland is going in a over-riding whatever calibration matrix is set via udev, in libinput.c I commented out the following:
LIBINPUT_EXPORT enum libinput_config_status
libinput_device_config_calibration_set_matrix(struct libinput_device *device,
const float matrix[6])
{
// Disable Wayland screwups
// if (!libinput_device_config_calibration_has_matrix(device))
return LIBINPUT_CONFIG_STATUS_UNSUPPORTED;
// return device->config.calibration->set_matrix(device, matrix);
}
I also had to go in and disable calibration via dev. Even after removing any relevant udev rules, libinput seems to attempt to read udev and set the identity matrix if it doesn’t find anything there. This means commenting out the following line:
evdev_read_calibration_prop(device);In path-seat.c and udev-seat.c.
With all these changes in place, libinput can then be build and installed as follows, restarting gdm for changes to take effect:
mkdir builddir
meson --prefix=/usr builddir/
ninja -C builddir/
ninja -C builddir/ install
/etc/init.d/gdm3 restartTouch sensitivity still seems a bit off. But I’m happy enough with it for the moment.
A tarball containing all my changes is here.
Siglent SSA3015X Plus Upgrade Issues
The SSA3015X Plus contains identical hardware to the SVA1015X vector network analyzer. A popular mod is therefore to software upgrade these instruments, which requires some hacking around.
There’s a “cross-flash” upgrade file floating around on the forums, however this is for upgrading the SSA3021X Plus. When used on a SSA3015X Plus it will /kind of/ work, but essentially result in an unusable instrument. The hardware is different enough between these instruments to cause issues. In particular, the UI doesn’t work at all. You can actually get some control over the UI by connecting to the instrument over Ethernet, attempting to upload a firmware image (which seems to force it into remote mode, so the buttons no longer create phantom input) and then connecting a mouse to the unit. This will then let you navigate menus and attempt firmware uploads.
But I was unable successfully restore the original firmware or enable telnet using this method. I think the problem is that the unit “type” and valid upgrade configuration are mismatched, and essentially nothing will install.
In the end I opened the device and connecting to the UART port. This use 3.3V, 115200 8N1 on the following pins:
Luckily I’d used the “backup” ADS upgrade package to dump the flash contents. Using the serial port you can re-flash the instrument. But first you need to figure out which files to flash where. I could just about figure out which files corresponded to the rootfs datafs and siglent partitions from the file sizes. Flashing these resulted in the bootable instrument, I was then able to install one the the telnet images (from memory SSA3000X+_telnet_11411.ADS) to enable telnet and change the upgrade_static_id in /usr/bin/siglent/config/NSP_config_upgrade_info.xml back to 11407.
This let me flash a stock firmware image, and get back to square one. From here you can use one of the other telnet images to enable telnet (I think this one). Change the upgrade_static_id to 11402 and upgrade to the SVA1015X using the stock firmware.
During the uboot reflash I used the following command to restore the firmware backup:
usb start
if fatload usb 0 0x100000 rootfs.cramfs; then nand erase ${rootfs_addr} ${rootfs_size};nand write 0x100000 ${rootfs_addr} ${filesize};mw.b 0x100000 0x0 ${filesize} && fi
if fatload usb 0 0x100000 siglent.img; then nand erase ${siglent_addr} ${siglent_size};nand write 0x100000 ${siglent_addr} ${filesize};mw.b 0x100000 0x0 ${filesize} && fi
if fatload usb 0 0x100000 datafs.img; then nand erase ${datafs_addr} ${datafs_size};nand write 0x100000 ${datafs_addr} ${filesize};mw.b 0x100000 0x0 ${filesize} && fiMy files are available here.
This tool also works: https://pastebin.com/rhdW63Vz
Cost per Gigabase
In the table above I’ve attempted to calculate the Cost per Gigabase, and Cost of goods sold per Gigabase ($/Gb COGS) for various sequencing platforms. I suspect these numbers are inaccurate, but hopefully are in the right ballpark. I’d welcome any suggestion/better numbers and corrections.
You can download the spreadsheet below and play with the numbers, and read my commentary on the substack.
Illumina
In general user reports for Illumina platforms were relatively easy to find and are mostly in line with what the vendor suggests. I couldn’t find a “Miseq Nano” run in the wild, though I did at least see some users reporting the same yield as Illumina, which suggests it may not be far off. But user reports would be useful.
Illumina don’t make pricing public, but a few sources show the prices they pay (where they have to report single source pricing). These are generally in line with the prices you see service providers or academic labs pricing.
Overall Illumina margins are in the region of 70%. This includes all instruments and consumables, my feeling is that margins are higher on the higher throughput instruments. On their highest throughput run I’ve guesstimated an 80% margin, to be honest this feels low to me… In any case, an upper bound on the Novaseq COGS/Gigabase is $1.18 or if we go with the vendor throughput ($1.42/Gigabase COGS).
Oxford Nanopore
I looked for various reports on Promethion flow cell throughput. This article stated “A single PromethION R10.4 flowcell generated 52.3 Gbp of data with a modal read accuracy of 99%” (published July 2022). This poster stated. “We observed high variability in yield with a mean of 68.5 Gb per cell.” (AGBT 2022). ONT have reported a 10Tb run, this would make the $/Gb 1.15 (or $1.42 if you use 6Tb). User reported yields on a large number of current generation cells (i.e. >48) would be useful here.
I didn’t search as hard to find Minion and Flongle output numbers, the Flongle page states the theoretical maximum, but user reports seem lower than this. Some solid reports showing averages across multiple current generation flow cells would be useful.
Pricing is as listed on the ONT site to the best of my understanding. A PromethION flow cell price of $600 is used which requires buying 2880 flow cells.
2021 accounts listed ONTs margins at 54.8% (combining instruments and consumables). I imagine that margins are lower on the Flongle/MinION than on the PromethION.
From the accounts, revenue seems to be heavily skewed toward the PromethION, it seems like nearly half there revenue comes from 56 customers with “S3” (PromethION) class instruments. So I would imagine margins are also better here..
Pacific Biosciences
The run I found for the Sequel II was actually performed by PacBio, so I wouldn’t be surprised if this was significantly above average. Pricing comes from a random pricing spreadsheet posted on cancer.gov in 2021.. so I wouldn’t be surprised if it was inaccurate.
Pacific Biosciences list overall margins as 47%. Again, this is likely skewed toward consumables, so I’ve guesstimated “50%”.
Ion Torrent
Thermo give public pricing for Ion Torrent chip, so I went with the public price for this. Margins are not listed… but I’ve guesstimated roughly 50%. This is kind of based on my assumption that it’s likely to be similar to Pacific Biosciences but this might well be entirely inaccurate.
RSS