It's Still Going To Be Tough Getting The OpenChrome VIA KMS Driver In The Linux Kernel
The many year effort on the open-source VIA "OpenChrome" DRM/KMS driver might culminate with getting into the mainline Linux kernel within the next few kernel cycles, but there is still a lot of work for that to happen.
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.
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.
21 Comments