Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
Problems with Display Port over USB4 (BeeLink SER9)
Reported by marcinczenko · filed Jul 27, 2025Closed upstream on 2025-07-28 by dhh. GitHub close reason: completed. No closing PR or commit is recorded — "completed" alone is not evidence of a fix.
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- Not yet mapped to any requirement or component.
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.
Original report
BeeLink SER9 uses Display Port Alternate Mode over its only USB4 port at the back. Beelink also has regular HDMI and DisplayPort outputs.
In my setup I am using Dell U4025QW with native resolution 5120x2160 and max refresh rate 120Hz. The screen has native HDMI, DisplayPort, and Thunderbolt 4 upstream port (Video + Data).
I have dual-boot configuration (windows/omarchy) with systemd-boot.
When using native DisplayPort connection, everything works good - I am getting [email protected]. Now, if I connect the display using BeeLink USB4 output and the Thunderbolt 4 screen upstream input (I mean by plugging in the USB4 <=> Thunderbolt 4 cable while being connected using native Display Port), the USB4/Thunderbolt 4 connection is correctly detected by arch linux and I am also able to reach the same resolution [email protected] - I can see that in the output of the hyprctl monitors command. If I now disconnect the native Display Port connection and switch the display to use Thunderbolt 4 input, everything works good as well. Also using Thunderbolt 4 docking station does not cause any troubles, which is impressive.
The problems comes when I now try to restart the machine. Recall, I am connected using USB4 <=> Thunderbolt 4 and everything works. Now after Beelink reboots, it shows the systemd-boot menu where I can select Archlinux (Omarchy). After selecting Archlinux, however, the video connection gets broken - the screen reports there is no signal on the Thunderbolt 4 input. To fix it, I have to use the native Display Port connection (or HDMI for that matter). Then when I reconnect using USB4 <=> Thunderbolt 4 connection, and issue the hyprctl monitors command, the "DP over USB4" is again properly detected and I can switch to the Thunderbolt input as before (at which point I also disconnect the native connection, and re-launch Hyprland). The process repeats.
I am not sure yet, where the problem is, and it may be it is not related to Omarchy, but because Beelink is now kind of recommended, it could be good to record the issue and see if it can be fixed in the future (which I would be happy to help, yet, I just started to play with Omarchy and I am new both to ArchLinux and Hyprland). My first thought was that some GPU libs are not loaded early enough - just a thought.
I will be happy to help or provide more input. Maybe someone can point me to some direction and I will try to do my own research when time allows.
View raw text
_BeeLink SER9_ uses _Display Port Alternate Mode_ over its only USB4 port at the back. Beelink also has regular HDMI and DisplayPort outputs. In my setup I am using _Dell U4025QW_ with native resolution `5120x2160` and max refresh rate `120Hz`. The screen has native HDMI, DisplayPort, and Thunderbolt 4 upstream port (Video + Data). I have dual-boot configuration (windows/omarchy) with `systemd-boot`. When using native DisplayPort connection, everything works good - I am getting `[email protected]`. Now, if I connect the display using BeeLink USB4 output and the Thunderbolt 4 screen upstream input (I mean by plugging in the `USB4 <=> Thunderbolt 4` cable while being connected using native Display Port), the `USB4/Thunderbolt 4` connection is correctly detected by arch linux and I am also able to reach the same resolution `[email protected]` - I can see that in the output of the ` hyprctl monitors` command. If I now disconnect the native Display Port connection and switch the display to use Thunderbolt 4 input, everything works good as well. Also using Thunderbolt 4 docking station does not cause any troubles, which is impressive. The problems comes when I now try to restart the machine. Recall, I am connected using `USB4 <=> Thunderbolt 4` and everything works. Now after Beelink reboots, it shows the systemd-boot menu where I can select Archlinux (Omarchy). After selecting Archlinux, however, the video connection gets broken - the screen reports there is no signal on the Thunderbolt 4 input. To fix it, I have to use the native Display Port connection (or HDMI for that matter). Then when I reconnect using `USB4 <=> Thunderbolt 4` connection, and issue the ` hyprctl monitors` command, the "DP over USB4" is again properly detected and I can switch to the Thunderbolt input as before (at which point I also disconnect the native connection, and re-launch Hyprland). The process repeats. I am not sure yet, where the problem is, and it may be it is not related to Omarchy, but because Beelink is now kind of recommended, it could be good to record the issue and see if it can be fixed in the future (which I would be happy to help, yet, I just started to play with Omarchy and I am new both to ArchLinux and Hyprland). My first thought was that some GPU libs are not loaded early enough - just a thought. I will be happy to help or provide more input. Maybe someone can point me to some direction and I will try to do my own research when time allows.
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
Not linked to any known issue, other report or change yet.
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
No decision has been recorded yet.