update so after realising I have ACPI: button: The lid device is not compliant to SW_LID. in my logs I found a couple of bug reports in the kernel https://bugzilla.kernel.org/show_bug.cgi?id=192231 https://bugzilla.kernel.org/show_bug.cgi?id=202421

so I guess this can be as well a kernel issue

so I made a bug report in the arch linux bug reporter: https://bbs.archlinux.org/viewtopic.php?pid=2119116

so yeah I guess and I hope someone understand the problem fix it with udev or the linux kernel directly or at least give me the steps to do so anyway yeah that's all

and I guess if this plan didn't work I have to learn C to fix the issue

there is one problem with those links they are forcing a whole device to be another device and I just want the key with scan code d7 to be state 0 of SW_LID and d8 to be state 1

and fixing this issue in the udev level will automatically fix everything like I will finally be able to use logind.conf

yeah read that bug report and to be honest I don't understand the developer standpoint like sorry at least give where can I find the documentation for udev rules

• even if I use libinput these are the id_input available: ID_INPUT_KEYBOARD, ID_INPUT_KEY, ID_INPUT_MOUSE, ID_INPUT_TOUCHPAD, ID_INPUT_TOUCHSCREEN, ID_INPUT_TABLET, ID_INPUT_JOYSTICK, ID_INPUT_ACCELEROMETER

and there is no lid one so yeah I don't know is this problem unfixable with udev rules alone + I made this whole thread just to not make that bug report one of the other 1.9k other open ones except the fact that I wanna improve my experience with linux

+_+

well as far as I understand adding "AttrLidSwitchReliability=unreliable" will not actually fix the issue and I hope this issue is fixable to be honest

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

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

thanks a lot that will certainly help

so this is the output for the fn+f2/3 "[32752.594169] atkbd serio0: Use 'setkeycodes e02b ' to make it known. [32752.599005] atkbd serio0: Unknown key released (translated set 2, code 0xab on isa0060/serio0)."

and the output for the closing lid "[32780.534749] atkbd serio0: Use 'setkeycodes e058 ' to make it known. [32780.538013] atkbd serio0: Unknown key released (translated set 2, code 0xd8 on isa0060/serio0)."

my question is isn't closing the lid is already assigned to "button/wlan WLAN 00000080 00000000 K" (output from acpi_listen)

• so what should I do now
• this part is actually unclear

"You can find the appropriate evdev:* information by running sudo udevadm test /dev/input/eventX where eventX is the evdev fd for the device in question. evtest will show you the names."

basically how to actually do something like this MSC_KEY_d7=lid MSC_KEY_ab=brightness_thingies

• yeah thanks

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

I hope someone knows a solution lol