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-dev

Next 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:


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;

        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;

        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:

MatchName=WCOM0101:00 2D1F:009C

MatchName=FTSC1000:00 2808:2922

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 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:


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 restart

Touch 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} &&    fi

My 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.


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.

SpreadSheet files

Number Document

Excel Document

Global Sequencing Capability Notes

I’ve been trying to come up with a rough estimate for the total worldwide sequencing capability. To estimate this, I tried to estimate the number of instruments deployed for popular sequencing platforms. In most cases vendors don’t make these available, but I’ve documented my thought below. The numbers below represent my estimates as of December 31st 2021.

Based on this estimate we could currently sequence 2.2 Exabases a year, or 70 Gigabases/s.

This of course assumes that we could keep all instruments supplied with reagents, this is likely not the case for all instruments. But the NovaSeqs alone account for about two thirds of the total sequencing capacity, and I suspect Illumina are in a position to keep these fully stocked with reagents.

While 3 Exabases seems like a awful lot, it’s worth noting that this still isn’t enough to sequence every human born. Somewhere in the region of 4 children are born a second, our 100Gb/s wouldn’t even let us fully sequence one of them (at 30x).

If we assume we can multiplex at most 384 samples per run, then we can potentially run 2 billion samples a year. Again, this seems like a lot, but according to some sources over 15 billion COVID tests have been performed over the course of the pandemic, with Abbott alone shipping 1.4 Billion tests.

So, if sequencing is eating the world, then there’s still a lot of room for growth.

Estimates and Spreadsheet files

MinION Estimates:

Oxford Nanopore 2021 financial reports state that there are 5501 active customers using MinIONs. They also state that the MinION is designed as a first instrument, before users move to higher throughput platforms. It therefore seems likely that the majority of customers only have one MinION that they actively use, before progressing to higher throughput instruments. As such we have set the estimate here as the number of active customers (5501).

GridION Estimates:

Similar to the MinION, the GridION is a lower throughput instrument, as such it likely does not make sense for a user to have multiple GridIONs, if they exceed instrument capacity a PromethION would be a more logical choice. As such we have set the instrument estimate as the number of active customers presented in the 2021 financials (782).

PromethION Estimates:

G42 are likely the largest user of the promethION. The image in the news report here shows ~12 instruments all of which are promethION 48s. Other sites (1 2 3 4 5) appear to use the PromethION 24, with little advantage to owning 2 PromethION 24s over a single 48, it is likely that these site have a single instrument. With 56 total customers, we can guess that G42 have 12 instruments, and other users have single instruments, giving a total of 67. For simplicity and to compensate for any under-estimation here, we will assume these are all PromethION 48s. 

Illumina Estimates:

I used two methods to estimate numbers here, for the spreadsheet I went back through JPM presentations for 2019 to 2022 (based on Shawn Baker’s suggestion, thanks Shawn!). The 2019 presentation had full instrument counts. The 2022 presentation has all “lower end” instruments lumped together and as such I’ve kept these in the same row, same goes for NextSeqs (the 550 and 2000s and all together, and I used the 2000 throughput, so this is very much an upper bound).

Previously I used the following:

Illumina presentations state their 2021 shipments as follows:

NovaSeq: 380, NextSeq: 1175, MiSeq/Mini/iSeq: 1680

Using 2021 shipments we can estimate the product mix breakdown as follows:

NovaSeq: 11.7%, NextSeq: 36.3%, MiSeq/Mini/iSeq: 51.9%

Illumina also state there are >20000 total instruments installed. Using these percentages suggests:

2340 NovaSeqs, 7260 NextSeqs, 10380 MiSeq/Mini/iSeqs

Ion Torrent Estimates:

Ion Torrent have an estimated 10% market share, Illumina almost complete dominates the rest of the market. Using this we would estimate that Ion Torrent have at most 10% of the Illumina total install base or 2220 instruments.

Pacific Biosciences Estimates:

PacBio shipped 374 instruments in 2021. Their total install base was 203 as of December 2020. As such, they have a total of 577 instruments placed as of December 31st 2022.

MGI Estimates:

MGI is the hardest to estimate as they may have significant market share in China, where we don’t have good data. A press release from January 2019 states that they have installed 1000 instruments. A press release from July 2022 simply states “thousands”. MGI have been restricted from selling instruments in many countries, which may have limited their growth. We’d therefore estimate that there are likely only a few thousand instruments installed, 2000 seems like a reasonable estimate. We use their mid-range instrument as representative of their range, as we have no accurate breakdown of instrument deployments.

UPDATE: I broke out T7 throughput, but it’s really hard to find T7 numbers. I’ve only seen one quoted sale of a T7 instrument (to GeneWiz). I suspect most T7s exist within MGI service labs. “10” seems like a reasonable random number to select, particular given I doubt these instruments could be used in the US in 2021.

Spreadsheet files:





Old Versions: