The SoC (Qualcomm MSM8998 aka SDM835) is not the issue:

• Qualcomm takes care of that (or rather mostly "took" in case of the SDM835, while Qualcomm's mainlining of the cellular and WiFi modem drivers for the SDM835 is still work-in-progess) via the Linux Foundation's Code Aurora platform.
• Except for some things in the video realm, specifically 3D (OpenGL & Vulkan; but not 2D), but OpenGL support for the SDM835's Adreno 540 3D-accelerator is already in Mesa.

But the specifics of the F(x)tec Pro1 platform are:

• AFAIK, nobody has checked yet, for which peripheral components (GPS, battery gauge, power management controller, keyboard controller, touchscreen controller, accelerometer, magnetometer, cameras (multiple) etc.) device drivers exist, which are licensed compatible to the GPLv2 (which is Linux's license; e.g. Apache, MIT, various BSD licenses and naturally the GPLv2 suffice).
• Missing GPLv2-compatible drivers would have to implemented, for which it makes sense to try to consult the peripheral's manufacturers first (it might be helpful to be able to read, write and speak some Chinese for that).
• A Device Tree (file) for the F(x)tec Pro1 platform has to be created, with parameterised bindings to the device tree entries of the components (SoC and peripherals) this platform is comprised of.
• Device Tree entries describing each peripheral component and binding it (usually also parameterised) to a device driver must be checked and / or created.
• All these efforts would have to be actively upstreamed, which is labour intensive and must be carried out for each aforementioned software component separately (preferably when an individual component is close to be deemed "ready for upstreaming").

Happy coding!
So go for it.