Omarchy hardware and connectivity: Wi-Fi, displays, audio and input
Set up essential devices, distinguish configuration from failure, and choose a diagnostic route for your exact symptom.
Based on public documentation; not hardware-tested. Match the instructions to your version and hardware.
Hardware setup is successful when your real task works: a website opens, both screens remain usable, the meeting app receives the correct microphone, and text reaches the application you are typing in. An icon or an installed package is only one part of that result.
This chapter connects normal setup with the corresponding troubleshooting articles. Begin with what you observe, then follow the responsible layer. Avoid treating every failure as a missing driver or making several unrelated changes before repeating the task.
Setup or troubleshooting?
Section titled “Setup or troubleshooting?”| What you see | First route | What the guide helps distinguish |
|---|---|---|
| A network appears and you need to join it | Connect to Wi-Fi | Selecting the connection and confirming internet access |
| No networks, authentication failure, or connected without internet | Wi-Fi troubleshooting | Device, connection, address, route and name resolution |
| A display works but text or arrangement is uncomfortable | Displays and scaling | Physical pixels, logical size, scale and position |
| A screen is missing, black or using the wrong mode | Display troubleshooting | Detection, configuration and the affected connection |
| Sound or a Bluetooth headset fails | Audio and Bluetooth | Pairing, profile, output, application and microphone |
| You need Chinese input | Chinese input setup | Framework, engine, activation and a real typing test |
| Input works in one app but not another | Input troubleshooting | Application and session integration |
| Suspend or wake behaves unexpectedly | Sleep troubleshooting | The trigger, resume and what stopped working afterward |
The setup guide owns the normal workflow; the troubleshooting guide owns a failed outcome. Read the appropriate route rather than repeating installation whenever an application behaves differently.
How the layers cooperate
Section titled “How the layers cooperate”A useful model is device → service → desktop control → application task. Some operations involve additional layers, but this gives you a starting point for deciding where evidence belongs.
- Network: NetworkManager manages connections; the desktop panel or terminal interface is a control surface. Seeing “connected” still needs an internet-access test. Official networking documentation
- Audio: BlueZ handles Bluetooth, PipeWire processes audio and WirePlumber manages routing policy. A paired headset is not proof that an application selected its microphone. See the media layer.
- Displays: Hyprland handles monitor configuration and window placement. An application’s own rendering can behave differently from the overall desktop. See the desktop layer.
- Input: Fcitx 5 and its engines work with session and application integration. Engine installation, engine selection and text arriving in a field are separate milestones. See the input layer.
This is a learning model, not a dependency diagram. The complete catalogued component lists remain in the system composition pages.
A first-day device check
Section titled “A first-day device check”Use a few familiar tasks and record the result before customizing. The following is a practical acceptance checklist, not a claim that every device is supported.
| Test | Evidence worth keeping | Why it matters |
|---|---|---|
| Open a website on the intended connection | Connection type and whether ordinary browsing works | Separates joining a network from reaching a service |
| Read the same document on each display | Resolution, scale, connection and which app looks wrong | Separates screen geometry from application rendering |
| Play audio and make a short microphone test | Selected output/input and application | Separates speaker output from recording |
| Type in a browser and your editor | Input method and the application where it succeeds or fails | Finds integration differences |
| Save work, suspend and wake once | Trigger used and which function changed afterward | Makes a later regression easier to describe |
Do suspend checks with saved work and a recovery option available. Monitor reconnection, dock use and laptop lid behavior are separate scenarios: succeeding at one does not prove the others.
Follow a scenario, not a bag of tweaks
Section titled “Follow a scenario, not a bag of tweaks”New laptop: connect using the Wi-Fi guide, adjust display scaling, check audio and input, then test suspend. Finish the baseline before adding custom startup services.
Meeting on a dock: verify the display connection, choose the audio devices in the meeting application, and check whether screen sharing works in that application. To keep notes and the call arranged predictably, continue with multi-monitor workspaces. Portal responsibilities are explained in the media layer; this site does not yet provide a dedicated application-by-application screen-sharing guide.
A fault after an update: record the last working state, update result and whether the fault affects one app or the whole session. Use the matching symptom article first, then update recovery if the evidence points to the change.
What to bring to a support request
Section titled “What to bring to a support request”Write the expected result and actual result in separate sentences. Include the Omarchy version, relevant hardware, connection type, failing application, exact error and recent changes. A report such as “external screen connected through this dock disappears after resume; the internal panel still works” is far more useful than “graphics broken.”
Share only relevant logs and remove passwords, network secrets and personal identifiers. Follow getting help for a reusable reporting format. Unsupported hardware and unresolved problems remain unresolved even if a restart temporarily clears the symptom; keep that distinction in your notes.