Redrix (HP Elite Dragonfly Chromebook) — Fedora 43 Issues, Findings & Requests for Guidance

wadem · March 11, 2026, 3:50pm

System Details

Device: Redrix (Alder Lake/Brya family), Intel Core i7-1255U
OS: Linux, Fedora 43 Workstation, GNOME, Wayland, PipeWire
Kernel: 6.18.16-200.fc43.x86_64
Firmware Type: UEFI Full ROM
Firmware Version: MrChromebox-2512.2 (01/25/2026)
Internal storage type: NVMe

Full disclosure, I have been using AI, along with lots of searching, to assist with this project so far, and even to summarize this post. I am a noob, so don’t hesitate to treat me as such. Additionally, it mostly just works with Fedora Workstation. I initially tried Manjaro based Big Linux, as that is what I run on my desktop, but it was far more cantankerous trying to set everything up.

I’ve been running Fedora 43 on my Redrix board for a short while and have made solid progress getting the system functional. I’m posting both to share what’s working and to seek guidance on several unresolved issues. I’ve done my best to document everything thoroughly including relevant log output. Also, for what it’s worth, it is funcional as is, just with caveats (which I assume is expected).

What’s Working (with fixes applied)

Suspend/sleep enters S3 deep sleep reliably after applying three fixes: the mem_sleep_default=deep kernel parameter, a systemd service to unload cros_ec_lpcs, cros_ec_keyb, and cros_ec_typec before sleep, and blacklisting the IPU6 camera modules. Without these the system would wake immediately after lid close.

Audio works correctly using the Pro Audio profile via WirePlumber. The accelerometer works and a manual tablet mode toggle script works for disabling the keyboard/touchpad and enabling auto-rotate. I get a notification popup in Fedora saying tablet/laptop mode when I run the script. Has anyone gotten tablet mode to work automatically when the lid is flipped?

Unresolved Issue #1 — xHCI Reset Loop During Suspend / Battery Drain

This is my most significant issue. While the system does enter S3, it never truly sleeps. The kernel log shows the xHCI controller resetting on a loop approximately every 20-30 seconds throughout the entire suspend period:

xhci_hcd 0000:00:0d.0: xHC error in resume, USBSTS 0x401, Reinit
usb usb1: root hub lost power or was reset
usb usb2: root hub lost power or was reset

The observable symptom is that the power button indicator light and keyboard backlight cycle on and off throughout suspend — on for ~20 seconds, off for ~1 second, repeat. This results in approximately 5-6% battery drain per hour in suspend, compared to days of standby on ChromeOS.This is after applying a fix from this thread here.

I will add, when I initially had Big Linux installed, Claude and I got the battery drain down to approximately 1% per hour.

I (AI) understand(s) ChromeOS uses S0ix which MrChromebox may not fully support on Redrix. Is this a known issue? Is there any workaround short of Submarine firmware?

Unresolved Issue #2 — Double Login on Resume

After waking from suspend, GDM presents the login screen. I enter my password successfully, but the session immediately collapses and GDM presents the login screen a second time. This happens on the majority of resumes. The timing varies — sometimes it happens before I even finish typing my password the first time, other times it takes up to ~20 seconds after the first successful login.

Relevant log entries around the event:

gnome-shell[2939]: Cursor update failed: drmModeAtomicCommit: Invalid argument
systemd-logind[936]: Delay lock is active (UID 1000/wadem, PID 2939/gnome-shell) but inhibitor timeout is reached.

Steps already taken with no resolution: masked fprintd, removed with-fingerprint from authselect, increased InhibitDelayMaxSec, applied and reverted i915.enable_psr=0 i915.enable_fbc=1. The drmModeAtomicCommit: Invalid argument error appears consistently before each double-login event. Any guidance appreciated.

Unresolved Issue #3 — Camera

IPU6 modules are currently blacklisted to prevent them from blocking suspend. I’m aware a fix exists but haven’t applied it yet. Has anyone confirmed this works on Redrix specifically? Any caveats?

Additional Issue — Keyboard Backlight Lost After Extended Poweroff

On two consecutive mornings, the keyboard backlight has failed to initialize after the machine sitting powered off overnight. Symptoms: the brightness indicator/gauge appears when pressing the physical backlight key, showing the level as empty/off. Adjusting via GNOME quick settings has no effect. The sysfs value (/sys/class/leds/chromeos::kbd_backlight/brightness) reports the correct brightness value (e.g. 100) but the keys remain unlit.

A standard reboot does not resolve it. The only fix found so far is a deliberate full power off (sudo poweroff), waiting ~30 seconds, then booting back up.

This only occurs after an extended cold poweroff (overnight). It does not occur after a normal reboot or short poweroff.

Pending / Not Yet Configured

Volume rocker — not yet configured, open to suggestions
Keyboard backlight timeout — not yet configured
Caps Lock remapping — planning to use GNOME Tweaks
Function keys — planning to use keyd
Microphone — just now tested, not working, open to suggestions

Submarine Firmware

I’ve been researching Submarine as an alternative to MrChromebox, particularly given the suspend and battery drain issues. The Ctrl+D on every boot is a deterrent but I understand it may resolve the S0ix and EC power management issues. Has anyone on Redrix specifically made the switch and can speak to whether it resolves the xHCI reset loop and battery drain? Any other tradeoffs worth knowing about?

I have read the thread on here, linked below, but can anyone confirm that everything is actually working as the OP claims.

References

Summary

Is the xHCI reset loop during S3 suspend a known issue on Redrix/Brya with MrChromebox firmware, and is there any software workaround short of switching to Submarine?
Has anyone experienced the double-login on resume with GNOME/GDM on Redrix? The drmModeAtomicCommit: Invalid argument error appears consistently before each occurrence — is this a known issue and is there a fix?
Has anyone successfully gotten the camera working on Redrix via the chromebook-linux-audio script with IPU6 modules, and are there any caveats?
For those who have switched to Submarine firmware on Redrix — does it resolve the S0ix/battery drain and xHCI issues? Any unexpected tradeoffs beyond the Ctrl+D on every boot?
The MrChromebox firmware utility script fails on Fedora 43 even with iomem=relaxed added to kernel parameters and secure boot disabled. Is running from a Live USB the only option for firmware updates on this distro, or is there another workaround? UPDATE: iomem=relaxed didn’t take the first time, it is now working!

Note — Kernel Oops with iomem=relaxed

In order to run the MrChromebox firmware utility script on Fedora 43, iomem=relaxed needs to be added to kernel parameters. While this parameter was active, a kernel oops was recorded:
```
Oops: general protection fault, probably for non-canonical address
0x3c4b2b7eff4c948a: 0000 [#1] SMP NOPTI
crash_function: blocking_notifier_chain_unregister
```
It was a single occurrence, timed to when the firmware script was running. iomem=relaxed was removed immediately after retrieving the firmware version info. No further oops events have occurred since removal.
Any recommendations for configuring the volume rocker on Redrix under Linux?
Has anyone gotten tablet mode to work automatically by just flipping the lid over into tablet mode?

Zidrewndacht · March 13, 2026, 3:40am

I don’t have much to contribute about Fedora/Linux quirks as I daily drive Windows on my Redrix, but here’s one thing I may help:

The tablet mode sensor was disabled in 2512 releases for brya-based boards, which include Redrix: accelerometer is not working in redrix · Issue #879 · MrChromebox/firmware · GitHub. If you’re running one of those releases, that’s probably your only problem.

I don’t know if MrChromebox already updated the builds offered by the firmware utility script, if he did then updating should be all you need to get tablet mode working. Otherwise you may have to manually install the firmware from the issue above.

I can also tell that the sleep issue doesn’t exist in Windows, mine uses up about 150mW of power during S3 (S0ix is disabled in mine), and can sleep for multiple days without worry. The power LED stays completely off during S3 (strangely so, yes, but it is indeed sleeping and not hibernated or off, as it wakes up imediatelly on a wake event instead of booting from disk. In fact, S4 is disabled in the OS).

So the firmware can reliably sleep just fine in S3 at very low power and the issue should be fixable in Linux side. Linux is very flexible, after all.

wadem · March 13, 2026, 11:05pm

Hmm, I read through that thread and seen you confirmed the link that Mr Chromebox posted did fix your issue, both for Fedora 43 and Windows. I also noticed the date of those posts are Feb 02. The firmware I am on is 2512.2 (01/25/2026). I have not tried installing that fix as my accelerometer is working, so I’m not sure we share the same root cause. My specific issue is activating tablet mode via lid flip.

My system can see the lid switch (I think), but the lid switch isn’t firing for some reason (might be watching the wrong switch). Additionally, after forcing tablet mode via the terminal, my touch pad, physical keyboard and backlighting would not disable. Scaling and screen auto rotation work excellent for me. That’s why I have a script to toggle tablet mode on/off, and it also disables the physical keyboard, backlight, touchpad, and also toggles the virtual keyboard (OSK) on.

Again, I am as green as can be, but I have dabbled over the years. That said, I am leaning on Claude pretty heavitly and Google-ing (or DuckDuckGo-ing).

I originally installed Manjaro based Big Linux and most everything was horrible. But, the lid switch for tablet mode did fire on Big Linux. We had to write scripts to disable keyboard and such as well, but the script would automatically run with the lid flipped (just like tablet mode should). Rotation didn’t work and scaling was horrible, but the lid switch was firing. This is when I first stumbled across the thread you linked. I was going to apply that fix, but Big Linux needed so much work that I decided to jump to Fedora instead, as Gnome seems to be better optimized for touch screens.

This is where I am totally lost, and the main reason why I decided to reach out for some guidance. With the Big Linux install we had to write a script to disable bluetooth on sleep (and re-enable on wake) because bluetooth wouldn’t let the computer enter sleep mode and hogged 72% battery in 6.5 hours overnight. After that, the computer used around 7% battery over 7.5 to 8 hours (exact time eludes me) the following night.

I did apply a fix from the suspend thread that I linked in my original post and it has helped tremendously with the Fedora sleep issue. Fedora is sleeping fine and I have no failed sleep sessions, as far as I can tell. Something is cycling the keyboard backlight on for 20s and off for about a full second, and then repeating that pattern the entire time it is sleeping. Turning the keyboard backlight off before closing the lid does not chage this behavior either.

I appreciate your reply nonetheless. Also, do you have any knowledge of, or experience with, the Submarine firmware in the other thread I linked? It looks too good to be true is why I am hesitant. I am strongly considering giving it a go though.

Zidrewndacht · March 13, 2026, 11:40pm

Still worth a try. I’m pretty sure the ‘accelerometer not working’ in the issue was actually a consequence of the lid switch, as, by default, the OSes only answer to rotation when in tablet mode.

Then, when you manually force-enabled tablet mode, rotation started working because the accelerometer itself wasn’t really unavailable, the OS just ignored it because one wouldn’t want to rotate a clamshell laptop.

The fact you say the sensor works in Big Linux puzzles me though. For sure the public 2512.2 release had it not exposed, maybe that distro accesses it some other way than relying on firmware?

I never tried Submarine as my original intent for this device always was to put Windows on it.

But you mention that “The Ctrl+D on every boot is a deterrent”, you should be able to disable this on Google’s firmware by changing the GBB flags with MrChromebox’s script, you can set it to boot to AltFw by default with short timeout. This requires disabling write protect, but this won’t be an issue for you since you’re already on a Redrix with Full ROM so you probably have a SuzyQ?

Which means that there’s a chance Submarine might be your solution indeed.

bookofchrome · March 14, 2026, 12:22pm

Huh… That’s a bit weird. I have a brya-based chromebook (crota360) and all the major linux distributions as well as Windows can’t see the sensor hub on my device and it is treated as a clamshell.

wadem · March 14, 2026, 8:57pm

I decided to give Submarine a test spin. It does work better out of the box and requires fewer fixes I guess. I’ll probably stick with it. Tablet mode is a little wonky but generally works without any fixes appled. I’ll probably tinker with it a bit.

Last night I reverted back to stock and didn’t install Submarine/Ultramarine on it until this morning. I noticed that the power led indicator, while on chrome os, doesn’t stay illuminated either. The indicator on my stock HP Elite C1030 slowly pulses while sleeping. Just thought I’d mention it.

UPDATE:

From 10:15 PM to 6:05 AM my battery went from 57% to 54% while sleeping. This is using the Submarine method linked in my original post. For reference, the night before when I went back to full stock, from 12:30 AM to 7:42 AM it went from 100% to 98% while sleeping.

wadem · March 14, 2026, 9:11pm

If you’re interested, here is an AI summary of how we got tablet mode functioning on Manjaro based Big Linux.

Sure! Here’s a comprehensive summary of everything we did to get tablet mode working on the HP Elite Dragonfly Chromebook (Redrix) under Big Linux/Manjaro KDE:

HP Elite Dragonfly Chromebook (Redrix) - Tablet Mode Fix on Manjaro/Big Linux

Hardware confirmed working:

cros-ec-accel (x2) — accelerometers
cros-ec-lid-angle — lid angle sensor
cros-ec-gyro — gyroscope
cros-ec-light — ambient light sensor
SW_TABLET_MODE switch via /dev/input/event4 (GOOG0007)

Problem: Screen turning off when folding into tablet/tent mode.

Root cause: KWin was detecting the SW_TABLET_MODE input switch and turning off the internal display.

Solution 1: Block KWin from accessing the tablet mode switch

Create /etc/udev/rules.d/99-tablet-mode.rules:

SUBSYSTEM=="input", KERNEL=="event4", OPTIONS+="static_node=input/event4", TAG+="uaccess", MODE="0600", OWNER="root"

Reload udev:

sudo udevadm control --reload-rules
sudo udevadm trigger
sudo reboot

This restricts the tablet mode switch to root only, preventing KWin from reading it directly while allowing our root systemd service to handle it.

Problem: Keyboard backlight staying on in tablet/tent mode, and display needed to be re-enabled after KWin turns it off.

Solution 2: Tablet Mode Handler Script

Install evtest:

sudo pacman -S evtest

Create /usr/local/bin/tablet-mode-handler.sh:

#!/bin/bash
BACKLIGHT=/sys/class/leds/chromeos::kbd_backlight/brightness
USER_NAME="wadem"
USER_ID=$(id -u $USER_NAME)

evtest /dev/input/event4 | while read line; do
    if echo "$line" | grep -q "SW_TABLET_MODE.*value 1"; then
        echo 0 > $BACKLIGHT
        sleep 0.5
        sudo -u $USER_NAME DISPLAY=:0 WAYLAND_DISPLAY=/run/user/$USER_ID/wayland-0 XDG_RUNTIME_DIR=/run/user/$USER_ID kscreen-doctor output.eDP-1.enable
    elif echo "$line" | grep -q "SW_TABLET_MODE.*value 0"; then
        echo 50 > $BACKLIGHT
    fi
done

Replace wadem with your username.

Make it executable:

sudo chmod +x /usr/local/bin/tablet-mode-handler.sh

Create /etc/systemd/system/tablet-mode-handler.service:

[Unit]
Description=Tablet mode handler for keyboard backlight
After=multi-user.target

[Service]
Type=simple
ExecStart=/usr/local/bin/tablet-mode-handler.sh
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Enable and start:

sudo systemctl enable --now tablet-mode-handler.service

Problem: Auto-rotation not working in tablet mode.

Solution 3: Install iio-sensor-proxy

sudo pacman -S iio-sensor-proxy

iio-sensor-proxy starts automatically via D-Bus activation. This enables:

Screen auto-rotation via accelerometers
Ambient light sensor
Tilt detection

Verify it’s working:

monitor-sensor

Problem: Virtual keyboard not appearing when tapping text fields in tablet mode.

Solution 4: Configure Maliit Virtual Keyboard

Maliit should already be installed:

pacman -Qs maliit

If not:

sudo pacman -S maliit-framework maliit-keyboard

Configure KWin to use Maliit:

kwriteconfig6 --file ~/.config/kwinrc --group Wayland --key InputMethod /usr/share/applications/com.github.maliit.keyboard.desktop
kwriteconfig6 --file ~/.config/kwinrc --group Wayland --key VirtualKeyboardEnabled true
qdbus org.kde.KWin /KWin reconfigure

Then open System Settings → Virtual Keyboard and select Maliit.

Problem: KDE Plasma switching to tablet UI mode causing panel scaling issues when rotating.

Partial workaround: Add to ~/.config/kwinrc under [Input] section:

[Input]
TabletModeEnabled=false

Note: This is a partial fix only. The panel layout breaking on screen rotation is a known upstream KDE Plasma 6 bug with no full fix currently available.

Known remaining issues:

Panel layout breaks when rotating between landscape and portrait in tablet mode — upstream KDE Plasma 6 bug
Physical keyboard/touchpad correctly disables in tablet mode
Virtual keyboard works in tablet mode
Auto-rotation works
Screen stays on in tablet/tent mode
Keyboard backlight turns off in tablet mode

Hope this helps others on the Chrultra forum!