As promised, drm-next-4.14 branch is now EOL (End of Life). The new drm-next-4.15 branch is getting within a dozen commits of drm-next-3.19 branch. drm-next-3.19 branch is still being maintained in order to test OpenChrome DRM against VIA C3 processor and CLE266 chipset. Due to VIA C3 processor not having PAE (Page Address Extension), there aren’t too many Linux distributions I can run VIA C3 processor these days. I tried Debian 8 with Linux 4.13 rc5+ kernel, but unfortunately, it suffers from storage (i.e., hard drive) recognition problem after resuming from a standby, so it is practically useless as a test configuration.

In order for the drm-next-4.xx branch to catch up to drm-next-3.19 branch, I did use a faster computer to compile OpenChrome DRM. I used AMD Athlon 64 X2 based computer with ECS K8M890M-M mainboard. With -j3 option when compiling the Linux kernel (make -j3), I can now get OpenChrome DRM to compile in about 5 minutes as long as the Linux kernel is already precompiled (i.e., compiling OpenChrome DRM only). I think this is pretty good considering that it takes HP 2133 mini-note’s VIA C7-M processor about 25 minutes . . . VIA C7-M is a horrendously slow microprocessor . . . Anyway, this ECS K8M890M-M mainboard does not support ACPI S3 State correctly (it tells Linux kernel it supports S3 State during boot time, but in reality, it does not turn off the fans, so it appears to be faking the S3 State behavior of all the fans turning off), so I do not really like it as a mainboard. One thing I never liked about ECS is that for some reason, they do not support ACPI S3 State with Taiwanese chipsets (i.e., VIA Technologies, SiS, etc.), but supports it with Intel or NVIDIA chipsets. I do not buy the notion that VIA or SiS chipsets’ ACPI S3 State implementation to be broken since major vendors like ASUS, GIGA-BYTE, MSI, etc. have supported them since Year 2002 or so.

Anyway, it appears that VIA K8M890 chipset’s Chrome9 IGP has only one hardware cursor instead of two for newer chipsets (i.e., P4M900 chipset). What this means is that when operating in a dual head configuration, X Server has to activate software cursor or one of the screen will not have a cursor displayed. At this point, OpenChrome DRM’s hardware cursor support for K8M890 chipset is broken. I am now actively trying to figure out a fix for this issue since I cannot really test OpenChrome DRM on K8M890 chipset too extensively due to the missing hardware cursor making the computer very hard to operate.