Alienware G-Mode on Linux: what the key does and how to get it back

What G-Mode actually is

On Windows, pressing the G-key (Fn+F1 on Alienware m- and x-series, a dedicated key on Dell G-Series) tells Alienware Command Center to do two things in firmware: select the G-Mode thermal table, which pins the fans high and lifts the sustained power envelope, and flip a flag Dell calls Game Shift status. The kernel documentation for the interface describes Game Shift as "some sort of CPU/GPU power profile" that does not itself change the fan profile. Both live in the embedded controller and the WMI firmware interface; AWCC only asked for them.

Two consequences. First, G-Mode survives without AWCC as long as something can call the same firmware methods. Second, on Dell G-Series the key itself flips Game Shift status in firmware, so pressing it on Linux is not entirely inert even with nothing bound. On Alienware laptops the key is just a key.

How the key shows up on Linux

The G-key arrives as PS/2 scancode 0x68 from the internal keyboard. systemd's hardware database maps it for every Alienware and Dell machine:

evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAlienware*:pn*:*
 KEYBOARD_KEY_68=!performance   # Fn+f1 Performance mode toggle

The ! marks a key that never sends a release event, so one is synthesized. performance is KEY_PERFORMANCE, evdev keycode 701. Confirm on your machine with udevadm info /dev/input/event3 | grep KEYBOARD_KEY_68 (the event number of "AT Translated Set 2 keyboard" varies), or watch it live with sudo evtest, or wev on Wayland.

Nothing in the kernel acts on it. Whether your desktop does depends on the session:

• X11 cannot see it. X keycodes stop at 255; keycode 701 is above the range, so xev, xbindkeys and every X11 shortcut dialog stay silent.
• Wayland compositors receive it through libinput, and recent xkbcommon names it XF86PerformanceMode. Some desktops let you record it in a shortcut dialog, some do not, and none we could verify ship a default action for it.

What alienware-wmi exposes

The mainline alienware-wmi driver has exposed the AWCC thermal profiles through the platform-profile API since Linux 6.13, and G-Mode toggling is part of that support: on models the driver flags as G-Mode capable, selecting the performance profile activates firmware table 0xAB and toggles Game Shift on; selecting anything else toggles it off. Fan RPM, temperatures and fan boost followed in 6.16. That is the whole kernel story; there is no separate "gmode" file.

Whether your model gets the G-Mode quirk depends on the driver's DMI table. The m18 R2 matches the "Alienware m18" entry (substring match) and gets it. Unlisted models get no profiles at all until they are added; force_gmode=1 exists as a module option for testing, alongside force_platform_profile=1.

Check what your kernel advertises before assuming anything:

cat /sys/class/platform-profile/platform-profile-0/choices
# m18 R2: cool quiet balanced balanced-performance performance custom

If performance is missing, the driver did not enable profiles for your model. If balanced-performance is missing but performance is present, you have Performance, not G-Mode, and any tool that claims otherwise is guessing.

Cryo builds that mapping from the kernel's advertised choices at startup: when both balanced-performance and performance are present, performance is labeled G-Mode; when only performance is, it is labeled Performance, because on those machines that is what the firmware means. Older legacy-table models use different ids (0x96 to 0x99) and a smaller set; the m18 R2 is a USTT machine.

Bind the key yourself

The portable approach is to remap the scancode to a key every session can see, then bind that key in your desktop. prog1 (KEY_PROG1, keycode 148) becomes XF86Launch1 in both X11 and Wayland.

1. Find the scancode: sudo evtest, pick the AT keyboard, press the G-key, note MSC_SCAN (0x68 on the m18 R2; it can differ on other models, or arrive from the "Dell WMI hotkeys" device instead).

2. Create /etc/udev/hwdb.d/70-gmode-key.hwdb, using svnDell* on a G-Series:

   text

   evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAlienware*:pn*:*
    KEYBOARD_KEY_68=prog1

3. Apply it: sudo systemd-hwdb update && sudo udevadm trigger --sysname-match="event*".

4. Confirm with evtest that the key now reports KEY_PROG1.

5. In your desktop's keyboard-shortcut settings, bind XF86Launch1 to cryoctl gmode, or to a script if you are not running Cryo:

   sh

   #!/bin/sh
   p=/sys/class/platform-profile/platform-profile-0/profile
   [ "$(cat $p)" = performance ] && echo balanced > $p || echo performance > $p

   The script needs root for the write; a polkit rule or a sudoers entry scoped to that single command is the honest way to grant it. cryoctl gmode needs neither, because the daemon owns the write and the CLI only talks to its socket. The toggle goes to G-Mode, or back to the configured after_game profile (Balanced by default).

Caution. This puts maximum fan and power on one keypress. Do not bind it to anything that can fire while the laptop is closed in a bag, and check that resume from suspend does not replay it.

Game-aware: what Cryo does

The manual toggle is half of it. Cryo's daemon also switches profiles when a game starts and back when it ends, and the definition of "a game" is deliberately strict because on the m18 R2 the compositor itself can sit on the RTX 4080 at 25 to 50 percent utilization.

Once a second the daemon asks NVML for the dGPU's graphics processes. A candidate is one holding at least 400 MB of VRAM whose executable name is not on an exact-match ignore list (compositors, Steam's own UI, browsers, VS Code). A game starts when a candidate exists and utilization stays at or above 50 percent for 10 consecutive seconds. It ends when the candidate disappears or utilization sits at or below 20 percent for 45 consecutive seconds, long enough to survive loading screens. On start the daemon records the current profile and writes the configured on_game target (G-Mode, or Performance on machines without it). On end it restores the recorded profile. Manual picks in between are respected, because rules fire only on those two transitions.

This needs the NVIDIA proprietary driver; without NVML the detector switches itself off and everything else keeps working. AMD dGPUs are out of scope for now.

Battery versus AC

Firmware lowers its power limits on battery whatever profile is selected, so G-Mode unplugged mostly buys noise. Cryo's default rules move to Quiet when the charger is unplugged and to Balanced when it returns, again on the transition only, so a manual choice sticks until the next event. The AC supply is discovered by type (Mains) rather than by name, since firmware calls it AC, ACAD or ADP1 depending on the model; if none is found, battery rules never fire and everything else works. cryoctl doctor prints which supply, if any, was found.

One thing the code does not do: game detection does not check the power source. Start a game on battery and it still enters the on_game profile. If you would rather it did not, set on_game to balanced or switch auto.enabled off while unplugged.

Troubleshooting

The key does nothing. On X11, expected; remap as above. On Wayland, run wev and press it. If nothing arrives, check udevadm info for the hwdb match, since a model whose G-key comes from the "Dell WMI hotkeys" device uses a different scancode.

The profile flips back. Something else is writing the file. Suspects, in order: power-profiles-daemon or tuned-ppd, if powerprofilesctl list shows a platform driver; a game ending, if Cryo's restore fired; a suspend cycle, after which firmware can come back in a different profile (Cryo's cryod-resume.service re-asserts it). cryoctl status shows the current profile and whether the daemon thinks a game is running.

Fans do not ramp on the m18 R2. Read the profile back: cat /sys/class/platform-profile/platform-profile-0/profile. If it says performance, the write took and the EC is running the G-Mode table; whether that table spins up at idle or only under load is the firmware's decision. If you want an immediate ramp, that is a boost write (cryoctl boost cpu 100), and Thermal Guard forces one at 88 °C regardless.

Lighting does not change. Correct. Neither the kernel nor Cryo couples lighting to the profile; whatever lighting change you remember from Windows was application-side. Chain it in the key's command (cryoctl gmode && cryoctl light static ff2d2d) if you want it back.