I am not having any touchpad issues with arch kernel 6.0.10.
Does look like your are missing the PIXA3854 entries that I have in my xinput. Have you tried re-seating the input cover to mainboard cable?
2 Likes
@D.H I tried to re-seat the cable and still have the same xinput entries… Am I looking at a bad touchpad?
1 Like
So i am getting weird freezes when playing games. Started with CKIII native, and is now continuing with Morrowind under proton…
Edit
I have been able to solve the crashing problems by installing the Linux-Clear kernel. Also getting a kind of crazy increase increase in battery life, ~30-40% increase in battery life.
1 Like
I just updated the first comment on the thread, sorting ArchWiki English first and Japanese second. And updated the word “En” to “English”, and “Ja” to “Japanese”, because some people may not be familiar with the abbreviations of the language names. I also noticed that the ArchWiki Japanese page Firmware section is a bit old compared to the English version.
3 Likes
Hi! I recently got a framework laptop, and it’s been working great, except for an issue when I resume from sleep. Here’s the messages I’ve been getting from journalctl (trimmed for brevity, but here’s the full log. Note that the log contains multiple suspends/wakings, it’s only the last that crashed):
Feb 09 07:30:08 mason-laptop systemd-logind[623]: Lid closed.
Feb 09 07:30:09 mason-laptop systemd-logind[623]: The system will suspend now!
# various systems shutting down (NetworkManager, avahi-daemon, dhcpcd, kded5)
Feb 09 07:30:09 mason-laptop systemd[1]: Reached target Sleep.
Feb 09 07:30:09 mason-laptop kded5[1276]: ktp-kded-module: "screen-saver-away" presence change request: "away" ""
Feb 09 07:30:09 mason-laptop kded5[1276]: ktp-kded-module: plugin queue activation: "away" ""
Feb 09 07:30:09 mason-laptop kded5[1276]: ktp-kded-module: "gabble/jabber/google_2dim_1" requested presence change error: "RequestedPresence 0 cannot be set on yourself"
Feb 09 07:30:09 mason-laptop systemd[1]: Starting System Suspend...
Feb 09 07:30:09 mason-laptop systemd-sleep[17131]: Entering sleep state 'suspend'...
Feb 09 07:30:09 mason-laptop kernel: PM: suspend entry (deep)
Feb 09 07:30:10 mason-laptop kernel: Filesystems sync: 0.074 seconds
# A few hours later
Feb 09 13:59:11 mason-laptop kernel: Freezing user space processes ... (elapsed 0.003 seconds) done.
Feb 09 13:59:11 mason-laptop kernel: OOM killer disabled.
Feb 09 13:59:11 mason-laptop kernel: Freezing remaining freezable tasks ... (elapsed 0.043 seconds) done.
Feb 09 13:59:11 mason-laptop kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Feb 09 13:59:11 mason-laptop kernel: ACPI: EC: interrupt blocked
Feb 09 13:59:11 mason-laptop kernel: ACPI: PM: Preparing to enter system sleep state S3
Feb 09 13:59:11 mason-laptop kernel: ACPI: EC: event blocked
Feb 09 13:59:11 mason-laptop kernel: ACPI: EC: EC stopped
Feb 09 13:59:11 mason-laptop kernel: ACPI: PM: Saving platform NVS memory
Feb 09 13:59:11 mason-laptop kernel: Disabling non-boot CPUs ...
Feb 09 13:59:11 mason-laptop kernel: smpboot: CPU 1 is now offline
Feb 09 13:59:11 mason-laptop kernel: smpboot: CPU 2 is now offline
Feb 09 13:59:11 mason-laptop plasmashell[3044]: [3038:3066:0209/135911.971699:ERROR:connection_factory_impl.cc(427)] Failed to connect to MCS endpoint with error -106
And my kernel params: loglevel=3 quiet pcie_aspm=off mem_sleep_default=deep nvme.noacpi=1
It seems to finish the suspend process after waking up. It only sometimes happens though. I enabled deep sleep, so perhaps that may be part of it?
3 Likes
I am happy it will hopefully work 
1 Like
I recently bought a Framework Laptop 13. It has been flawless and the best laptop I’ve ever had except for one issue I’ve found so far. The brightness up/down keys as well as the airplane mode key do not seem to be read by the system. Their corresponding function keys are read fine by programs such as showkey and xev. But when using function lock or just holding fn, the brightness and airplane mode keys are not read at all. No error, just a lack of output. The arch wiki states that these keys are mapped by default (shown here). What could be the issue?
This issue is documented in the following thread. The fix involves blacklisting the hid-sensor-hub kernel module to have the XF86MonBrightnessUp & XF86MonBrightnessDown keys function. Note that blacklisting the mentioned kernel module makes the automatic brightness sensor unusable.
5 Likes
Hi, I recently got my fingerprint login and sudo to work. Does someone else want to try out my “guide” to see if I missed to write down any crucial steps?
1 Like
Is anyone here on AMD? I couldn’t get into GDM and it reported session never registered. Not sure why.
Currently, running Arch on my AMD Framework 13.
3 Likes
You’ll get amdgpu hangs/crashes with the current kernel (6.5.x) and BIOS 3.02, though it works, ish. The reason GDM borks is because the Wayland session crashes the first time you load it. You can load the X11 session, logout and then start the Wayland session and it’ll work. Starting the Wayland session from the TTY also works: XDG_SESSION_TYPE=wayland dbus-run-session gnome-session, but you might have to do it twice.
If by chance you have something like gdm-plymouth-nox installed there won’t be an X11 session at all so you’ll need to load up the normal gdm package first or always go from the TTY.
Other than that, everything works (bluetooth, WiFi etc.). I did find that without configuring the regulatory domain I got stuck on 802.11n (WiFi 4) and 2.4GHz bands. But once you follow the setup in Network configuration/Wireless - ArchWiki everything works.
4 Likes
Just to note, all of this is no longer true since BIOS 3.03. It has resolved all the GPU issues with newer kernels, and everything works as expected now.
My AMD framework is much happier with BIOS 3.03 - all of the GPU issues I was having have been resolved as far as I can tell.
One issue I have is that the internal microphone is incredibly loud, and needs to be set to 30% volume to be usable. My other Intel framework has the same problem, and I was able to solve that by disabling Mic Boost in ALSA. Strangely, that hasn’t solved the issue here.
Finished my first setup with arch and hyprland, really diggin it so far:
Bios 3.03 no real issues so far, didnt tried to get my fingerprint working
5 Likes
Has anyone done a drive swap from an intel machine to an AMD machine? What packages should I pre-install (then uninstall afterward)?
I know at least: power-profiles-daemon instead of thermald.
1 Like
The “Arch” recommendation would be to do a fresh install.
In my case, I did a swap from a desktop Intel to and AMD, and here would be some packages to clear / change to adapt to the new system, so from the top of my head:
- Remove custom linux kernel compiled for Intel if any. Now I just use the default linux kernel on that machine, but there might be something better like linux-zen ?
- Remove intel-ucode and install amd-ucode
- Check mkinitcpio.conf for things like intel’s kernel graphics driver (e.g. i915) that shouldn’t be used on AMD; remove
vulkan-intel, and similar packages. - Updated xorg.conf in case there is any intel specific configuration there
- Nvidia drivers and related packages in case the Intel machine also had an NVIDIA GPU.
1 Like
Why is that the recommendation?
Anyway, I just went through it, and most of the things worked (I was on wayland so no xorg). I also installed vdpau instead of the intel libva for video acceleration, but it’s hard to know if video acceleration is working.
Strangely, wluma stopped working when going from my 12th gen Intel → AMD.
2 Likes
That’s usually the recommendation I have seen floated up a lot in Arch related forums when it comes to changing system, especially when it comes to relatively drastic changes like CPU and such.
The rationale would be that through the life of the system under configuration A, there might be a lot of packages installed to enable a specific features or work around a problem that is native to said configuration. Some users also compile from source (e.g some packages on AUR), even if they don’t realize, so a CPU change might lead to a broken system in case the CPU that the program was compiled against is not used anymore.
More generally, it is quite easy to forget what a given package was installed in the first place, and actually unused packages tend to accumulate.
Therefore, the recommendation when updating to a physical configuration with a significant amount of difference is to do a fresh re-install, then copy the relevant config and dotfiles. Refresh your knowledge of Arch basics, while getting caught up with any changes that might have happened in Arch, and kind of force the user to properly go through their files and triage through.
Find the equivalent of top for your CPU / GPU, then try playing “Costa Rica 4K” on Youtube or equivalent to check whether the relevant pipeline of the processors are getting activated ? This page should have more info in case you are interested / free to go down a not so deep rabbit hole 
1 Like