AprilNEA / AprilNEA/OpenLogi

[Feature]: keyboard layout switch/force

Open
#967 1 comment 2 reactions 0 assignees View on GitHub
needs: triage type: feature
Dominant language
Rust
Stars
21k
Forks
675
Avg merge
2d 5h
Merged PRs (30d)
172

Description

### Pre-flight checklist

- [x] I searched existing issues and the [Roadmap](https://github.com/AprilNEA/OpenLogi#roadmap), and this isn't already tracked.

### Problem / motivation

Currently, OpenLogi does not provide a software toggle or configuration option to switch or force the keyboard layout between Windows and macOS.

While Logitech keyboards have built-in hardware shortcuts (such as holding `Fn + O` or `Fn + P`), this automatic OS-detection or manual hardware switching can often be unreliable, reset after a reboot, or get stuck when switching the keyboard between multiple devices via Easy-Switch (e.g., jumping between a Windows PC and a Mac).

In the official Logi Options+ software, users can lock the layout or force a specific OS mapping. Since OpenLogi aims to be a lightweight, open-source alternative, missing this layout-switching feature makes it difficult to fully transition away from the official software when using Logitech keyboards in mixed-OS environments.

### Proposed solution

I propose adding a configuration option (and eventually a GUI toggle) to explicitly set or force the keyboard layout mode (Windows or macOS) for supported Logitech keyboards.

Ideally, this could be implemented in two ways:
1. **Configuration File (`config.toml`):** Introduce a setting under the keyboard profile, for example:
```toml
[keyboard]
os_layout = "mac" # Options: "auto", "windows", "mac"
```
2. **GUI Toggle:** A simple dropdown or switch in the OpenLogi interface allowing users to manually force the layout for the active device.

This feature would send the appropriate feature command to the keyboard to override or lock its OS-detection state, matching the functionality found in the official Logi Options+ software.

### Alternatives considered

1. **Using Hardware Shortcuts (`Fn + O` / `Fn + P`):**
While this built-in keyboard shortcut works temporarily, it frequently resets after the computer reboots, when the keyboard wakes up from sleep mode, or after switching devices via Easy-Switch. It requires constant manual input from the user.

2. **Remapping Modifiers via OS Settings:**
Swapping the `Option` and `Command` keys directly inside macOS Settings (or using PowerToys/SharpKeys on Windows) fixes the layout, but it creates a messy workaround. If the keyboard suddenly decides to correct its own layout hardware-wise, the OS-level remap ends up breaking the layout again by reversing the keys a second time.

3. **Keeping Logi Options+ Installed:**
Using the official software just for this single feature defeats the whole purpose of switching to a lightweight, privacy-focused, open-source alternative like OpenLogi.

### Related area(s)

- [x] GUI
- [ ] CLI
- [ ] Button actions / remapping
- [ ] DPI
- [ ] SmartShift
- [ ] Per-application profiles
- [x] Configuration (TOML)
- [ ] Auto-update
- [x] Other

### Additional context

This feature is especially important for users with a dual-boot setup or those who use a KVM switch/Easy-Switch to jump between a Windows PC (e.g., for gaming or work) and a Mac (e.g., for productivity).

Without software enforcement from OpenLogi, the keyboard often gets confused about which OS it is currently connected to, leading to a frustrating experience where the modifier keys (`Ctrl`/`Cmd`/`Alt`) are constantly inverted.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by locating the keyboard profile configuration, TOML parsing, GUI device settings, and HID++ feature-command handling in the Rust codebase. Determine which supported Logitech keyboards expose the OS-layout command and how existing settings are applied. Done means users can choose auto, Windows, or macOS layout behavior through configuration, with the proposed GUI toggle and coverage for the supported devices.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
desktop
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.