Onboard memory and background software keep your profile in different places. On a locked-down tournament PC, that difference decides what still works. A setting saved in the keyboard's own memory can be read and applied by its firmware at startup, but a software profile may only work while its program runs on the computer.
Neither approach guarantees your setup will behave the same way at an event. The safe rule for keyboard profile storage is simple. Count on a setting only after you've confirmed it works with the required software unavailable, and use software-dependent features only where the event lets that software run.
How Onboard Memory Differs From Software Profiles
The difference that matters is where a setting lives when you plug into a computer you don't control. Two documented examples show each side. They come from different keyboards, so treat them as two separate illustrations rather than a head-to-head test.
On the firmware side, QMK is open-source keyboard firmware. Its documentation describes settings stored in the controller's EEPROM that are kept even after power loss. EEPROM is a small block of memory on the keyboard's controller chip that holds data with the power off. In QMK's example, the firmware reads that stored config when the keyboard starts up and uses it right away to set the default layer's RGB color. The value travels with the keyboard, and the keyboard applies it on its own.
The software side works differently. Lenovo's user guide for the Enhanced Performance USB Keyboard Gen II and the Lenovo 700 Multimedia USB Keyboard says its RapidAccess keys must work with the software program. The same guide describes profiles you create for each app, and those profiles switch automatically based on the active app. That behavior depends on the program being installed and running on the computer.
That's why the distinction matters at a tournament. A setting applied by firmware can still work on a computer that blocks installs. A function that needs a host program has no fallback if the event computer won't run that program. Neither example tells you which group a given setting on your own keyboard belongs to. You need setting-level evidence for that.
Which Settings Are Actually Verified to Persist?
For your exact keyboard, only setting-specific documentation or your own test can answer this. Lighting, macros, and magnetic actuation can be handled differently on the same board, so judge each one separately.
Lighting
QMK's documented case happens to be a lighting example: a value read from EEPROM at startup sets an RGB color. That shows lighting can be applied by firmware in QMK's documented configuration, and only there. It says nothing about whether another keyboard's lighting mode, color, or brightness carries over to a new computer.
The same goes for our own boards. We list onboard memory and a web driver for our X60 HE magnetic keyboard. Those two specs tell you the board has storage and a driver. They don't sort lighting, macros, or actuation into "saved on the keyboard" and "needs the driver." So treat all three as settings to test on your own unit.
Macros
A macro that depends on a host program stops working when that program isn't running, just like Lenovo's software-dependent keys. An onboard memory label doesn't tell you whether your macros are stored on the keyboard or played back by software. On the X60 HE, consider macros unverified for driver-free use until they pass your own test. If you also run work macros on the same keyboard, keeping gaming macros in a separate profile makes the tournament check cleaner, because you only test the profile you'll actually use.
Magnetic Actuation
Adjustable actuation depth is a setting you'll feel on every keypress, so it's tempting to assume it sticks. A spec sheet that lists adjustable actuation or onboard memory doesn't show whether the depth you picked stays active on a computer with no driver. A missing mention doesn't mean it fails either. It just means the answer is still open. When you compare boards in our magnetic switch keyboard range or anywhere else, look for documentation that names actuation as a setting saved to the keyboard. Then confirm it yourself.
Choose Based on What the Tournament Computer Allows
Base your choice on what the event computer will actually run, then match each setting to that answer. Neither method is better everywhere.
- Required software is permitted and runs: A software-managed profile is a workable option. Confirm with the organizer that you may install or launch the program, or open the web-based tool, on the event machine. Then make sure it can stay running for as long as your settings depend on it.
- Required software is blocked or unavailable: Count only on the settings that passed a test with that software unavailable. A setting you haven't tested, or one you only know about from a feature label, isn't a confirmed onboard fallback.
Rules come from each event, not from a single tournament-wide standard. Ask the specific organizer instead of carrying over another event's policy. If the event PC runs a different operating system than yours, check Mac and Windows software support too, since that can decide whether a driver is even an option. A setup that mixes both routes works well: rely on onboard keyboard profile storage for the settings that passed, and keep software-only extras for events that allow them.
Run a Pre-Event Test on the Exact Keyboard
A short test at home shows which settings will hold up before you sit down at an event PC. Run it on the exact keyboard you plan to bring.
- Confirm the event's rules. Ask whether you may install or run the keyboard's configuration software or web tool, and whether there are limits on macros.
- Save the profile the documented way. Follow your keyboard's manual or official guide to write the profile to the keyboard. If you need a firmware update first, do it before saving, and work through our keyboard firmware checks so you know your recovery options.
- Recreate the restriction. Close the software or browser tab. Then connect to a second computer that has never had the driver, using the same connection mode (wired, 2.4GHz, or Bluetooth) you'll use at the event.
- Check each setting separately. Lighting: does your saved mode appear? Macros: does the key type the full sequence in a plain text editor? Actuation: does a key register at the depth you set, such as a light press triggering when you set a shallow point?
- Record pass or fail for each setting. A pass makes that setting an onboard fallback. A fail, or a setting you couldn't test, should go through the software route only if the event allows it. Otherwise, plan your setup without it.
A pass only covers that keyboard, those settings, and that setup. If you change firmware, profiles, or connection mode, run the test again.
FAQs
Does "onboard memory" mean every setting is saved?
No. An onboard memory label tells you the keyboard has some keyboard profile storage. It doesn't tell you which settings are stored there or whether they work without the configuration software. Lighting, macros, and actuation can each behave differently, so go by documentation that names the specific setting, plus your own test with the software closed.
Does the QMK RGB example confirm what the X60 HE stores?
No. QMK's EEPROM documentation describes how QMK firmware stores a setting and applies it to RGB lighting at startup. That behavior belongs to QMK's documented configuration. For our X60 HE, or any other keyboard, you need model-specific confirmation for each setting before relying on it without the driver.
Can I assume another tournament allows the same software?
No. Software rules come from each event, so a program allowed at one tournament may be blocked at the next. Ask each organizer two things: whether you may install or run the tool, and whether the event computer can actually run it during play.
