Arch Linux on the Framework Laptop 13

I just run powerstat -a. You can see details of how I do my idle power testing here. (basically it waits 180s and then does 300s of sampling to generated a result)

I am running linux-clear not linux-clear-bin so yes, it was a custom compile with MALDERLAKE.

Maybe I’ll play around w/ EPP and see w/ all the kernels since I’ve been pretty disappointed in general w/ how battery usage w/ YouTube playback, even in Firefox where I have full HW acceleration (it’s about 1-2W lower than Chrome, which doesn’t have working HW decode).

1 Like

I am using endeavor with XFCE here, and it has driven me up a wall.
To keep it short:
No tip has extended the four hour battery life for me. Certain programs, such as Discord, endeavor easy package install, will not redraw and will display a frozen image until the window border is changed in any way. Certain icons for window borders and menus will be tiny for zero reason. Scaling in general is broken and doesn’t cooperate with me.

Can someone please, please tell me what I’m doing wrong? I’ve tried two days worth of troubleshooting and absolutely nothing has fixed all of those issues.

1 Like

Update, found out my mic doesn’t work either. Fantastic.

1 Like

So I run Arch, not Endevour, but they are the same base. I’ve had really good luck reading the Arch Wiki to make most things work great. Lemme share a few things that might help… theres a Frame.work Arch wiki entry:
Framework Arch Wiki Entry

The newest kernel, 5.19+, sometimes creates several video-related bugs/issues. I install both Linux and Linux-LTS kernels; if the kernel is ever creating bugs, or updates and creates new ones, you can just select the Linux-LTS in GRUB and it’ll squash those. The forum is currently reporting issues on 5.19.12, so this might help you;
How to install Linux-LTS alongside Linux kernel

Remember, I’ve setup Arch from the ground up - so I don’t have experience using EndevourOS (on the frame, anyway)… I think you need to look at issues a different way. LIKE, are the video issues you mentioned because of the kernel? Etc…

One thing at a time, and many times where yer sniffing isn’t where the problem is. Sorry yer not loving Endevour on the frame. Heck; I installed Windows 11 just to see the difference. I’ve had the most luck with Fedora and Arch on the Frame, Linux side anyway. Hope you iron things out.

1 Like

Has anybody tried kernel 5.19.13 yet? If so, can you report whether it plays well with framework laptop display or not?

Thanks!

2 Likes

5.19.13 works fine. You can also see reports here of working versions at the end of this thread: PSA: don't upgrade to linux kernel 5.19.12

4 Likes

5.19.12 broke mine as described. Arch Linux LTS kernel temporarely fixed my system (could also have downgraded the kernel)
5.19.13 right now works great again. no display problems, just like before .12.

2 Likes

@CodeAsm I would really like to know how you have this setup and working. I cant for the life of me figure this out.
At the moment my screen locks up for about 10 seconds at a time and then is usable for about 10 seconds. This is where I’m currently at.
Framework 12th gen
Arch 5.19.13-arch1-1
i3-gaps for my window manager
Installed mesa, and my Xorg log contains:
[ 112.325] (II) LoadModule: “intel”
[ 112.326] (WW) Warning, couldn’t open module intel
[ 112.326] (EE) Failed to load module “intel” (module does not exist, 0)
[ 112.326] (II) LoadModule: “modesetting”
[ 112.326] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[ 112.328] (II) Module modesetting: vendor=“X.Org Foundation”
[ 112.328] compiled for 1.21.1.4, module version = 1.21.1
[ 112.328] Module class: X.Org Video Driver
[ 112.328] ABI class: X.Org Video Driver, version 25.2
[ 112.328] (II) LoadModule: “fbdev”
[ 112.328] (WW) Warning, couldn’t open module fbdev
[ 112.328] (EE) Failed to load module “fbdev” (module does not exist, 0)
[ 112.328] (II) LoadModule: “vesa”
[ 112.329] (WW) Warning, couldn’t open module vesa
[ 112.329] (EE) Failed to load module “vesa” (module does not exist, 0)
[ 112.329] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[ 112.351] (II) modeset(0): using drv /dev/dri/card0
[ 112.351] (II) modeset(0): Creating default Display subsection in Screen section

I have created the file /etc/modprobe.d/i915.conf and it contains:
options i916 enable_psr=0
options i915 enable_fbc=1
options i915 fastboot=1
options i915 enable_guc=2

I have also created /etc/modprobe.d/acpi.conf and it contains:
acpi_osi="!Windows 2020"

My dmesg shows:
[ 112.549672] i915 0000:00:02.0: [drm] Selective fetch area calculation failed in pipe A
[ 113.023362] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[ 117.110283] mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_component_ops [i915])
[ 117.113929] mei_pxp 0000:00:16.0-fbf6fcf1-96cf-4e2e-a6a6-1bab8cbe36b1: bound 0000:00:02.0 (ops i915_pxp_tee_component_ops [i915])
[ 158.671733] i915 0000:00:02.0: [drm] GPU HANG: ecode 12:0:00000000
[ 158.672100] i915 0000:00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0
[ 158.773810] i915 0000:00:02.0: [drm] GuC firmware i915/adlp_guc_70.1.1.bin version 70.1
[ 158.773824] i915 0000:00:02.0: [drm] HuC firmware i915/tgl_huc_7.9.3.bin version 7.9
[ 158.788069] i915 0000:00:02.0: [drm] HuC authenticated
[ 158.789077] i915 0000:00:02.0: [drm] GuC submission enabled
[ 158.789084] i915 0000:00:02.0: [drm] GuC SLPC enabled
[ 193.838699] i915 0000:00:02.0: [drm] GPU HANG: ecode 12:0:00000000
[ 193.838954] i915 0000:00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0
[ 193.941669] i915 0000:00:02.0: [drm] GuC firmware i915/adlp_guc_70.1.1.bin version 70.1
[ 193.941686] i915 0000:00:02.0: [drm] HuC firmware i915/tgl_huc_7.9.3.bin version 7.9

The gpu hang section keeps repeating over and over.
It seems as though the chip is being reset for a stopped heartbeat.

What is wrong in my config that would cause this?

Any help would be greatly appreciated!!

2 Likes

Hey there. I happen to have pretty much the same setup as you do.
Arch Xorg i3 wm (i3-gaps), no login manager.
12th i7 1260P Batch 2, 2 x 8 GiB and 1TB WN SN850.

Not sure if this is a typo, but shouldn’t it be i915 instead of i916 ?
If you had i916 in your .conf file, I would suggest trying again with and without PSR to check if it works.
The screen related problems I had with my 12th gen were mostly solved by disabling PSR, or upgrading to an ever more recent linux kernel (linux-clear==6.0.0.2 seems to work even with PSR enabled).

I experimented with this parameter, and I think you are better off just commenting out this line.
Just use default GuC and HuC setting for Arch.

Hope it helps.

Sorry, I didn’t have notifications on for this thread! Yes this solved that issue for me as well!

1 Like

My framework display has been fine so far with 5.19.13

1 Like

Hi All. I’m trying to get an external monitor working with my Framework on Arch. I have a CalDigit TS3 Plus Thunderbolt 3 dock which has an Apple 27" display plugged into it. When I connect the dock to my Framework, the display is recognized and renders output. However, it remains stable for about 90 seconds and then does about 30 seconds of flashing on and off in 1 second intervals. Then this whole cycle repeats again.

According to the Arch Framework docs, this dock should play nicely

I’m using KMS with Wayland (Hyprland) though I also tried Xorg with Awesome & Picom and had the same problems.

Any suggestions on where I can look to debug this? I’ve viewed the output of journalctl and dmesg while the issue is happening and nothing jumps out at me, though I may not know exactly what to look for.

1 Like

@dosssman Thanks for the pointers.

The i916 wasnt a typo, but changing it to i915 didnt solve the issue either.
I downloaded linux-clear and installed it (took nearly 2 hours with the 1260 and 64gig of ram) Now I’m stuck I installed with archinstall because the screen flickering on the laptop didnt allow for me to use the laptop and the secondary monitor chops off the bottom 1/3rd of whats happening so the archinstall script was the only way to see what I was doing during the install, and the ??systemd?? bootloader is not liking the change to “linux-clear”

I’m at square 1 again.

I’ve had this frame.work laptop for 1 week today and have been struggling like crazy to get it working with arch… Installing Gentoo on a Thinkpad T61P in 2008 was easier. Installing arch on my T14 Gen1 AMD only took a day…
I’m damn near ready to throw this thing in the garbage.

1 Like

Did you run mkinitcpio -p linux after changing that to recompile the kernel ?

EDIT: Not sure about systemd-boot usage, but with GRUB, it requires re-running the grub-mkconfig command to generate the appropriate boot entries for the newly added kernels too.

While it might help in your case, I think first and foremost you should focus on the 5.19.13 linux default kernel, as it is confirmed to work (personally, as well as other people in this thread).
Maybe try disabling the other fbc and fastboot options for i915 in the .conf file, and reboot again.

For later reference, in case you have to compile packages from source faster, you should edited your /etc/makepkg.conf, namely by changing the default line with MAKEPKG_FLAGS="-j2" to something like MAKEPKG_FLAGS="-j$(nproc --all)". This will make the computer use all the core for compilation, which should make it last around 10 to 20 minutes (I also did it yesterday on i7 1260P).

Once you get it working, it is a smooth and pleasant experience.
Maybe give it a try again with a fresher / cooler head :sweat_smile:

Best of luck.

@dosssman Thanks for reply! My friend’s issue is resolved by using intel_pstate scaling driver instead of intel_cpufreq (the driver used given intel_pstate=no_hwp option). The scaling driver without hwp seems too aggressive for 12th gen, limiting most of its cores to 400MHz. Even power state of intel_pstate won’t have that issue.

1 Like

@dosssman I formatted, reinstalled, put in the single line into the kernel config options i915 enable_psr=0 and then rebuilt the kernel and rebooted and havent had a single issue yet.

When I did the install the screen was flickering the entire time (1 second on, then 1 second off repeating) It made it a huge pain to do the install.
I added i915.enable_psr=0 to the end of the linux line but it didnt do anything there, is it supposed to be something else?

I’m up and running now… I was nearly going to leave it in the trash!!
Thanks for your help!

Editing — I’m still struggling
After suspend and resume the lag / freezing video problems came back,
Then I rebooted and when it boots to the console the flickering comes back (1 second off, 1 second on repeating)

After logging in the flickering is gone and the freezing is gone but I cant watch any video from a browser. glxgears performs fine now though as previously it didnt.
An mp4 plays smoothly in vlc, so it seems I have a video issue in firefox and brave / chromium.

1 Like

I managed to resolve this by installing bolt when reading through these guides in the Arch Wiki: Thunderbolt - ArchWiki

1 Like

What is the linux kernel in use ? (`uname

@dosssman As others reported it working, after the reinstall I stuck with 5.19.13

I the driver used is the modesetting one. No login manager. I3-gaps for the window manager.

1 Like

Do you using display scaling ?

You might get better results if you use Early KMS, as per the Arch documentation: Intel graphics - ArchWiki

I have MODULES=(i915) in my mkinitcpio.conf before regenerating it, and it gets rid of one flickering I have observed pretty much every time I boot.
(Note that in my case, it is just a single flickering at boot, so it is not that big of a problem).

Here are my relevant configs, for reference:

# /etc/mkinitcpio.conf
MODULES=(i915)
BINARIES-()
FILES=()
HOOKS=(base systemd autodetect keyboard sd-vconsole modconf block sd-encrypt filesystems fsck) # No need for systemd nor sd-encrypt if you don't use encryption, but will need "resume" if using suspend-to-disk / hibernation
# /etc/modprob.d/i915.conf
options i915 enable_psr=1
options i915 enable_fbc=1
options i915 fastboot=1

Kernel parameters set via GRUB:

loglevel=3 mitigations=auto mem_sleep_default=deep nvme.noacpi=1 acpi_osi=!'Windows 2020' acpi_backlight=vendor

And the ouptut of systool -avm i915 to see what features of the i915 are loaded. Maybe you can diff it with yours to check if there is any difference ?

Module = "i915"

  Attributes:
    coresize            = "2732032"
    initsize            = "0"
    initstate           = "live"
    refcnt              = "56"
    taint               = ""
    uevent              = <store method only>

  Parameters:
    disable_display     = "N"
    disable_power_well  = "-1"
    dmc_firmware_path   = "(null)"
    edp_vswing          = "0"
    enable_dc           = "-1"
    enable_dp_mst       = "Y"
    enable_dpcd_backlight= "-1"
    enable_fbc          = "1"
    enable_guc          = "-1"
    enable_gvt          = "N"
    enable_hangcheck    = "Y"
    enable_ips          = "1"
    enable_psr2_sel_fetch= "Y"
    enable_psr          = "1"
    error_capture       = "Y"
    fastboot            = "1"
    force_probe         = "*"
    force_reset_modeset_test= "N"
    guc_firmware_path   = "(null)"
    guc_log_level       = "-1"
    huc_firmware_path   = "(null)"
    invert_brightness   = "0"
    lmem_bar_size       = "0"
    lmem_size           = "0"
    load_detect_test    = "N"
    lvds_channel_mode   = "0"
    memtest             = "N"
    mitigations         = "auto"
    mmio_debug          = "0"
    modeset             = "-1"
    nuclear_pageflip    = "N"
    panel_use_ssc       = "-1"
    psr_safest_params   = "N"
    request_timeout_ms  = "20000"
    reset               = "3"
    vbt_firmware        = "(null)"
    vbt_sdvo_panel_type = "-1"
    verbose_state_checks= "Y"

  Sections:
    .altinstr_aux       = "0xffffffffc0739108"
    .altinstr_replacement= "0xffffffffc0738f50"
    .altinstructions    = "0xffffffffc073a208"
    .bss                = "0xffffffffc07c03c0"
    .data..read_mostly  = "0xffffffffc07bcd00"
    .data.once          = "0xffffffffc07bbfd0"
    .data               = "0xffffffffc07b4260"
    .exit.text          = "0xffffffffc0738f0a"
    .gnu.linkonce.this_module= "0xffffffffc07c0080"
    .init.text          = "0xffffffffc0824000"
    .note.Linux         = "0xffffffffc07adaec"
    .note.gnu.build-id  = "0xffffffffc07adac8"
    .note.gnu.property  = "0xffffffffc07ada98"
    .ref.data           = "0xffffffffc07bd800"
    .retpoline_sites    = "0xffffffffc079f228"
    .return_sites       = "0xffffffffc07a4e44"
    .rodata             = "0xffffffffc073a740"
    .rodata.str1.1      = "0xffffffffc07645e1"
    .rodata.str1.8      = "0xffffffffc0771908"
    .smp_locks          = "0xffffffffc079dddc"
    .static_call.text   = "0xffffffffc0739140"
    .static_call_sites  = "0xffffffffc07bc037"
    .strtab             = "0xffffffffc085f1a0"
    .symtab             = "0xffffffffc0825000"
    .text               = "0xffffffffc0588000"
    .text.unlikely      = "0xffffffffc0733668"
    __bpf_raw_tp_map    = "0xffffffffc07bcdc0"
    __bug_table         = "0xffffffffc07b0000"
    __ex_table          = "0xffffffffc07ad1f4"
    __jump_table        = "0xffffffffc07ae000"
    __ksymtab_gpl       = "0xffffffffc073a000"
    __ksymtab_strings   = "0xffffffffc07accf8"
    __param             = "0xffffffffc07ac708"
    __tracepoints_ptrs  = "0xffffffffc07ad224"
    __tracepoints_strings= "0xffffffffc07ad340"
    __tracepoints       = "0xffffffffc07be820"
    _ftrace_events      = "0xffffffffc07bd5e0"

With that being said, I alsohappen have one display related problem after resuming from hibernation (suspend-to-disk) on 5.19.13, and most of the other kernels I have tried. I have not yet found a 100% solution, only work arounds.
Namely, after resuming from hibernation, the screen will power on but stay blank and black. I can only see the mouse cursor, and even interact with the windows that were previously opened, executing commands in opened terminals, etc…
Resuming from simple suspend works without problem for me, however.

I suspect there is still some problems with the graphics driver for handling resume on 12th Gen Alder Lake CPU like ours. Hopefully they get ironed out in next kernel / drivers releases.

Regarding the Firefox, Chromium video performance, have you tried to fixes / work around from the Arch wiki ?

https://wiki.archlinux.org/title/Intel_graphics#Corruption_or_unresponsiveness_in_Chromium_and_Firefox

Also saw something that might be relevant in this thread about battery life tuning on the forums: [TRACKING] Linux battery life tuning

Hope it helps somehow.