basecamp
Add thunderbolt / USB-C display + dock compatibility
This hopefully makes the extra USB-C to display port cable unnecessary.
- Thunderbolt & USB-C on Boot: Displays are fully usable on boot & USB devices plugged in the display like your keyboard work to unlock your drive. For this, i adjusted initramfs Modules & hooks.
- Thunderbolt Hot Plugging: Similar to Macs, thunderbolt devices are now auto authorized. You can now plugin your display or dock any time (Laptop). Achieved by udev rule
- Fix for ghost displays in hyprland: Hyprland got confused by the second MST stream of Thunderbolt displays. A watcher will find the second stream and hide it for hyprland.
In my use case (BER8 + Thunderbolt display with connected KM) direct connection as well as a TB switch now work flawlessly on boot and in userspace.
Possible Improvements:
- Add i915 to initramfs modules on intel systems. May or may be not necessary.
- A migration to add initramfs config for already existing installations may be too risky if not tested widely, so this may be optional (migrations/1755631163.sh)
- Check if screen is unlocked / user present for auto authorization on hot plugging (extra security bc. TB has DMA)
- Ghost display fix only runs once on login. While persistent across reconnects, its not effective if the display is not connected on initial login (Laptops). We may need to include the ghost display fix script in the udev hot plugging rule, but this runs in a different user context without access to the hyprland session. If someone has a clever idea to this, it would be appreciated. The best i have is to expand the udev rule, get all hyprland session and run the ghost fix on each / broadcast.
https://gist.github.com/chriopter/82871f6b9f1cabb63655e540bab28e2b
It seems very specific to some installations, maybe the setup should be moved on demand in the setup menu (like the fingerprint scanner).
Debatable yes, i think as Beelink, modern Displays and AMD GPU are not only official hardware recommendation but also probably one of the most common setups its worth considering to pull it in the standard. Up to the maintainer imho
I regularly use my FW 13 in clamshell mode hooked up to a Caldigit TS4 dock and external display, and have quite a few issues... for example, needing to slightly open the lid after suspending in order to get things going again, and issues with things like GDK_SCALE needing to change depending on which display is in use.
I'm relatively new to Arch/Omarchy, but I'm happy to help test this and provide anything I can here, especially since 95% of my computer use is clamshell mode 😀
Oh great! Can you currently use keyboard and display connected to the dock on boot to unlock the drive?
@chriopter nope, I need to boot unplugged. Also, not sure if this is more of a Framework thing, but only one of the USB-C ports - the right one (both on the two rear ports) can do display + keyboard + eth + audio. The other just does display.
@brennandunn Can you apply the both migration patches of the PR to your machine and try if you can boot plugged in with the port that works?
I think it's expected that not all ports have the same feature set but unsure if this matches your systems behaviour.
I have FW13 AMD 7040 laptop with Caldigit TS4. These are my experiences.
I have my extension cards setup like the picture before so the top right and left are USB-C ones, these support USB4 and my caldigit is connected to either of these, depending on the situation.
Because of the AMD platform, the boot screen/bios is not available to external screen through the caldigit. But my external keyboard (also connected to the TS4) works in the LUKS prompt.
I need to install the bolt package to be able to use the dock on the system. This package brings basic TB stuff and allows authorisation etc to be done.
Thanks, i have an FW13 under way as well to test.
Bolt would work to replace our udev authorization in userspace, but unfortunately we would still need the initramfs hooks I think.
Could you apply the patch without udev scripts to test if you can get a picture at LUKS?
Very keen to see this fixed by default. But we need to be careful about just giving free access to all potential TB devices, I think. Wonder if there's a way to scope this down somewhat.
Also needs some serious testing to make sure we don't screw over other things. But love to see this move forward!
@brennandunn Can you apply the both migration patches of the PR to your machine and try if you can boot plugged in with the port that works?
I think it's expected that not all ports have the same feature set but unsure if this matches your systems behaviour.
yeah port 3 works fine with the dock, port 1 only works with the display. It's strange... based on what I've read, the two rear ports (1 and 3) should function identically. Not a big deal, though.
@dhh
Pre-boot Thunderbolt limiting is tricky i think since docks expose very different functions etc. Maybe a pragmatic model is: Encourage users to enable IOMMU/Kernel DMA protection in BIOS, treat entering the LUKS passphrase as implicit trust in whatever was already attached on boot, and then let bolt whitelist those devices post-boot. Future hot-plugs in userspace would need explicit enrollment, persisted in bolt / BootACL, rather than being auto-authorized. I think very comparable to Ubuntu or MacOS
That sounds like a good plan. What do you think @kevinmcconnell?
I think that sounds good too 👍 Trusting the devices connected at boot time seems reasonable, and it solves the chicken & egg problem of being able to boot up to a working display that hasn't yet been enrolled. After that point, we can require explicit authorization/enrolment with bolt.
I'm happy to help test this too, btw, as I have a 3 different machines (all AMD) that should be able to work with my Studio Display over USB-C given these changes.
@chriopter I have a framework 13 with hx370, with an old elgato dock.
Screen works from scratch but I had to allow the dock with bolt for the keyboard and mouse attached to it to work.
When I suspend, keyboard and mouse never work, I have to use the laptop/s keyboard to wake up and enter my password (screen is ok). Once I'm logged, I unplug / replug and everything works as expected.
I ran you script without the udev rule as you said earlier, but it gives me no change.
@bastnic Thanks! The sleep behaviour might be dock related, at least i cant reproduce it via FW13 and Studio Display. Can you test this with another OS / machine and similiar sleep state?
Will get an update to the PR ready in the next minutes.
Updated PR:
- Added bolt which auto-authorizes TB devices in userspace (check with boltctl) on systems with IOMMU enabled, falls back to userprompt on older systems (standard behavior of bolt) - i would stick with that @kevinmcconnell @dhh
- Disable ghost display now also on hot-plug (hyprctl monitors)
In my testing, on a FW 13 the full chain works without manual action; boot and userspace full KBM via Studio Display.
When booting the FW13 with the lid opened, the plymouth omarchy theme fails to display correctly centered while other themes work fine. It might be related to the included script of the theme. I tinkered a little bit but failed to grab the issue, maybe @dhh can take a look?
For the sake of easier debugging & testing, i removed the migration scripts for now and laid the scripts flat in subfolders. They still can be run to apply it live inside the repo for those who want to test:
export OMARCHY_PATH=./ && bash install/config/thunderbolt.sh && bash install/config/fix-ghost-display.sh
Excellent work, @chriopter! We'll get this checked out. We have a bunch of Framework 13 users at 37signals who use it with an external display 😄
Just tried it, and it didn't seem to work. This is on a F13 with an Apple XDR 6K. The only monitor it's detecting is the dummy:
Just tried it, and it didn't seem to work. This is on a F13 with an Apple XDR 6K. The only monitor it's detecting is the dummy:
Can you re-enable the monitors disabled by the ghost fix and post hyprctl monitors? The script currently disables the monitors with less modes assuming its the ghost one. It works flawlessly for me, but i also have a Studio Display not the XDR
This might be related to this PR: https://github.com/basecamp/omarchy/pull/1405
@quinchou77 and I tried Omarchy on Framework 13 AMD Ryzen AI 300.
We only needed to install bolt, then we can connect a screen through a thunderbolt GPU dock.
bolt.service authrorizes the device automatically.
I tested this on a Beelink Ser8 with a Studio Display - I still have to log in blindly (type the password without seeing the prompt, etc) before logging in and don't see anything after selecting Linux from the original boot option until Wayland starts. Moreover, while I do get the display working, it's not properly removing the old displays - I can tell because of the spaces behavior. Running hyprctl monitors showed both still.
I did the standard disable trick and it worked - and then I ran into another issue which is when I unplugged and re-plugged the thunderbolt cable from the back of the Beelink after some time, I saw nothing. I ssh-ed in and switched back monitors file to auto and then I got my screen back. oddly enough, at that point,hyprctl monitors showed 2 entires again, but this time, both were "valid," (no 0x0 entries) despite having only one monitor.
