The more and more I dig, I think its a hardware issue. I went as far as installing Windows 10 with Secure Boot and all the bells and whistles; and still no mic.
I’m frustrated.
Thanks for your suggestions, I had also thought of switching to pipe or jack options… its not my cam/mic module, its not the hardware switch in the bezel - so I guess I have to go from there.
Could I get some assistance on switching the mouse setting from the default sides profile to the triple/double/single finger click as well as tap to click? The wiki for the framework laptop is kind of confusing as it doesn’t explain the process very well, and I haven’t seen a whole lot of discussion about it here other than one person.
Depending on your desktop environment, there might be some easy ways of setting this - I use GNOME and settings allows me to select tap to click right in the touchpad section… to do the right-click thing I followed the Arch Linux Frame.work pade:
@Paulie420 I used that same wiki that you sent, but I don’t really understand what it wants me to do. I tried using their temporary command to see if that would work, but I’m not really sure what I’m supposed to put for the device portion (i tried imputing id=x). I should also mention that I’m using BSPWM, otherwise I would’ve had an easy time just switching the setting in GNOME settings too.
Although I used the temporary command, I would prefer to do the permanent one, as I liked the way that I was using my touchpad on gnome.
EDIT: I’ve taken some time to understand libinput a bit more, and when I input the command (from the wiki) xinput set-prop “device” “libinput Click Method Enabled” 0 1
I get “property ‘Click Method Enabled’ doesn’t exist, you need to specify its type and format”
I’m looking at the xinput(1) wiki right now, but I’m still unsure of what I would need to input to get that to work. Either way, this is not a persistent setting change, and I’m still looking for the permanent solution to this
EDIT 2: So I have now realized that I need to edit /etc/X11/xorg.conf.d/ to add the triple/double finger click mode as well as tap to click, but what do I need to actually input into the .conf file and what is proper syntax?
That will give you the right settings for BSPWM. If you want to add trackpad gestures you will want the libinput-gestures package as well, which uses a separate config file that lives in ~/.config/ and has to be started separately. (I start it from my bspwmrc file.) That lets you use swipe gestures to change workspaces, which is really handy.
EDIT: Fixed config file path for anyone else who uses this as a reference later!
@Jay_Reding Thanks for the response! I’m so glad that somebody is practically in the same situation as me, and that I can in fact have gestures for switching workspaces (that would’ve been my next task). I hope to also ask you for help with that if I need it.
One question though: I am using vim, and when I try to wq/wq!, my terminal tells me that /etc/X11/xorg.d/40-touchpad.conf cannot be opened for writing. What do I need to do to open this file for writing?
EDIT: Figured out the issue, you had a typo in the directory name. I should’ve noticed but I didn’t lol. Anyways, I didn’t add the “NaturalScrolling” as I am fine with the scrolling out of the box and the same goes for “DisableWhileTyping”, but thank you so much for this help, and I hope to ask you about the gestures as soon as I get to that
@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:
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.
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.
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.
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).
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.
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)!
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.