Framework Laptop

User Support HCL Reports
21

This issue tracks Qubes support of Tiger Lake processor, including suspend.
Support is not yet complete

22

Back to the USB cycling.
Today, I had another round of problems with the camera dropping out of my chosen Qube
Also, I have trouble attaching my Android to a Qube
The microphone, however, stays attached.

23

I’ve successfully installed Qubes on my Framework, and have gotten almost everything working great. I’ve included a link to notes I made while installing

I haven’t tested anything to do with suspend, so no notes there. Shutting down and starting is fast enough for me anyway.

Jot notes from my install:

3 Likes
24

You both are awesome and I am looking forward to getting this all working for everyone. So far everything is going fairly well EXCEPT the AX210 card… I don’t understand it. I got it working for quite some time the same way that EncrytpedGiraffe did, but a recent intel linux firmware update seems to have broken it. Any other ideas? And also, WHY does the AX210 card work in every other linux distribution I have tested, but not Qubes. I suppose the clear antagonist must be the Xen virtualization somehow? I know I could buy an old card somewhere, but I feel that I must figure this out, as there will be many more Intel Wifi6 cards going forward in Qubes for the community no doubt.

25

Have you added the kernel-latest and kernel-latest-qubes-vm to dom0, and set your sys-net to use that kernel? That was the only way I could get my WiFi6 device recognized (not Framework) on my laptop.

26

pr0xy, Thanks for the suggestion. Yes I have done that, I hope, correctly. without kernel-latest, there were a few hardware issues, but those are resolved now running kernel 5.18.14 on sys-usb and sys-net. I personally would have expected your suggestion to fix the issue, as that does on other linux distributions (for example, LMDE 5). But alas, it still has trouble loading the driver. I do have the demsg screenshots of the driver failure. I will post them here, but if this is not the appropriate place for that (since this is the HCL Report page), please just let me know moderators and I will remove it.

wifi_issue2
wifi_issue21920×2560 549 KB

wifi_issues1
wifi_issues11920×2560 605 KB

As you can see, it attempts to load the wrong driver. It SHOULD be loading number 58 according to the Intel page. However, I have tried this process extensively with both the Debian VM as the base and the Fedora VM as rthe base, and both have issues. Debian actually tried to load the correct driver, but fails due to pvnm not loading. This demsg is from the Fedora 36 VM version of sys-net.

27

The next thing I was going to suggest was to make sure you had Fedora for sys-net…but you have that covered. The kernel change in combination with Fedora 36 was all I needed to get the WiFi6 adapter recognized and operational (again not a Framework device).

Have you tried booting from a live image of Fedora 36 to see if the device is properly detected and operational there?

1 Like
28

That’s a really good idea. I just tried that with a fedora 36 live-USB and my wifi card was immediately detected and working on boot. However, I did notice that, yet again, the dmesg revealed that the card was technically running under the wrong ucode “drivers”(according to Intel’s Linux page, this card should use the .59 ucode…I incorrectly stated “58” in my previous post). It seems to try from the largest numbered ucode and then try them all until it finds one that sorta works well enough not to reject it outright. I am attaching the dmesg from Fedora 36 live USB here.

fedora26liveUSB_dmesg
fedora26liveUSB_dmesg1920×1440 254 KB

It seems that the universal constant causing the failure is when the pnvm doesn’t load…I am not sure why it doesn’t as the file is indeed there and it does actually load it. then just times out and fails to load anything after that. It should be noted, that I did also try renaming all the ucode files other than ucode .59, and it did the same thing where pnvm fails to load and causes it to simply not work. I am noticing that the hexadecimal identifier for pnvm version is different in Fedora 36 LiveUSB where it succeeds and the Qubes Fedora 36 VM where it fails… Perhaps it is actually trying to load the wrong pnvm somehow?

Other possible factors that I am not qualified enough to dig into: maybe there is some kernel issue specific to Qubes kernels or something with the Xen abstraction that interferes with the card.

29

After some investigation, this seems to be related to some interaction between pciback (the pcie passthrough driver of the AX210 Wifi 6E card in dom0) + iwlwifi firmware loading code.

1 Like
30

Thank you for putting time into investigating. That makes a lot of sense since the firmware and card seem OK in a multitude of other distributions I have Live-booted. I have no idea at all how to work to rectify that passthrough issue… do you know anyone who does? The card has worked in Qubes in the past with strange workarounds in older kernels (which it no longer does), so I feel it must be technically possible somehow, but I don’t know the first thing about Xen. :frowning:

31

I just installed 4.1.1 on the i5 model, and everything I have tried now works OK after some troubleshooting. Some comments to help others:

  • AX210 WiFi. Initially this didn’t work, but updating dom0 brought a new kernel (5.15.64-1.fc32) and then it just worked. I checked the box ‘Enable updates for qubes without known available updates’ in Qubes Update to force the dom0 update.

  • Suspend. Initially laptop wouldn’t wake up from suspend, the power button light would just pulse until I did a hard shutdown. echo deep | sudo tee /sys/power/mem_sleep made suspend work OK, I added a crontab line for after each reboot. Suspend isn’t perfect, using perhaps 15% of battery overnight, but it is enough to be useful.

  • Trackpad. It took me a while to realize that clicks in the bottom right corner of the trackpad register as right clicks.

The webcam worked fine, and I have not tried bluetooth or the fingerprint reader.

2 Likes
32

For anyone who jumps into the Framework Laptop 11th gen at this point (such as the HCL report is for this post), at this point the laptop works very well and new kernels have resolved all the major issues. I have posted a guide for Framework laptop users, for all generations, here on github Setting up and tweaking Qubes OS 4.1 and 4.2 on Framework Laptop ¡ GitHub.

I will also be building one out in the forums: Framework Laptop Set up and tweaking Guide [Orca Project 2]

2 Likes
33

Fabulous machines and great forum. If you can look more into BIOS like Linux Boot it would make perfection. Former Machine Head… with lots of brain damage talking.

34

A post was split to a new topic: Framework Laptop (HCL)

35

@moonlitOrca I moved your HCL report to its own topic so that it’s in the HCL category.

That makes processing easier, and makes it easier to find afterwards. And the move leaves a link here for people following the thread, so it’s a win-win situation :slightly_smiling_face:

1 Like
36

Was this topic already in the HCL category? Looks like I missed that :woman_facepalming: I’ll bring your HCL back @moonlitOrca, and let @flavio know that it’s here.

37

Submitting my HCL report here, since I never did!

layout:
‘hcl’
type:
‘Notebook’
hvm:
‘yes’
iommu:
‘yes’
slat:
‘yes’
tpm:
‘2.0’
remap:
‘yes’
brand: |
Framework
model: |
Laptop
bios: |
03.17
cpu: |
11th Gen Intel(R) Core™ i7-1165G7 @ 2.80GHz
cpu-short: |
FIXME
chipset: |
Intel Corporation 11th Gen Core Processor Host Bridge/DRAM Registers [8086:9a14] (rev 01)
chipset-short: |
FIXME
gpu: |
Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] [8086:9a49] (rev 01) (prog-if 00 [VGA controller])
gpu-short: |
FIXME
network: |
Intel Corporation Wi-Fi 6 AX210/AX211/AX411 160MHz [8086:2725] (rev 1a)
memory: |
32551
scsi: |

usb: |
4
certified:
‘no’
versions:

  • works:
    ‘FIXME:yes|no|partial’
    qubes: |
    R4.2.0-rc4
    xen: |
    4.17.2
    kernel: |
    6.1.56-1
    remark: |
    FIXME
    credit: |
    FIXAUTHOR
    link: |
    FIXLINK

Everything works as follows on Qubes 4.2:
Keyboard
Trackpad
Microphone
Microphone kill-switch (still appears in dom0 but doesnt work)
Webcam kill-switch (removes device from sys-usb completely)
Webcam indicator-light
Power-light indicator
USB-A expansion ports (data)
USB-C expansion ports (power and data)
WiFi (Intel AX210)
3.55mm (Output)
Power button
Power button light
S3 Sleep (after adding kernel argument)
Bluetooth
Right click (after changing option in XFCE)

Untested
Fingerprint Reader

1 Like
38

There was a similar report for the same laptop but wake up from sleep wasn’t working for that one (I guess they didn’t have the necessary kernel argument). I’ll add this one too.

I just submitted a pull request to the HCL repository. Thanks for sending this HCL report!

2 Likes
39

@flavio please feel free to also include my HCL report: Framework Laptop 13th Gen, Intel - #17 by leee

I’m not sure what’s important to note in the remarks. Feel free to include any of the following, but they’re mostly optimizations/QoL improvements to get to a “flawlessly” working system. So perhaps unnecessary.

  • brightness hotkeys don’t work out of the box due to conflicting modules preempting each other. Framework recommends blacklisting/unloading hid-sensor-hub.
  • USB ethernet adapters not working, haven’t investigated more.
  • “s2idle” or “freeze” (S0 suspend to idle) is the default suspend mode even though ACPI PM identifies S3 as available. Maybe ACPI table info issue? Anyways usual frobbing of mem_sleep_default does the trick to get “deep” (S3 suspend to RAM) sleep. Also adding nvme.noacpi=1 may help but I haven’t quantified any testing. For what it’s worth, I don’t think any of the SSDs Framework sells have known bad ACPI implementations.

Something notable (at least to me) is the keyboard is exposed to the host as PS/2. The mouse is also exposed as {PS/2 mouse, i2c mouse, i2c touchpad}.

One suggestion - a lot of issues can be CPU arch and generation specific. The only common framework about Frameworks (haha) are the physical dimensions. The underlying mobos are unique. That also includes different 13" and 16" mobo SKUs, since the latter not only has different dims but also needs to support PCIe expansion modules (like GPUs).

My suggestion is to follow Framework’s own mainboard listings https://frame.work/marketplace/mainboards and expand on model name like so:

  • Laptop 13 (AMD 7040 Series)
  • Laptop 13 (Intel 11th Gen)
  • Laptop 13 (Intel 12th Gen)
  • Laptop 13 (Intel 13th Gen)
  • Laptop 16 (AMD 7040 Series)

So the model of @moonlitOrca’s report should be Laptop 13 (Intel 11th Gen). Mine should be Laptop 13 (Intel 13th Gen).

For this reason I also would suggest having separate forum posts.

1 Like
40

@leee, I just submitted another pull request with your report. Based on what you said, it does work save for minor issues with brightness control and ethernet port, which I noted in the remarks.

Best,

Flavio

2 Likes