Max brightness (5500 nits) and presentation mode enabled
Display set to 2560x1600 at 165Hz (max resolution and refresh rate)
Only qube running other than sys-usb, sys-net, and sys-firewall
All CPU cores allocated to the test VM and running between 30%-50%
12GB of RAM allocated to the test VM
Total battery lifespan: 2h8m
Personally, I would judge that to be good for Qubes and even more so for a workstation.
From anecdotal experience, I spent around 2-3 hours just in terminal sessions configuring stuff while not plugged in and battery was around 55%.
Miscellaneous
Keyboard backlight controls are not exposed directly to the system, you cycle through the backlight levels by clicking Fn+Space (and Enter with numlock off on the numpad)
There appear to be community kernel modules which expose the keyboard backlight controls directly to the system but use at your own risk (personally hotkeys on the keyboard are sufficient and minimal greater control over it isn’t worth the risk)
A consequence of this is that keyboard backlight isn’t turned off on suspend
Keyboard and numpad are detected as USB device
I have yet to audibly hear the fans, let alone have them spin up!
RAM and storage were bought separately but have not had any issues
Kingston Fury KF556S40IB-32 DDR5 5600 (1x32GB)
Samsung SSD 990 Pro MZ-V9P1T0B/AM
Adding and removing expansion cards work absolutely flawlessly, truly plug and play and you don’t need to reboot or do anything!
Attachments
The HCL report Qubes-HCL-Framework-Laptop_16__AMD_Ryzen_7040_Series_-20240309-181958.yml is pasted above.
Thank you and I definitely will add a conclusion after having used it for a couple.
So far though, I would absolutely recommend it for Qubes as you are able to enjoy all of the benefits of the Framework with its modularity and expansion cards systems just like you would using any other distro, without any down sides whatsoever.
Only downside is the lack of keyboard on suspend but I’m trying to find a fix.
With my previous laptop, I would need to reboot any time I plugged something as simple as a usb to ethernet adapter to get the adapter recognised by Qubes. I was fully expecting with the Framework to have to reboot every time I switched input modules, but no not at all. Any new ones get detected automatically and I can start using them straightaway, even for things like the display output where I removed the DP expansion card and then plugged the HDMI one in and it detected it and extended the display to the output I connected, didn’t need to reboot or anything.
Also it is incredibly quiet, coming from a laptop which would spin up and sound like a jet engine on boot or under heavy load, at their peak so far the fans are barely discernible when there are no background sounds (FYI I do not have the dGPU module).
Additionally, I am running a test of the battery and it is over 2h and still going. For Qubes and given that this test is having the laptop at full brightness and running at around 30-50% CPU, I think that is quite good.
EDIT: Battery test is finished and added to the main post
I’ll update as soon as I find a fix for the keyboard working on suspend wake.
Regarding the handling of the USB modules, all of the expansion cards are treated as USB devices and are handled by sys-usb. This is evident during use as for example wanting to use the ethernet expansion card, requires adding it to sys-net (i.e. your desired network vm).
Running lsusb in dom0 will return nothing.
The one exception to this are the expansion cards for the display ports (HDMI, and display port) as when plugged in I will get a notification from sys-usb that say the HDMI card is active however, the display output is automatically handled by dom0 without needing to add the device or anything. Even then, running lsusb or even lspci in dom0 yields no different results than when the display output is not connected.
The expansion cards are certainly an added attack surface in my opinion and could be an added way to attempt to gain compromise to the device.
Within the BIOS, you can disable USB boot and password lock it which will prevent any low effort AEM attacks using a USB stick but will not protect against more sophisticated attacks.
I added it to the very end of the GRUB_CMDLINE_XEN_DEFAULT line of my /etc/default/grub file.
Make sure you then run sudo grub2-mkconfig -o /boot/efi/EFI/qubes/grub.cfg followed by sudo dracut -f to ensure your grub actually gets updated.
I usually get a black screen on boot until reaching the disk encryption prompt but not afterwards.
Do keep in mind I have a Framework 16, if you have a Framework 13 there are multiple forum threads here for each of the Framework 13 versions and chipsets which may be of additional help.
Okay im not making it that far because the xen commamd line keeps saying “USB in dom0 is not resticted consider rd.qubes.hide_all_usb or usbcore.authorized_default-6.” But im not sure where to put the in the xen commandline. Ill keep looking around. Thanks. I also have a ryzen 7040u
Can you not even get into Qubes and dom0?
Please reply in either one of these threads, whichever one is for your laptop. This thread is for the Framework 16 and I would like to not have this thread get too off topic.
So far I’ve been able to pin the keyboard not working on suspend wake issue to be due to sys-usb not being restarted/unpaused on suspend wake and since the keyboard is registered as a USB device, you can’t use it to unlock the laptop.
I’ve been trying to play around with the Qubes suspend hooks but so far haven’t gotten anywhere.
Due to it being a sys-usb issue though, even using an external keyboard would not work (I also tried before identifying the root cause and to no avail).
A temporary but very insecure workaround would be to disable lock on suspend so when waking up, you aren’t locked out and you can then proceed to manually restart sys-usb.
As for the workaround, do you use touchpad to manually restart sys-usb? If so, would it be possible to use the virtual keyboard to enter the password and avoid disabling lock?
Yep exactly, I use the touchpad since as it is connected over i2c and not usb, it still works, and yes that would absolutely work! Good idea, hadn’t thought of that
Another idea is to re-create the sys-usb qube, but leave the USB controller responsible for the internal keyboard in dom0. The process described in this section of the docs.
Unfortunately, the USB controller that is responsible for the keyboard also handles anything connected via the expansion cards so that would significantly compromise the security and isolation of the laptop. This is because any USB device connected would be exposed directly to dom0.
The actual issue at play is sys-usb not getting restarted on suspend wake and that’s what needs to be resolved.
Haven’t had the chance to do more debugging and try and fix it since my prior comment, I’ve been quite busy and haven’t had the time to.
Does that mean there is only 1 usb controller for the whole device? Like in the Qube Manager for sys-usb it only shows one device selected? That would be a huge dealbreaker for me
No there are 6 USB controllers.
There are 6 devices passed on to sys-usb and you can also see that when running lsusb in sys-usb with no external devices connected:
[user@sys-usb ~]$ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd QEMU Tablet
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 05e3:0610 Genesys Logic, Inc. Hub
Bus 002 Device 003: ID 05e3:0610 Genesys Logic, Inc. Hub
Bus 002 Device 004: ID 05e3:0610 Genesys Logic, Inc. Hub
Bus 002 Device 005: ID 0e8d:e616 MediaTek Inc. Wireless_Device
Bus 002 Device 006: ID 27c6:609c Shenzhen Goodix Technology Co.,Ltd. Goodix USB2.0 MISC
Bus 002 Device 007: ID 32ac:0012 Framework Laptop 16 Keyboard Module - ANSI
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 002: ID 05e3:0625 Genesys Logic, Inc. USB3.2 Hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 006 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 002: ID 32ac:0002 Framework HDMI Expansion Card
Bus 007 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 008 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 009 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub