This repository contains workarounds for the Huawei Matebook E Go (8cx Gen 3) to support Linux.
This project mainly refers to the following projects:
- jhovold: who contributes to the mainline to support X13s and SC8280XP (8cx Gen 3).
- steev: who maintains the kernel for X13s.
- linaro team: who authored the Lenovo c630 EC driver(first proposed), and showed an example how to write auxiliary device modules.
- Nikita Travkin: who authored the very first(first upstreamed) Acer aspire1(sc7180) i2c EC driver.
- aymanbagabas: who authored Huawei laptop wmi driver and showed the meaning of ACPI identifiers like GBTT, SBTT, etc
- NewWheat: who helped me find EC interrupt, and offered one copy of i2c EC driver for reference.
- chenxuecong2 & matalama80td3l: who migrated the initial device tree from X13s' and added a framebuffer for the Huawei Matebook E Go.
The time span is very long. If I forget someone's work, please remind me, if I recall something, I will add it.
Initial dt support will land on 6.14, currently, they are in qcom -next tree, see here.
I am just an amateur, a Linux noob, not educated with formal CS courses. You should never believe what I say below, except this sentence. I am not responsible for your actions; you do this all at your own risk!
The DT works with steev's latest branch. You should extract the firmwares required by DT, and get them well placed, you can find them in the Windows OS DriverStore directory. (Update: AUR here)
Use steev or jhovold one with default config and simplefb enabled. (Update: AUR here)
Kernel parameter: clk_ignore_unused pd_ignore_unused arm64.nopauth efi=noruntime
Search for gaokun from another one of my repo, here.
The image and a copy of packages from another repo, see release.
User and password are both alarm and both root.
Refer to this as well. If you want to see some spoilers, check this.
With kernel version 6.12 by steev. (I write against the latest stable kernel release only.)
| Feature | Status | Note |
|---|---|---|
| Audio | works | see below |
| Backlight | x | DSI DCS-based backlight control, control method had been figured out. There is an I2C baclkight IC, power supply and how to enable keep unknown |
| Battery | works | some attributes are hidden, like cycle count is also supported |
| Bluetooth | works | RF performance is incredible when you have set calibration data for wifi(they are both on the chip of WCN6855) |
| Camera | x | have no plan to support them yet |
| CPUfreq | works | |
| Display | x | There is no DSI driver for SC8280XP now. I added some patches to patch sets folder, but still not work |
| Display sensors | x | for rotation detect, light detect, etc. Added slpi nodes, but how can we access it? |
| EC | works | Battery and adapter status, wmi, ucsi,maybe modern standby |
| EFI variables | works | with the patch. |
| Fingerprint reader | x | mbn firmwares related which means that is complicated. x13s one was introduce from commit. |
| GPU | works | Freedreno 690(FD690), remember to install vulkan-freedreno to enable vulkan support. |
| Hibernation | x | |
| Keyboard & Touchpad | works | |
| Keyboard fn keys | partial | brightness, volume adjustment, screen lock |
| Lid | x | basically works, revaluate it until dsi panel works |
| NVMe SSD | works | |
| PCIe (x4) | works | |
| Power key | works | |
| Remoteproc | works | adsp, cdsp, sdsp(sensors related, see below) |
| RTC | works | |
| Suspend | works | s2idle |
| Thermal sensors | works | partial I think |
| Touchscreen | partial | weird behavior |
| TPM | x | |
| USB | works | |
| USB-PD | works | With UCSI EC driver, charging power is up to 45W compared to 23w before, can be used as sink and source |
| USB-C DisplayPort Alt Mode | works | initial support, wait for upstream to fix Qualcomm's quirks |
| Video acceleration | works | see below |
| Virtualisation | x | |
| Volumn keys | works | |
| Watchdog | partial | One in sc8280xp works, another in EC not(acpi method identifiers have not been figured out yet) |
| Wi-Fi | works | see below |
| WMI related features | partial | charging control, FN lock, smart charge, thermal sensors and so on(undiscoverd things due to its meaning is unknown) |
Caution
Recently, UCSI subsystem is buggy for this tablet. Chances are that failed to boot(auto reboot). Only plug into Type-C ports after booting up.
Support 2-lane only for now, Johan mentioned this also, but we don't require insert orientation.
In default, the bandwidth of per lane is limited to 5.4Gbps(HBR2, DisplayPort 1.2 or later). If you want to a higher limit, set this.
...
&mdss0_dp0_out {
...
link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000 8100000000>;
...
};
...
According to the dcoument of Windows Dev Kit 2023, USB-C ports support 8.1Gbps per lane(HBR3, DisplayPort 1.3 or later).
In my case, the monitor supports DisplayPort 1.1 with 2.7Gbps per lane, data rate is 4.32Gbps(8b10b coding), basically, it means I can only use 1920x1080@60Hz. However, if we tweak the timings(at your risks), we can support a decent resolution with a rich timings, 24bpp with 2048(+180H.Blanking)x1280(+60V.Blanking)@60hz
This part is not that stable, you may get a auto reset when you plug out or replug, after all, I havn't mastered the whole procedure yet(Reversing is like that, you can't ask for too much or perfect, lol), some of them are related to Qualcomm's quirks, some are my code issues. I am working on it to minimize the potential harm to your device.
If you encounter the following, reboot, it is rare, but still possible.
gaokun_ucsi.ucsi gaokun_ec.ucsi.0: error -ETIMEDOUT: PPM init failed
gaokun_ucsi.ucsi gaokun_ec.ucsi.0: con1: failed to register alt modes
If there is no issue now, let's plug in wait for seconds.
Note: if you plug out when there is no other video output device(logical), replug will not work.
Recently, use the X13s' profile.
sed -i 's/LENOVO.*ThinkPad X13s.*/LENOVO.*ThinkPad X13s.*|HUAWEI.*MateBook E.*\"/' /usr/share/alsa/ucm2/Qualcomm/sc8280xp/sc8280xp.conf
echo 'start stop' /sys/devices/platform/gaokun-wmi/charge_control_thresholds
Clarification from TLP.
Start charge threshold (START_CHARGE_THRESH_BATx): battery charge level below which charging will begin when connecting the charger.
Stop charge threshold (STOP_CHARGE_TRESH_BATx): battery charge level above which charging will stop while the charger is connected.
The values would not be saved after you shut down and plugged out, the default values are set to 0 0 at next boot, you can use udev to set the default values like 55 60,
ACTION=="add", SUBSYSTEM=="platform", KERNEL=="gaokun-wmi", ATTR{charge_control_thresholds}="55 60"
Explanation, refer to Huawei support page
cat /sys/devices/platform/gaokun-wmi/smart_charge
cat /sys/devices/platform/gaokun-wmi/smart_charge_param
When the laptop is just connected to a power adapter, it starts charging until the battery level reaches 70% if the battery level is lower than 70%, or the battery level does not increase if the battery level is 70% or higher. This is normal.
When the power adapter is always connected, the laptop starts charging if its battery level is lower than 40%, and stops charging when the battery level reaches 70%.
smart_charge: default are 4 72 40 70, correspond to charging mode, delay, start, stop, after 72 hours, charging level is limited to 70%.
smart_charge_param: enable or not? Recently, If it is 1, then charge power might be up to 23W.(unsure)
If you set charging control on Windows, like 90%, then smart_charge would be 1 72 85 90, charge_control_thresholds would be reset to 85 90 also.
- front: hi846 or s5k4h7
- rear: ov13b10 or s5k3l6
There are too many unknowns(dsi support, dual dsi with video mode dsc, gpio, power supply, backlight, etc), no actual progress can be confirmed, I have uploaded all my progress, if you have an idea, then go ahead.
Addition: Some patches are first proposed by matalama80td3l at here. I verified and completed them.
+-------------+ +-------+
| framebuffer | ---> | plane |\
+-------------+ +-------+ \ +------+ +---------+ +---------------+ +-----------+
|---> | CRTC | ---> | encoder | ---> | dsi connector | ---> | dsi panel |
+-------------+ +-------+ / +------+ +---------+ +---------------+ +-----------+
| framebuffer | ---> | plane |/
+-------------+ +-------+
framebuffer should be okay, as we can capture screenshot. plane and CRTC are unsure, but information from debugfs indicate primary plane and cursor plane are alright. There are many issues with DPU encoders, dual-dsi support issue, dsi video mode dsc support issue, etc. Upstream has been committing patches to fix them. If other parts function well, panel should show garbled or something else. As for connector, I guess they have no plan to support, there are few devices shipped with dsi panel. I have added support for dsi and dsi phy, which is guessing based on SM8350 and SM8450. Also, I have added support for DSI panel.
){kind=link}
Some issues:
- dsi fifo error:
dsi_err_worker: status=4. - backlight: there is a backlight ic which is controlled by i2c, once we enable
msm(I think the cause isdpu), dsi panel reinit, I guess backlight ic would be disabled, in fact, some i2c4 slaves disappeared, I think there must be garbled on screen, we can't see it due to disabled backlight.
During the probe of panel, after we sent initial code to dsi(prepare), then dpu would send video stream to dsi, if we created a backlight device previously, KMS would turn on it for us(enable), but we would get msm_dsi ae94000.dsi: [drm:dsi_cmds2buf_tx [msm]] *ERROR* wait for video done timed out, because backlight ic wouldn't respond.
echo 0/1 > /sys/devices/platform/gaokun-wmi/fn_lock_state
0: disable the fn key(hotkey first, such as press F1 to decrease brightness)
1: enable the fn key(function key first), you can only trigger hotkey with Fn + F1-12
BTW, you can press Fn key(light on) to reverse it temporarily.
I don't know these sensors for which devices, but you can read them
cat /sys/devices/platform/gaokun-wmi/temperature
SLPI(Sensor Low Power Island), more details.
[ 2.606897] remoteproc remoteproc2: remote processor 2400000.remoteproc is now up
[ 2.613505] qcom,fastrpc 2400000.remoteproc:glink-edge.fastrpcglink-apps-dsp.-1.-1: no reserved DMA memory for FASTRPC
The firmware of slpi can be loaded, you can also find /dev/fastrpc-sdsp, not support IOMMU for now. Even though, how can I access sensors?
The firmware can be loaded.
The api like VA-API, VDPAU, which are most modern tools/apps supported, like firefox, vlc, obs-studio. This platform does not support them,(It supports v4l2_m2m) so there is no easy way to test it.
Use the script,
extract all files from the board file, you can get it from your local directory or here,
./ath11k-bdencoder -e board-2.bin
edit board-2.json, let us use x13s one calibration data,
...
"board": [
...
{
"names": [
"bus=pci,vendor=17cb,device=1103,subsystem-vendor=17cb,subsystem-device=0108,qmi-chip-id=2,qmi-board-id=255,variant=HW_GK3"
],
"data": "bus=pci,vendor=17cb,device=1103,subsystem-vendor=17cb,subsystem-device=0108,qmi-chip-id=2,qmi-board-id=140,variant=LE_X13S.bin"
},
...
]
...
regenerate it,
./ath11k-bdencoder -c board-2.json
-
refactor ECCD implementation to avoid data inconsistency(local repo finished, replacement work still remains)(New paln: try to add an abstracion layer, but the related dsdt implementation is ..., huawei you sucks) - refactor UCSI part code
- add a sysfs to tweak EC
- add the altmode part code to UCSI
- fix Qualcomm's quirks
Some people have asked me for an early access. Now I explain here.
Remote repo is far behind local repo due to stability, and my local repo is quite different.
Why don't you create another branch for it? No, if I open it, I should clarif my intentions, I am tired of constant maintenance, I don't like commit every piece of modification, because I start over again when my new ideas don't work, I will most likely delete all I have written. That is time-wasting to keep track those things. Every time I work on one part only, I can maintain context in my brain, until things are settled, I will update my local repo. After some tests, I will plan to update remote repo.
About the ETA of any features, I promise nothing. And, as an amateur, I have my own life, my coding time is flexible.
I am occupied with real life things, I spend much free time on it, if someone can help me test features, that will be awesome. Also, as I am an amateur, I am happy to receive suggestions from coding, ACPI/DSDT/SSDT reversing, working mechanism of DSI panel, etc.