-
For your first point you'd probably want to investigate why your system doesn't suspend or what exactly is going on. You could check logind.conf, specifically the HandleLidSwitch* keys. Otherwise, your lid switch should have a corresponding /dev/input/ event that you could maybe listen to or something.
-
I can't offer much input on your second point. I think unplugging the audio jack should probably trigger a udev event that you could write a rule for. No idea about wireplumber though.
this post was submitted on 23 Aug 2023
14 points (93.8% liked)
Linux
48092 readers
899 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
thanks for the idea it actually got me to find something so I am going to use "acpi_listen" I guess its a deamon for acpi the funny thing is closing the lid counts as "button/wlan WLAN 00000080 00000000 K" so I am positive linux or the kernel thinks that closing the lid is pressing the wiki toggle button (that's the current behaviour btw) so I guess the next step is to just find out how can I make the kernel think that closing the lid is actually closing the lid lol
anyway thanks for the help stranger
-
the source of all of this https://askubuntu.com/questions/640741/what-code-is-executed-when-headphones-are-disconnected
-
the followup: https://lemmy.ml/post/3772773
so I made a follow up post: https://lemmy.ml/post/4441946 and a bug report: https://github.com/systemd/systemd/issues/28942 if you are interested in helping
"systemctl suspend" when the lid is closed basically the default behavior doesn't work for some reason
I'd go and figure out why that is instead. Check the journal; I'd journalctl -f before closing the lid and see what happens.
The action of the lid is controlled by logind. Check its config.
If logind can't detect the lid switch, that likely means there's some deeper cause that would affect doing the same manually aswell.
Is your laptop docked (or does Linux think it is)?
but that power comes at the cost of not switching between those respective two sinks
Why? How did you set this up?
How are the device(s?) configured?
You might need "Pro" mode to expose separate outputs as such.
basically I guess this bug report will explain everything: https://github.com/systemd/systemd/issues/28942 and I made this post as a followup: https://lemmy.ml/post/4441946
- basically in my laptop I have 3 problems pressing fn+f2/3 (supposedly brightness keys) it gives the same scan code and I am lost on how to give one of them up and the other down brightness second problem fn+f12 (basically the airport mode aka stop wifi) it doesn't even give a scancode in the first place third problem and the biggest is explained in that bug report and if you have any idea how to deal with this help I guess
and how did I set up the different sinks to headphone and speakers basically just used hdajackretask to make it so idep_hp = yes and then rebooted my laptop and yeah that was basically it and I am in the process of writing a script to change between the two sinks on the fly