Hey guys, primary reverse-engineerer and author of the BYD touchpad driver found in the psmouse kernel module here.
Just wanted to give y’all some context of the trade-offs between the ‘official’ kernel driver ( ie the one enabeld by writing ‘byd’ to serio1/protocol ) vs this DKMS driver smirta linked to. It’s been awhile since I’ve had my head in this space so some of the following details might be a bit off, but they should be mostly correct.
Custom DKMS
The DKMS driver handles things like scroll events and multi-touch gestures in hardware on the touchpad itself. The gesture recognition is fairly terrible and laggy, especially when compared to other modern multi-touch devices you’re used to (such as a macbook, for instance).
The device also has no (known) way to expose information on individual multi-touch events the modern multi-touch input stacks need to provide good user experience (finger location, pressure, etc). The hardware only exposes single-finger absolute position packets, but with single byte resolution in each dimension, and no pressure information. Modern multi-touch device drivers simply report finger touch location and pressure to the user-space layer (libinput, synaptics) and do all gesture recognition at that level, which theoretically gives users for fine-grained control over sensitivity settings, left/right click locations, gestures, etc.
Built-in PSMOUSE
The BYD driver built into the psmouse kernel module (when enabled) disables all the various hardware-detected gestures and does not support its ‘multi-touch’ modes. It reports the device to the user-space input layer as a single-touch absolute position touchpad and reports single-finger touch location/movement and hardware left/right mouse clicks.
The driver gets around the 1-byte resolution limitation mentioned above by using the absolute position events as a beginning ‘anchor point’ for mouse movements, and then updates the position using relative movement packets. The provided relative movement packets have a much higher resolution, so while the absolute packets resolution is only 255x255 we can effectively provide location data with a ‘virtual’ resolution of 11264x6656.
By providing raw location data, synaptics and libinput integration is pretty good and you can enable various settings from your window-manager’s mouse settings page and associated configuration tools. In modern Gnome3 at least, you can enable tap to click, natural scrolling, and edge scrolling (though annoyingly the dialog assumes that since it’s a touchpad, it offers a two-finger scroll option which does nothing besides dash your hopes).
If you’re using libinput rather than synaptics, you get ‘disable the touchpad when typing’ for free (which in my experience is a must-have with this hardware). Synaptics, if I recall correctly, provides much more fine-grained control for the power-user to tweak.
One downside is that have to manually enable the BYD driver. This is because it cannot be enabled by default in the Linux kernel as the BYD hardware provides no unique ‘handshake’ to identify itself. IE, when this driver is enabled a generic PS/2 mouse will successfully go through the BYD initialization and then promptly not work as the driver expects some other things besides generic PS/2 packets.
TLDR:
Custom DKMS:
+ multi-touch gesture support
- no individual finger reporting
- not configurable through window-manager settings pages
- no tap-to-click (this could be implemented)
- no natural scrolling (this could be implemented)
Built-in PSMOUSE:
- only single-touch support
+ configurable through window-manager settings pages
+ tap-to-click (if you want it)
+ edge scrolling (if you want it)
+ smoother, more fine-grained scroll experience with software edge scrolling compared to hardware two-finger scrolling
- no two-finger scrolling
+ natural scrolling (if you want it)
+ disables mouse events while typing (libinput only)
- have to modify “/sys/bus/serio/devices/serio1/protocol” to enable 
- cannot play nicely with generic PS/2 mice (though not really an issue with the Librem series)