hi, welcome to the forum.
as of mid 2022 everything works fine on a typical install on the 11th gen, there isn’t a single component that isn’t supported. some have reported some issues here and there (unrelated to arch) but everything works mostly fine.
Been using EndeavourOS (arch derivative) for 7+ months now. No showstoppers at all.
Arch Wiki and other threads on this forum have more details. Search is your friend.
My 12th gen is running really well so far except for occasional GPU crashes.
When it happens the screen freezes and the fans start to ramp up after a bit, unable to switch to tty or anything. Currently using enable_fbc=1 but neither had an impact on this behavior.
I wasn’t able to reproduce it yet, just happened a couple times the last few days.
The dmesg looks like that:
Aug 03 01:58:17.169251 framework kernel: Asynchronous wait on fence 0000:00:02.0:gnome-shell[888]:e752 timed out (hint:intel_atomic_commit_read>
Aug 03 01:58:20.199442 framework kernel: i915 0000:00:02.0: [drm] GPU HANG: ecode 12:1:849ffffb, in gnome-shell [888]
Aug 03 01:58:20.199706 framework kernel: i915 0000:00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0
Aug 03 01:58:20.199800 framework kernel: i915 0000:00:02.0: [drm] gnome-shell[888] context reset due to GPU hang
Aug 03 01:58:20.199883 framework kernel: i915 0000:00:02.0: [drm] GuC firmware i915/adlp_guc_69.0.3.bin version 69.0
Aug 03 01:58:20.199977 framework kernel: i915 0000:00:02.0: [drm] HuC firmware i915/tgl_huc_7.9.3.bin version 7.9
Aug 03 01:58:20.218807 framework kernel: i915 0000:00:02.0: [drm] HuC authenticated
Aug 03 01:58:20.219701 framework kernel: i915 0000:00:02.0: [drm] GuC submission enabled
Aug 03 01:58:20.219877 framework kernel: i915 0000:00:02.0: [drm] GuC SLPC enabled
Does anybody else experience this kind of freezing or can point me in the next direction?
Edit: The same thing just happened casually browsing on firefox and doing some terminal stuff (kitty) but this time it just froze for a second and continued running normal after. I’m seeing lots of usb 3-9: reset full-speed USB device number 2 using xhci_hcd which is the fingerprint sensor but not sure if that’s related.
Having tons of issue with the GPU on my i5-1240p 12th gen as well. Either straight up freezing on gnome like apol1o described, or supper laggy updates when running with my usual xorg/i3 combo, both on modesetting and xf86-video-intel 
EDIT:
This one fixed it: Periodic stuttering on fresh gnome.40 wayland install on Arch Linux - #6 by William_Light
I needed to turn of panel self-refresh.
Should’ve probably added that I’m running wayland/sway. Does xf86-video-intel even support alder lake’s GPUs now?
I did some experimenting and early KMS for i915 improved it too but unfortunately this broke hibernation for me.
However, Linux 5.19 reduced it a lot for me and sometime last week I updated (5.19.2?) and haven’t experienced this issue since.
Which kernel are you running?
Just linking this here:
Arch is working perfectly for him / her.
Anyone else having boot problems after the new grub update?
Grub reboots into bios for me, I thankfully I have timeshift setup and could return to a working system.
Be careful with the new grub update, it borks some grub configs.
I am on Arch stable, I3WM.
5.19.3-arch1, now 5.19.4-arch1
Well, I at least got output with it. But I’ve moved to modesetting, with early KMS, and disabled PSR. Since then it’s working great. Sadly Wayland is not an option for me as too much stuff is still broken by design, that I rely on for work.
Besides PSR the only other quirk that I’ve noticed is the brightness keys, but there are threads about that already with the current workaround of blocking the ALS module, which works for me.
So far very happy with Arch on my i5-1240p 
Thank you @Alphabet for posting this and the reddit link. After about 2 hours fiddling, I was able to get my laptop working again. What a mess! It would probably take days without your post though, many thanks!!!
I would like to add that the stuttering and screen tearing is NOT wayland or GNOME specific. (Unless archinstall installs something in the background that is GNOME related.)…
On Kernal 5.19.5 i3-wm (no gaps) I had the stuttering issue. I added options i915 enable_psr=0" in /etc/modprobe.d/i915.conf` then rebooted and that solved the stuttering.
Installing Arch on the 12th gen Framework. So far so good, though I struggled with a strange issue for a while:
After installing Arch, I installed xorg, awesome and alacritty. Whenever I typed in alacritty, nothing would appear, but whenever I added another alacritty instance to awesome and a refresh occurred, I would see the text I had previously typed. This also happened with kitty but not with xterm.
It turns out that I had installed xf86-video-intel and this after removing this (based on this doc in Arch wiki everything resolved
Installed arch on the 12th gen and besides the kernel parameter to disable the psr feature, evertything worked ootb except for the gtk file dialog menu. Whenever a gtk app opened this dialogue menu an insanely big window would appear that seems to a user like a unicolored screen. In fact you are just seeing a small piece of this huge window. In case you encounter this: press super and drag the mouse to shrink the window. Gtk will remember the setting and you are good to go.
I have a question for the community: Anyone here with a slick setup for automounting an expansion card when plugged in? I have a 1TB expansion card and I want to have it mounted automatically whenever I plug it in. I just tried: Automount USB devices on Linux using UDEV and Systemd | Andrea Fortuna but this doesn’t work for unplugging for some reason
Hello there.
Had the same issue and your post was quite helpful
I use Arch with Xorg, i3wm and alacritty.
How is the rendering speed in alacritty for you ? When typing in the alacritty terminal, it feels a bit slow compared to what I am used to. A bit like working on a remote server.
Same in xterm.
Managed to fix this by adding “i915.enable_psr=0” to the GRUB Kernel parameters, as suggested by:
@apol1o Hey there.
You mentioned that i915 breaks hibernation for you, and I seem to have the same problem.
Curious to see if you find any work around for it ?
I am using Arch LInux with the latest kernel Linux V01DFR4M3 5.19.11-arch1-1 #1 SMP PREEMPT_DYNAMIC Sat, 24 Sep 2022 18:24:15 +0000 x86_64 GNU/Linux. Setup hibernation with swapfile and encryption.
As a sanity check I tested the hibernation by running systemctl hibernate directly from tty1 and it does work.
However, when I start Xorg / i3 combo, and hibernate from there using the same systemctl hibernate command, at resume, I just get a black screen.
The computer itself boots and is working, and I can see the mouse cursor moving, and even access terminal windows opened that were opened before, but it does not render any UI or window, just a blank screen…
Are you having the same issue by any chance ?
Thanks for your time.
Only when loading it early with KMS. I’m not doing that anymore and haven’t tweaked it much since, it’s just working more or less. These days I usually don’t have problems with hibernation but it sometimes hangs when leaving suspension. It’s a bit different each kernel version somehow. However, I’m running the Clear Linux kernel because I get better battery life with it but it seems that the vanilla kernel doesn’t have any problems for me anymore (limited testing though).
Ah yes, had the same issue with sway and occasionally with gnome too.
You should check what dmesg says. Something like sudo journalctl -b-1 -o short-precise -k -p 4 to get it filtered from the last boot.
Are you using the modesetting driver?
I have the following in my sway config file which manages the screen/lock when idle.
I’ve noticed that it works just fine when toggling power to dpms, so that’s basically what it does after resuming sleep/hibernate (last line).
exec swayidle -w \
timeout 30 'if pgrep -x swaylock; then swaymsg "output * dpms off"; fi' \
resume 'swaymsg "output * dpms on"' \
timeout 210 '~/.config/sway/swaylock.sh' \
timeout 270 'swaymsg "output * dpms off"' \
resume 'swaymsg "output * dpms on"' \
timeout 900 'systemctl suspend' \
resume 'swaymsg "output * dpms on"' \
before-sleep 'playerctl pause' \
before-sleep '~/.config/sway/swaylock.sh' \
after-resume 'swaymsg "output * dpms off" && sleep 5 && swaymsg "output * dpms on"'
Probably not the best solution but seemed to do the trick. What I did to test it was to create a script which toggles dpms and bound it to a key.
Can’t remember the i3 way of doing something like that but on X11 you can use xset to toggle dpms.
@apol1o Hello again.
Thanks a lot for the thoughtful answer.
I will be trying the linux-clear kernel, see if it hs better drivers for this situation.
journalctl -b-1 -o short-precise -k -p 4 is flooded with the following lines
i915 0000:00:02.0: [drm] *ERROR* Fault errors on pipe A: 0x00000080
which does seem related to driver issues.
I am indeed using kernel mode setting, with
MODULES=(i915)
in my /etc/mkinitcpio.conf. I tried with and without, but same problem of “black screen / visible mouse” seems to happen.
As far as DMPS is concerned, I can indeed turn the screen on and off with xset dpms force on | off, but in my case, after resume, the DPMS seems to already be on. Namely, I can see the mouser cursor moving, and even use the Xf86Brightness key to control brightness. Only the desktop does not seem to be rendered at all (or covered by a huge black window mask).
In any case, will try to look deeper at how to control the DPMS more precisely before and after the resume, might get lucky too.
UPDATE: Hibernation (systemctl hibernate) now working as expected after installing linux-clear-bin. Huge thanks @apol1o .
I looked it up and it seems like a kernel specialized for intel CPU / GPU ? so it might have more suited graphics drivers. It even works with Kernel Mode setting.
UPDATE 2: While the previous update does mention that hibernation works, there is a potentially serious caveat at stake. I have experimented around with three different kernels: linux from the official Arch packages, linux-clear and linux-clear-bin from the AUR.
It turns out that hibernation is working on linux-clear-bin because some i915 are not working / not compiled in said kernel (throws up a a few error messages on boot, such as Failed to initialized GuC or GPU marked as wedged. So while hibernation works, the GPU / rendering features performances is quite bad. I realized this when trying to do some 3D modeling with blender. It was very slow even with the basic project. Beside that, it seems that battery does not hold as well as it did using the linux kernel, but it might be due to different use cases.
However, linux and linux-clear kernels seem to have better i915 GPU driver support (no glaring i915 related errors thrown on boot). This seems to be corroborated by the fact that blender 3D rendering runs way smoother, compared to linux-clear-bin.
So to sum it up:
linux-clear-bin = 5.19.11.1191-1: sub optimal i915 GPU driver, which happen to break the thing that prevents hibernation (suspend-to-disk) from workinglinux = 5.19.11.arch1-1 (Arch repo) and linux-clear = 5.19.11-1 (AUR) have better i915 drivers, but something in there prevents proper hibernation.I guess I will have to wait for linux kernel that has better i915 graphics support to get the best of both world. Too bad the recent 5.19.12 is broken as of now (2022-09-30)
Blockquote
This fixed it for me as well. Running i3wm (w/gaps) on arch. i3 was insanely slow, with terrible lag and sometimes freezing completely for >10s. I tried sddm to see if I could isolate the issue to i3 and sddm worked beautifully.
Adding this kernel parameter seems to have fixed the issue. I don’t know enough about how i3 works behind the scenes to understand why the issue was only happening there (and not sddm) but I’m happy it’s resolved. Thanks!
Please see the link below. I confirm this as many others do as well.
Beware! Don’t upgrade to linux kernel 5-19-12-arch1-1 on arch linux
Greetings.
Currently experiencing a very peculiar issue regarding hibernation on Arch Linux and the FW 12th, while using Xorg and i3 window manager.
Namely, whenever I resume from hibernation (suspend-to-disk), I am greeted by a blank screen.
The system effectively resumes, the screen does turn, and I can even see and move the mouse, I can interact with the terminal windows that were previously opened before entering hibernation, but beside that the whole screen just stays black.
I would really appreciate if someone could help by trying to run systemctl hibernate on their Framework with Arch, then resume and let me know if they have the same black screen problem on resume.
As a sanity check, I also ran systemctl hibernate from a tty instead of a graphical session, and it does not result in the black screen problem on resume. I suspect some i915 driver related error so far.
I tried many kernels such as linux-mainline, linux-clear, linux-lts already, but to no avail.
Thanks a lot for your time.
For reference, the relevant configuration files of the system would be as follows:
linux /vmlinuz-linux root=UUID=unlocked_part_UUID rw
cryptdevice=UUID=encrypted_part_UUID :root:allow-discards
root=/dev/mapper/root resume=UUID=unlocked_part_UUID
resume_offset=swapfile_offset loglevel=3 quiet intel_pstate=disable
security=apparmor mitigations=auto mem_sleep_default=deep
nvme.noacpi=1 acpi_osi=!'Windows 2020'
echo 'Loading initial ramdisk ...'
initrd /intel-ucode.img /initramfs-linux.img
/etc/mkinitcpio.confMODULES=(i915)
BINARIES=()
FILES=()
HOOKS=(base udev autodetect keyboard keymap consolefont modconf block encrypt filesystems resume fsck)
options i915 enable_psr=0
# options i915 enable_guc=3
# options i915 enable_fbc=0