Hide frontlight controls on Xiaomi Reader and Moaan Mix7 (both RK3566)

[jkl16]

Problem

The Xiaomi Reader (rk3566_eink) and Moaan Mix7 have a frontlight, but the launcher has no driver for it. They fall through to GenericController, which adjusts the window brightness attribute. That has no effect on these panels, so KOReader shows a Frontlight menu entry, gesture actions and a footer brightness item that do nothing.

The RK3566 lights driver from #573 does not work here either. It writes to the lm3630a_leda / lm3630a_ledb sysfs backlight nodes and InkBook system properties, which these devices do not expose.

Change

• Add QUIRK_UNSUPPORTED_LIGHTS in DeviceInfo.kt for devices that have lights no available driver can control. This is deliberately separate from QUIRK_NO_LIGHTS, whose entries all lack frontlight hardware, so the existing list keeps its literal meaning.
• Device.hasLights is now false when either quirk is set. KOReader reads this through android.hasLights() and hides its frontlight UI.

Why hide rather than add a driver

On these devices the system already offers a good frontlight experience. Brightness and warmth are one swipe away in the system quick settings, and the firmware has an auto brightness option that adjusts to ambient light.
A KOReader driver would compete with that: it would have to write through a private vendor API, and any level it sets would be overridden as soon as the system's auto brightness or cached settings kick in. Leaving the light to the system is the simpler and more reliable behaviour, and hiding the non-functional controls makes that explicit.

Notes

• Moaan Mix7 is included because it runs the same Moaan firmware as the Xiaomi Reader.
• Tested on Xiaomi Reader: the Frontlight entry, gesture actions and footer item are gone; system brightness control is unaffected.

---

This change is 

[hugleo]

Just add your devices to https://github.com/koreader/android-luajit-launcher/blob/master/app/src/main/java/org/koreader/launcher/device/DeviceInfo.kt#L773 since the quirk is doing the same thing.

[Frenzie]

But maybe add a tiny one-line comment saying it doesn't actually have no lights but that there's no added value to controlling them.

[jkl16]

I did consider adding them to QUIRK_NO_LIGHTS. I kept a separate quirk because I prefer code that documents itself: every device in QUIRK_NO_LIGHTS has no frontlight hardware, while the Xiaomi Reader and Moaan Mix7 do have one that we just can't drive. Merging them would make the "devices without lights" list untrue.

That said, this is a small thing and I don't want to hold up the PR over naming. If you'd both rather keep a single list, I'm happy to fold the two entries into QUIRK_NO_LIGHTS with a comment on each line, just say so and I'll update the branch.

[hugleo]

Yes, a QUIRK_NO_LIGHTS with a comment will do it

[jkl16]

Updated the branch:

• Moved both devices into QUIRK_NO_LIGHTS as suggested.
• Also added the RK3566 getWaveformFull fix. It returned EPD_AUTO (0), which MainActivity.einkUpdate() drops as invalid, so every full refresh was a no-op on these devices. The same fix is part of Add Rockchip e-ink device support: RK357x EPD controller, RK3566 full-refresh fix, OBOOK R501, Flow Mini #611, but that PR has been sitting without approval and bundles several unrelated device additions. Including it here gets the RK3566 devices a working full refresh without waiting on that one.

[hugleo]

Looks like RK35xxEPDController.kt is already working for the Xiaomi 7 Reader: #478

You may break other devices if you change EPD_AUTO globally. It would be better to use a separate driver for this.

Also, I don't think the changes here will have any effect, because setMode is commented out and the code only calls sendOneFullFrame():

https://github.com/koreader/android-luajit-launcher/blob/master/app/src/main/java/org/koreader/launcher/device/epd/rockchip/RK35xxEPDController.kt#L57C19-L57C26

[jkl16]

What I did in #478 those 2 years ago only made EPD test procedure work properly for all RK3566 devices. Due to EPD_AUTO being interpreted as "invalid" (as described in #611) full screen refresh does not work on any RK3566 devices when requested directly by KOReader (another proof of this faulty behaviour is #608).
TLDR: EPD_AUTO value inside getWaveformFull() is a global bug for all RK3566 based readers - you only get a refresh in the test mode.

When it comes to sendOneFullFrame(), then it IS a proper way to do a refresh on those devices. Call to setMode would change the refresh algorithm, which is a totally different thing.

[hugleo]

All right, now I understand. getWaveformFull with 0 doesn't even call sendOneFullFrame because is ignored in some if/else clause...