ratmusic
Response to #6.
Thanks for taking the time to test this and for documenting how far you were able to push it.
What you are running into is essentially the current boundary of FreeBSD Linux compatibility. Getting as far as a splash screen is already a sign that the linuxulator is doing what it can, but failures around GL context creation are a known and expected limitation. Modern Linux desktop applications assume a very specific graphics stack, including Linux DRM, Mesa behavior, and driver interactions that FreeBSD does not and cannot fully emulate.
At this point, Linux compatibility on FreeBSD and GhostBSD is best viewed as a convenience feature for some userland and CLI software, not a production ready solution for complex desktop applications or games. Once GPU acceleration, OpenGL, or Vulkan enter the picture, reliability drops sharply and failures become subtle and difficult to debug.
For running Linux desktop software in a stable and supportable way, a VM remains the correct solution as that approach also avoids the security and maintenance concerns that come with running Linux binaries through the compatibility layer.
What FreeBSD needs is a clearly defined graphics framework of its own, with stable interfaces and explicit design goals, rather than continued dependence on Linux subsystems for solutions.
The current approach relies heavily on importing Linux DRM, KMS, and driver behavior, which ties FreeBSD’s graphics stability and direction to decisions made for a different kernel, driver model, and security philosophy. When those assumptions do not align, failures tend to surface at the edges, such as during power management, display re synchronization, or graphics context creation.
A native framework would allow FreeBSD to define predictable semantics for device ownership, memory management, and rendering paths, and to support both accelerated and non accelerated graphics in a controlled way. That would improve long term stability, make debugging tractable, and reduce the need for compatibility layers that are difficult to secure and maintain.
Without this, Linux compatibility will remain limited, and desktop graphics issues will continue to appear as downstream symptoms rather than problems FreeBSD can fully own and solve.
As an aside, I am developing "drawfs" and "semadraw" to help but they are not production ready.
