I fixed it by myself on ArchWiki. Only English version. Because to edit the Japanese translated page, it seems I needed one more account on the Wiki.
1 Like
@Jerry - Glad you got that figured out! The libinput-gestures part is pretty easy - the only think you will want to do is copy the example config to ~/.config/libinput-gestures.conf and then update the device part of the config. I think the device identifier should be the same for all Frameworks:
device PIXA3854:00 093A:0274 Touchpad
If that doesn’t work, you can get the device name this way:
libinput list-devices
Just look for the Touchpad option there and copy the Device name to your config file and you should be ready to go. I personally reversed the swipe left and right lines in my libinput-gestures.conf file (that by default will change workspaces in BSPWM) as it seems more natural to me, but you can play around with what works best for you.
Then you can add
libinput-gestures-setup start
as a line in your bspwmrc file to start the gesture system.
I was just trying this myself and couldn’t get it to work, either. Fwupd stuck an efi application and *.cap file into my boot, I manually added it to the efi boot manager, but it just outputs “Reset System” when it runs on boot and doesn’t update the BIOS.
I’ve been trying to enable verbose debug logs on the efi application, but neither efivars nor the sysfs interface will let me create the FWUPDATE_VERBOSE variable:
[sean@glitch ~]$ sudo efivar -n 0abba7dc-e516-4167-bbf5-4d9d1c739416-FWUPDATE_VERBOSE -w -f /tmp/one
efivar: Input/output error
@Sean_Greenslade Apparently Framework is still testing when it comes to LVFS, according to the Arch Wiki article section on LVFS.
I don’t know is this the right place to report this, but I see an issue. On kernel
5.16.2-1 when I suspend the framework, the keyboard backlight keeps lighting up, though when I close the lid, it disappears, and when I open it reappears.
2 Likes
Perhaps, the issue is same with the following issue. Not sure it is reported on the kernel.org.
1 Like
A rolling distro like Arch Linux, Fedora rawhide, Debian unstable (sid) is for users who are comfortable to report and fix by themselves, downgrading the pacakge in a mean time.
A distro with the stable version release style is more stable. But in this case, Fedora 35 kernel version will be upgraded from 5.15 to 5.16, upgrading a minor version. Fortunately it is not actually released to the stable version package repository yet. On Fedora there is a process to report the testing version using an app called Bodhi. And I reported here. So, I hope this version will be not released.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-57fd391bf8#comment-2394706
If more people are involved in the testing, more issues will be fixed before releasing, and you don’t see the issues on the stable version.
In case of Framework Laptop requiring new kernels and libraries, in term of Fedora, maybe the stable Linux distribution is future Red Hat Enterprise Linux (RHEL) 9.x or downstream distros of the RHEL. On RHEL, as far as I know important packages are only upgraded on the maintenance version level (z in x.y.z) or only a source code patch to fix specific bug is applied. I don’t know other downstream distro’s situation.
One more tip to use stable version is as Framework Laptop works better on Fedora 35 than Fedora 34, people are usually using the Fedora 35, the latest stable version. But if you consider stability, you can use Fedora old stable version (latest stable version - 1 or - 2). I recommend continuing to use Fedora 35 even after Fedora 36 and Fedora 37 are released. I am sorry to write Fedora topic on the Arch thread.
2 Likes
I have similar thoughts that the suspension doesn’t work properly as it seems to drain the battery a lot.
When I installed the system, the kernel version was 5.15.12, and seemed not to have this issue with the backlight. But it didn’t wake when the keyboard was pressed, it waked only with power button press.
1 Like
You may want to enable deep sleep instead of the default s2idle. Deep sleep takes a bit longer to resume, but saves quite a bit more power.
Alternatively, you can do what I do and just use hibernate. If I use hibernate, the battery barely loses charge even after letting sit for a week or so (obviously it will slowly drain down, especially as the battery gets older and less able to hold charge, but that drain is miniscule, especially when the battery is still fairly new).
On Debian (sid), at least, hibernate isn’t disabled (unlike, apparently, some other distros?!), so I just mapped the power button to hibernate (instead of poweroff or shutdown) and manually do a poweroff or reboot if the situation requires it (usually after a kernel update or something).
3 Likes
I’ve been trying to setup hibernate and it still doesn’t work for me. I already have my swap file and put in the necessary things in kernel parameter. Doing systemctl hibernate just results in a fresh reboot for me. How did you do yours?
Edit: Nevermind I forgot to add the resume hook on mkinitcpio.
2 Likes
Has anyone else dealt with high CPU temps? My fan is always on full blast.
Running the 5.16 kernel.
EDIT: Turning on sys_mem_deep_sleep seems to help a little bit.
1 Like
That’s a great question. I think it was a Docker container, actually. Rebooting (and in the process killing the Docker process) probably fixed it. I’m running at normal temps again. Sorry for the noise (no pun intended)!
1 Like
It seems to fix the issue, thanks, I found some instructions on how to do it. I found some instructions on how to do it.
1 Like
I’m running into an annoying regression on Arch Linux with 5.15.24-2-lts - closing the lid does nothing. It doesn’t even try to suspend or disable the internal display when external displays are attached which leads to an annoying issue where the mouse cursor, windows etc. move to the internal display even though the lid is closed and it shouldn’t be on. Could someone else please test this to confirm it’s not an issue only on my end? Thanks.
Edit: Seems to be a bug in the upower package:
I’ve had mine a few days now, I just wanted to document my experiences here in case they help anyone.
Batch 8 (UK) i7-1165G7 64GB RAM and AX210 WiFi
I’m using Garuda Linux (Dragonized) - an Arch derivative which has some nice tweaks. I’ve not long started with arch, so some of this might seem obvious.
Initially, I thought I had a broken machine. The X server kept crashing, everything seemed slow.
It wasn’t until I saw *ERROR* Atomic update failure on pipe in my journalctl output, and found this post on the arch forum that I realised it wasn’t loading the microcode - turns out I needed to install the intel-ucode package and run a grub update
I also struggle with the interface scaling - I like my text small, but that’s too small - and the hidpi settings are too big. So I leave it as tiny, have a script containing xrandr --output eDP1 --scale 0.75 to fix that whenever I reboot or connect a monitor.
Since then, the only problem has been the WIFI. The connection speed is horrible. I have three laptops that I use on my desk a floor away from the router, and the Framework is the only one that has this problem - losing connection after about 30 seconds into big downloads. I don’t suppose anyone has a good fix for that yet?
Otherwise, it’s working well!
3 Likes
I’ve received my machine thursday and put an arch install on it because I wanted to try it out. Honestly, the entire jump from T440-Ubuntu-Gnome40 to Framework-Arch-Gnome41 has been massive. It feels speedy as hell, three fingers swipes are great, I love horizontal workspaces, the install was way, way easier than I had assumed. That being said:
- ~~GNOME 40 has some stuttering issues due to Panel Self-refresh: Periodic stuttering on fresh gnome.40 wayland install on Arch Linux - #7 by Theodore_Koniszewski ~~ Problem is solved in kernel 5.14.2-1.
I would like to contest this statement. The screen glitching out when moving to the side of the screen at native resolution (2256x1504) were still real. You can either fix them as suggested in the link posted by nrp, or you can change the resolution, either will work (or at least worked for me).
To add onto what @Philipp_D said, I used both the latest stable official kernel and zen which should be around 5.16 if I can remember correctly. The issue still persists on gnome 40 (what i have might be 41) wayland.
Batch 8 laptop arrived in the UK yesterday. Last night I did an Arch install including btrfs on top of Luks, swap file on encrypted partition, and got hibernate working, which I’m pretty pleased with.
One problem I hit: pacstrap complained about the keys on every package. I think it’s because I forgot to set the hardware clock. Just fixing the hardware clock didn’t help and there was rebooting involved too.
The strangest thing was after doing the chroot, at first pacman commands worked, then all of a sudden (in the middle of installing packages) it broke again and went back to saying the keys were invalid. I fixed it by copying /etc/pacman/gnupg from the live ISO (where the output of pacman-key --list-keys looked sensible) to the installation (where the --list-keys output had all keys either invalid or unknown). So I’m not certain it was just the hardware clock that was the problem.
1 Like
fwiw I put up a video of a complete Arch install on the Framework, warts and all. It’s quite long but it has chapter bookmarks.
The bit I’m most proud of is getting hibernate to work with a swap file on btrfs on Luks (this starts at the 1:22:20 timestamp and takes about ten minutes until I test it.
(The video is monetised; not because I’m a “YouTuber” but because I can due to a quirk of fate; so don’t click it if you think I shouldn’t be posting such things here.)
4 Likes
@Rob_Fisher I made the experience that I had to repeatedly retrieve gpg keys at least thrice in total (essentially every time I did any command that complained about keys), even with clock set and all.
$ gpg --keyserver-options auto-key-retrieve --verify archlinux-version-x86_64.iso.sig
SImilarly no clue as to why that was
1 Like