I had a lot of similar questions until I asked them here. The essence of the infos you get over this post is these:
- No android app handles directly
/dev/fb0, does it exist or not. Instead, they are communicating with the system process named "Surface Flinger", which is the analogy of the X server on the Linuxes.
- This communication happens with Binder, which is an android-specific localhost-only RPC protocol similar to the unix pipes.
- Not even the Surface Flinger can see the
/dev/fb0 directly. Instead, it talks to the HAL (hardware abstraction layer). Until Android 8, the HAL was a set of shared libraries in /lib/hw. Since Android8, also the HAL is a set of system services talking over binder with the Surface Flinger (although legacy shared lib HALs are still possible).
- Direct display access happens in the HAL library (service) responsible for that.
HAL libs (services) are developed by the phone vendor. Ha can develop a /dev/fb0 driver and use a hal capable to handle it, but he can also develop any custom method. In the second case, you won't have a /dev/fb0 in the kernel.
Furthermore, and it is already a linux-specific thing: /dev does not need to have all the device files existing on your system. Commonly it is so, but it is not a requirement. (On most Linux distros, the software named udev automatizes this task, but Android does not use it.) /dev has device files, on a Linux you can see that they start by a c (character device file) or b (block device file) in the ls -l output, and also on Android:
crw-rw---- 1 root video 29, 0
Dec 10 09:08 /dev/fb0
brw-rw---- 1 root disk
8, 0
Dec 11 07:21 /dev/sda
-rwxr-xr-x 1 root root 1302248 Apr 18 2019 /bin/bash
/dev/fb0 is a character device file, /dev/sda is a block device file, while /bin/bash is an ordinary file and not a device.
You can create device files with the mknod tool, but note: it requires root.
It is quite possible that /dev/fb0 is created elsewhere on your system, maybe on a location which is hidden behind same userspace-only mounts or so. It is also possible that fb0 is not created at all, despite that its driver is compiled into the kernel.
We can check, which device files are compiled into the kernel, in the procfs file /proc/devices. It should contain the line
Character devices:
...
29 fb
...
This procfs file is practically always readable also as a user. If it does not exist, then your HAL responsible for the display communicates over some other way with the kernel.
If it exists, then you can create the framebuffer device by a command
mknod /dev/fb0 c 29 0
as root. (Actually you can always create it as root, but if the line above does not exist in /proc/devices, then it won't be usable.)
P.s. in LineageOS, my experiences are far the best by compiling an userdebug image. It did not slow my system at all, but all the rooting, adb things worked in it very correctly.