Okay, I spent about 6 to 7 hours yesterday trying to figure out how to fix K8M890 chipset’s Chrome9 IGP’s mouse cursor not being displayed on the screen when running OpenChrome DRM. It turns out, OpenChrome DRM did not have the code to properly handle the older generation Chrome IGPs with only one hardware icon (in VIA Technologies documents, it is abbreviated as HI or HWI).

One major problem when dealing VIA Chrome IGP is that older models have support for only one HI, and it can be displayed on either IGA1 (primary display) or IGA2 (secondary display), but not both at the same time. Eventually, someone noticed that this is inconvenient, so VIA added a second HI. This is particularly helpful when one is using two screens at the same time, and portions of the screen overlap.

Going back to the discussion about HI, the problem is, there is no clear boundary of which models have dual HI and which models don’t. Based on some experiments I performed with OpenChrome DDX, it appears that K8M890 chipset’s Chrome9 IGP does not have support for dual HI. Just for the sake of discussion, K8M890’s graphics engine is called Chrome9, and its 3D engine has been rumored to be based on S3 Graphics DeltaChrome. DeltaChrome was probably the last time S3 Graphics (at the time, a fully owned subsidiary of VIA Technologies) seriously tried to reenter discrete PC graphics market back in Year 2003 to 2004 time frame. That being said, all the Chrome9 family’s 2D / video / display engines are merely the evolved version of UniChrome Pro’s 2D / video / display engines. For example, the hardware registers are generally backward compatible, and this makes it easier to take unified device driver approach to the graphics device driver development.

Anyway, once I was convinced that K8M890 chipset’s Chrome9 graphics engine has only one HI, I ported the working hardware cursor code from OpenChrome DDX to OpenChrome DRM. Luckily, I got the hardware cursor working the second time I compiled OpenChrome DRM code for the explicit purpose of fixing this bug. That’s pretty good considering that I expected this bug to be much harder than that to fix. I already have a patch I can apply to the existing OpenChrome DRM to fix this bug, but I will put off committing the code into the upstream repository for several more days since I am trying to get drm-next-4.xx branch to get to drm-next-4.17 (currently, it is at drm-next-4.15). I am also waiting for drm-next branch of DRM upstream repository to be updated with newer code so that I can advance drm-next-4.xx branch to drm-next-4.16 and then drm-next-4.17. After drm-next-4.xx branch gets to drm-next-4.17, I will apply the patch and commit the code into the upstream repository. Then, I will backport the code to the drm-next-3.19 branch.

For the next three days, I will be attending an electronic hardware industry trade show (DesignCon 2018), so I will have less time to work on OpenChrome. I will likely bring a laptop (my usual HP 2133 mini-note) to continue to work on the OpenChrome DRM code, but I do not expect to make that much progress for the next few days.