[Openchrome-devel] [ANNOUNCE] The current status of drm-openchrome (August 24th, 2017)

[Kevin Brace]

Hi everyone,

Just a quick update on drm-openchrome.
I tackled several compilation related issues of drm-next-4.13 branch this morning, and as of right now, I think they are all resolved.
Yes, there are still a few things that will show up as warnings, and several of them will be dealt with shortly, but the rest will remain there for now.
That being said, the DRM code is currently broken, and X Server will refuse to start due to yet to be resolved bugs related to GEM / TTM.
At least, FB console will work, but that all for now.
It is my general policy not to keep the code in a broken state, however, the jump from 3.19 to 4.13 was too much for me, so until the fix is ready, it will stay broken.
Regarding drm-next-3.19 branch, the code in the repository right now can boot X Server on Xubuntu 14.04 LTS (the stock kernel is Linux 3.13) by substituting Linux 3.13 (Xubuntu 14.04 stock) with Linux 3.19 rc6 (the Linux kernel used by drm-next-3.19).
However, it still contains a bug that causes X Server to crash when you try to change the screen resolution.
    My basic strategy of managing drm-next-3.19 and the latest drm-next branches is that I will try to keep the code between the two as identical as possible.
If anyone has noticed, many if not all commits I have made are similar.
This arrangement is sort of necessary for now since I plan to use drm-next-3.19 branch primarily for CLE266 chipset support.
I plan to install Debian 8 in one of the hard drives I have eventually, and I will use it with CLE266 chipset.
If I recall it correctly, Debian 8 uses Linux 3.16 kernel, so I should be able to install drm-next-3.19's Linux 3.19 kernel over it.
Due to disappearing support for non-PAE (Page Address Extension) x86 microprocessors, not too many Linux distributions support non-PAE x86 microprocessors these days, and unfortunately, CLE266 chipset is almost always (There have been a few with Socket 370, and in this case one can use Intel Pentium III or Celeron which supports PAE.) mated with VIA Technologies C3 processor which does not support PAE.
At some point, I will stop working on drm-next-3.19 branch, but I do not have a firm timeframe when this will happen.
To those who are wondering, due to the nature of how Linux gets developed, it is not really feasible to retrofit old Linux kernels with a newly developed DRM.
To those who are used to Microsoft Windows (myself included), this is really a culture shock since it is very common for new hardware to support Windows releases that were released more than 5 years ago or even 10 years ago (i.e., the latest graphics cards still support Windows 7 which was related in 2009).
So, all I can do is to keep up with the latest Linux kernel, and when I feel like the code is reliable enough, I will ask for mainline inclusion.
Since I face so many issues, I do not know when this will happen.
    Regarding the Linux kernel I will be dealing with moving forward, unlike in the past, I will not stay with an old kernel for long, and I will try to pull the latest code from Linux DRM maintainer's drm-next branch roughly every 6 months.
What happened in the past was that I did not know how to pull the drm-next branch into drm-openchrome (i.e., I do not have prior FOSS development experience), so the Linux kernel had to stay at 3.19 rc6 for this long.
    One last thing.
If you plan to guinea pig yourself with drm-openchrome, please do not forget to upgrade your OpenChrome DDX with Version 0.6.158 or later.
What happened was, I changed the location of OpenChrome DRM from /drivers/gpu/drm/via to /drivers/gpu/drm/openchrome.
Subsequently, the current drm-openchrome (both drm-next-3.19 and drm-next-4.13 branches) will ultimately generate openchrome.ko rather than via.ko.
I wanted change the name of the DRM since OpenChrome is not VIA Technologies sponsored project.
It is sort like Nouveau (reverse engineered NVIDIA graphics stack) not calling their DRM nv.ko or nvidia.ko.
Because of this, you will need to update OpenChrome DDX since it will look for openchrome.ko now rather than via.ko.
I do recognize that this might be a problem for those who still use DRI1 supporting VIA DRM, and I may have to make further updates to the code to handle via.ko only to support the old VIA DRM for a backward compatibility reason.
That being said, for DRI2 (Direct Rendering Infrastructure 2) and KMS (Kernel Mode Setting) supporting DRM, the code will only search for openchrome.ko from now on.
    That's all for now, and I will send out another update regarding this issue when I finally get Xubuntu 16.04.3 to work with drm-next-4.13.
At this point, I do not know how long it will take.

Kevin Brace
OpenChrome Project maintainer / developer