1d722e3fbSopenharmony_ciThis is a historical description of what is now the kgsl backend 2d722e3fbSopenharmony_ciin libdrm freedreno (before the upstream drm/msm driver). Note 3d722e3fbSopenharmony_cithat the kgsl backend requires the "kgsl-drm" shim driver, which 4d722e3fbSopenharmony_ciusually is in disrepair (QCOM does not build it for android), and 5d722e3fbSopenharmony_cidue to random differences between different downstream android 6d722e3fbSopenharmony_cikernel branches it may or may not work. So YMMV. 7d722e3fbSopenharmony_ci 8d722e3fbSopenharmony_ciOriginal README: 9d722e3fbSopenharmony_ci---------------- 10d722e3fbSopenharmony_ci 11d722e3fbSopenharmony_ciNote that current msm kernel driver is a bit strange. It provides a 12d722e3fbSopenharmony_ciDRM interface for GEM, which is basically sufficient to have DRI2 13d722e3fbSopenharmony_ciworking. But it does not provide KMS. And interface to 2d and 3d 14d722e3fbSopenharmony_cicores is via different other devices (/dev/kgsl-*). This is not 15d722e3fbSopenharmony_ciquite how I'd write a DRM driver, but at this stage it is useful for 16d722e3fbSopenharmony_cixf86-video-freedreno and fdre (and eventual gallium driver) to be 17d722e3fbSopenharmony_ciable to work on existing kernel driver from QCOM, to allow to 18d722e3fbSopenharmony_cicapture cmdstream dumps from the binary blob drivers without having 19d722e3fbSopenharmony_cito reboot. So libdrm_freedreno attempts to hide most of the crazy. 20d722e3fbSopenharmony_ciThe intention is that when there is a proper kernel driver, it will 21d722e3fbSopenharmony_cibe mostly just changes in libdrm_freedreno to adapt the gallium 22d722e3fbSopenharmony_cidriver and xf86-video-freedreno (ignoring the fbdev->KMS changes). 23d722e3fbSopenharmony_ci 24d722e3fbSopenharmony_ciSo don't look at freedreno as an example of how to write a libdrm 25d722e3fbSopenharmony_cimodule or a DRM driver.. it is just an attempt to paper over a non- 26d722e3fbSopenharmony_cistandard kernel driver architecture. 27