[Openchrome-devel] [ANNOUNCE] Syncing drm-openchrome with drm-next

[Kevin Brace]

Hi everyone,

I have not had much updates lately (several weeks), but this is because I was working on syncing drm-openchrome with drm-next.
Maybe this is not a big deal to those who know how to use Git properly, but I finally figured out how to sync drm-openchrome with DRM maintainer David Airlie's drm-next.
The drm-next I am talking about here is equivalent of Linux kernel 4.13-rc2 or rc3.
Unfortunately, it appears that very few people do this in real life, so it took me a week to figure out how to merge code from another repository into drm-openchrome repository.
    From now on, I will likely not develop drm-openchrome on the master branch, and instead use drm-next-*.** branch.
Just for the reason of developing drm-openchrome on CLE266 chipset, I did create a branch called drm-next-3.19.
This is because I plan to use Debian 8.x for the sole purpose of developing drm-openchrome for CLE266 chipset.
Of course, whatever code that is updated for CLE266 chipset will be merged into the drm-next-*.** branch code.
Unfortunately, very few major Linux distributions support x86 processor without PAE (Page Address Extension) anymore, and most CLE266 chipsets I know shipped with VIA Technologies C3 processor, which does not support PAE (because C3 was originally developed as a Socket 7 processor, and it was called WinChip 4 prior to VIA Technologies acquisition of Centaur Technology).
If I find a satisfactory Linux distribution that still supports x86 processors without PAE with the latest Linux kernel (i.e., around Linux 4.10), I will likely switch to that distribution for the development of drm-openchrome for CLE266 chipset.
This way, I will have to maintain two development branches, and that is a big burden.
    Just in the interest of disclosure, the code on the drm-next-4.13 branch will not compile correctly at this point.
I spent a week updating the code to get rid of compilation errors and warnings, and I will merge the code changes over a week or so since a lot has changed with DRM in almost two and half years.
There is one very undesirable feature (i.e., use of helper_private member inside drm_framebuffer struct) the previous developer used that prevents rather systematic conversion of old code to compile against Linux 4.13.
I have not figured out how to change the code to overcome this issue at this point, but other than that, most compilation issues have been resolved when I used a far faster processor than C7-M 1.2 GHz to sped up Linux kernel compilation speed (AMD Athlon 64 X2 2.3 GHz with K8M890 chipset).
I was probably getting 3X speed up in compilation speed (let's face it, C7 processor is really slow . . .), although it burns more power (i.e., more power = more electricity = more $$$ coming out of my wallet).
    In terms of drm-openchrome, it still has a nasty bug of X Server crashing when you change the screen resolution.
I have not figured out how to fix this bug yet, but in order to do this, I will likely have to rewrite large portions of frame buffer initialization code.
Also, the code still has issues with I2C bus control especially with those that use DVI.
Obviously, the code is long away from mainlining, but in order for the code to become mainlined, I think it is crucial for me to closely track DRM maintainer's drm-next so that this can happen eventually.

Regards,

Kevin Brace
OpenChrome Project maintainer / developer