Show Your Support: This site is primarily supported by advertisements. Ads are what have allowed this site to be maintained on a daily basis for the past 18+ years. We do our best to ensure only clean, relevant ads are shown, when any nasty ads are detected, we work to remove them ASAP. If you would like to view the site without ads while still supporting our work, please consider our ad-free Phoronix Premium.
It's Still Going To Be Tough Getting The OpenChrome VIA KMS Driver In The Linux Kernel
Kevin Brace who is largely the only (independent) contributor left working on the OpenChrome project for providing open-source Linux graphics driver support for aging VIA x86 graphics hardware is hoping to see it through soon for getting this driver mainlined.
He's recently been working on fixing some lingering bugs and in recent months have been focusing on mainline kernel support. But if that driver is being mainlined, the initial cut in the kernel won't support any still to be developed Gallium3D user-space OpenGL driver let alone any 2D support.
This weekend Brace sent out another kernel mailing list message about his mainline ideas. He's hoping to get it mainlined in the "next one or two Linux kernel development cycles" for this 7+ year old driver.
Among the open issues are whether the OpenChrome DRM driver needs to move from the "legacy" KMS interfaces to supporting atomic mode-setting, the basic acceleration code within the DRM code has not been finished and may need to be removed, and other open matters.
DRM subsystem maintainer David Airlie has responded that he won't insist on atomic mode-setting as a requirement for merging, but if other upstream developers insist on it and needed for review, he would abide by the wishes of others. Also, the unfinished acceleration code would need to be removed for merging as well as removing the code to custom libdrm API calls. David also commented that if an initial review can be done by others, the OpenChrome DRM driver might be allowed into "DRM staging" while settling other open matters.
It's certainly too late to get the driver reviewed and prepped for Linux 4.18, so that would be Linux 4.19 or Linux 5.0 before possibly seeing the code in a readied state for potentially finding its way into the mainline Linux kernel, if all goes well. But if atomic mode-setting is deemed necessary, that could push the effort back by several more releases.