Re: new laptop: how2 enable suspend / hibernate?
On Tue, Jun 25, 2024 at 3:34 PM Van Snyder wrote: > > On Tue, 2024-06-25 at 09:47 -0400, Lee wrote: > > My old laptop died - a tiny little pop and it powered off. So I've > lost my implementation reference. > > If you can get the disk drive out of your old laptop, get a USB adapter for > it. Then you can look at your installation logs. I hadn't thought of that -- thanks! > But I can't suspend or hibernate the laptop :( Both options are > greyed out. How do I enable suspend / hibernate? Not being able to do suspend or hibernate seems to be a function of UEFI boot. I never figured out how to do UEFI boot before, so I never had a problem with suspend or hibernate. I seem to have found a work-around tho.. lee@laptop:~$ cat /etc/sudoers.d/adm-grp-privs # members of the adm group can run certain commands as root without supplying # a password # Andrei POPESCU Sun, Dec 5, 2021 at 10:46 AM # To: debian-user@lists.debian.org # Re: Don't try this at home kids Cmnd_AliasADM_COMMANDS = /usr/bin/dmesg, \ /usr/bin/apt list, \ /usr/bin/apt update, \ /usr/bin/systemctl suspend /usr/sbin/checkrestart, \ /usr/sbin/needrestart, \ /usr/sbin/reboot, \ %adm ALL = (root) NOPASSWD: ADM_COMMANDS lee@laptop:~$ cat ~/bin/sleep #!/bin/bash # put the machine to sleep (i hope. how to know **for sure**?? sudo systemctl suspend and make a keyboard shortcut so that s calls ~/lee/bin/sleep so members of the adm group can do certain commands with sudo privs and then Lee
Re: new laptop: how2 enable suspend / hibernate?
On Tue, 2024-06-25 at 09:47 -0400, Lee wrote: > My old laptop died - a tiny little pop and it powered off. So I've > lost my implementation reference. If you can get the disk drive out of your old laptop, get a USB adapter for it. Then you can look at your installation logs. > My new laptop is a Lenovo v15 G3 - installing > debian-12.5.0-amd64-netinst.iso from a flash drive was trivially > easy. > Whoever worked on the how to install Debian from flash did an > excellent job. > > But I can't suspend or hibernate the laptop :( Both options are > greyed out. How do I enable suspend / hibernate? > > TIA, > Lee >
new laptop: how2 enable suspend / hibernate?
My old laptop died - a tiny little pop and it powered off. So I've lost my implementation reference. My new laptop is a Lenovo v15 G3 - installing debian-12.5.0-amd64-netinst.iso from a flash drive was trivially easy. Whoever worked on the how to install Debian from flash did an excellent job. But I can't suspend or hibernate the laptop :( Both options are greyed out. How do I enable suspend / hibernate? TIA, Lee
Re: system won't suspend automatically
On 6/13/24 13:30, David Wright wrote: Swap:0 0 0 You have no swap. Well, that's another good reason it won't work. 1. Fix /etc/fstab so it has PARTLABEL=swapnone swapsw 0 0 2. Run "sudo swapon PARTLABEL=swap" 3.eben@cerberus:~$ free total usedfree shared buff/cache available Mem: 32294664 27093456 2039172 5259032 8887968 52012 Swap: 50331644 050331644 Thanks. -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Ben Franklin
Re: system won't suspend automatically
> Swap:0 0 0 You have no swap. Cheers, David.
Re: system won't suspend automatically
On 6/13/24 11:52, Max Nikulin wrote: On 13/06/2024 21:44, e...@gmx.us wrote: Well that's a no-go, because when you de-power the monitors, ddccontrol gives you no info about what sleep state they're in. Reasonable, I guess. Perhaps there is a command to put the monitor in standby state instead of power off. Maybe it is possible detect switched off state by reading some file in /sys. You still mix monitor and system issues. E.g. a media player may inhibit power saving for monitors. I have seen that sometimes suspend to disk (hibernate) is blocked, but I do not know details. It's blocked by something, to be sure. I don't think it's a failing monitor config script, since it doesn't get errors any more. An obvious reason is full swap, so RAM can not be saved there. Perhaps suspend to RAM may be blocked as well. Swap is nearly empty, all the time. Right now, for example: eben@cerberus:~$ free total used freeshared buff/cache available Mem: 32294664 26585308 3050572 5360560 8486244 5709356 Swap:0 0 0 eben@cerberus:~$ uptime 12:14:13 up 4 days, 22:00, 2 users, load average: 1.14, 1.19, 1.34 So it's not a "just booted" situation. Do I have to tell something the UUID of the new swap partition, or does it figure it out? Update grub and initramfs configuration. Right, I found this page https://wiki.debian.org/Hibernation#Changing_or_moving_the_swap_partition edited /etc/initramfs-tools/conf.d/resume to say RESUME=PARTLABEL=swap and ran "sudo update-initramfs -u". It exited successfully, with no errors or warnings. That won't take effect until I boot on Saturday, and I won't know if it worked until Sunday morning. If I change my swap partition again, I'll also name the new one "swap" so this might keep working. -- Actually, we have scientifically determined that Heisenberg did indeed sleep exactly here. However, we have no idea whatsoever just how fast asleep he was. -- Dave Aronson on ASR
Re: system won't suspend automatically
On 13/06/2024 21:44, e...@gmx.us wrote: Well that's a no-go, because when you de-power the monitors, ddccontrol gives you no info about what sleep state they're in. Reasonable, I guess. Perhaps there is a command to put the monitor in standby state instead of power off. Maybe it is possible detect switched off state by reading some file in /sys. You still mix monitor and system issues. E.g. a media player may inhibit power saving for monitors. I have seen that sometimes suspend to disk (hibernate) is blocked, but I do not know details. An obvious reason is full swap, so RAM can not be saved there. Perhaps suspend to RAM may be blocked as well. There wasn't room on the hard drive to just enlarge the old one without spending a lot of time moving partitions around. Some time then or after, automatic suspension stopped working. Do I have to tell something the UUID of the new swap partition, or does it figure it out? Update grub and initramfs configuration.
Re: system won't suspend automatically
On 6/11/24 12:54, e...@gmx.us wrote: On 6/11/24 12:27, Max Nikulin wrote: On 11/06/2024 21:44, e...@gmx.us wrote: Does anyone know how to get the monitor state programmatically? ddccontrol Thanks. However I am lost if you need to put your monitor to standby state (or to turn it off) or you expect suspend to RAM after some period of inactivity or when lid is closed. In the latter case check power and display settings in your DE configuration. I'll probably watch ddcontrol, and if the monitors go into and stay there for 30m or an hour, suspend. Well that's a no-go, because when you de-power the monitors, ddccontrol gives you no info about what sleep state they're in. Reasonable, I guess. So I'm back to doing it manually, until I figure out what's wrong. Something came to mind: A while back when automatic suspension worked, I got an error that it failed because the swap partition ran out of room. I guess it was doing hybrid sleep and there was too much stuff in swap already? The old partition was the same size as RAM, and the new one is 1.5x. I did these steps to upgrade: Make a new swap partition swapon the new one swapoff the old one remove the old swap partition There wasn't room on the hard drive to just enlarge the old one without spending a lot of time moving partitions around. Some time then or after, automatic suspension stopped working. Do I have to tell something the UUID of the new swap partition, or does it figure it out? -- Information is more dangerous than cannon to a society ruled by lies. --James M Dakin (from RT, S)
Re: system won't suspend automatically
On 6/11/24 12:37, Charles Curley wrote: On Tue, 11 Jun 2024 10:44:12 -0400 e...@gmx.us wrote: Well, that is not encouraging. Does anyone know how to get the monitor state programmatically? I'll write my own script based on that. DFMS works. I mean if the computer won't do it for you, roll your own. Install arandr, use it to set things up the way you want them. Then have it emit a suitable script. OK, no problem. The script I wrote uses xrandr to do that exact thing. Call that from XFCE's session manager on startup. How exactly do I do that, and why would it re-enable suspension? -- "Cheating is the gift man gives himself." - Mr. Burns, The Simpsons.
Re: system won't suspend automatically
On 6/11/24 12:27, Max Nikulin wrote: On 11/06/2024 21:44, e...@gmx.us wrote: Does anyone know how to get the monitor state programmatically? ddccontrol Thanks. However I am lost if you need to put your monitor to standby state (or to turn it off) or you expect suspend to RAM after some period of inactivity or when lid is closed. In the latter case check power and display settings in your DE configuration. I'll probably watch ddcontrol, and if the monitors go into and stay there for 30m or an hour, suspend. Maybe even have it user-configurable if I feel frisky. Maybe even do what it's _supposed_ to do, but you gotta pay extra for that.
Re: system won't suspend automatically
On Tue, 11 Jun 2024 10:44:12 -0400 e...@gmx.us wrote: > Well, that is not encouraging. Does anyone know how to get the > monitor state programmatically? I'll write my own script based on > that. DFMS works. I mean if the computer won't do it for you, roll > your own. Install arandr, use it to set things up the way you want them. Then have it emit a suitable script. Call that from XFCE's session manager on startup. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: system won't suspend automatically
On 11/06/2024 21:44, e...@gmx.us wrote: Does anyone know how to get the monitor state programmatically? ddccontrol However I am lost if you need to put your monitor to standby state (or to turn it off) or you expect suspend to RAM after some period of inactivity or when lid is closed. In the latter case check power and display settings in your DE configuration.
Re: system won't suspend automatically
On 6/10/24 21:11, Ralph Katz wrote: On 6/10/24 13:05, Eben King wrote: Hi, I have a Debian 12 (Bookworm?) installation with XFCE as my DE. [...] and it still doesn't suspend over night. Suspend works just fine when I go to log out and hit the suspend button. I don't see any obvious errors in journalctl. Where can I go to debug suspend? Thanks. I also have bookworm, XFCE and a suspend issue. Dell laptop suspends on lid close, but with an attached monitor, it does not suspend on lid close. As a workaround, I use a keyboard shortcut to suspend. Closing then opening the lid wakes it up. I'm eager to see how you resolve this. If you file a bug, please post the number so I can add my case. Well, that is not encouraging. Does anyone know how to get the monitor state programmatically? I'll write my own script based on that. DFMS works. I mean if the computer won't do it for you, roll your own. -- The best answer when anybody asks you if you're any good with explosives is to hold up two open hands and simply say "Ten". -- Anthony DeBoer on ASR
Re: system won't suspend automatically
Entire attribution and quote removed to avoid the mailing list treating this post as spam. Yes, but I don't know enough about modern monitor connections to know whether the monitor being on will inhibit the system from suspending. The docs for XFCE talk about preventing inconsistent configuration timings of the several modes, but I don't know (not using XFCE) how far this is carried between display management and system power management, or between the kernel's, X's, and XFCE's controls. Sorry not to be more help. Cheers, David.
Re: system won't suspend automatically
On 6/10/24 13:05, Eben King wrote: Hi, I have a Debian 12 (Bookworm?) installation with XFCE as my DE. [...] and it still doesn't suspend over night. Suspend works just fine when I go to log out and hit the suspend button. I don't see any obvious errors in journalctl. Where can I go to debug suspend? Thanks. I also have bookworm, XFCE and a suspend issue. Dell laptop suspends on lid close, but with an attached monitor, it does not suspend on lid close. As a workaround, I use a keyboard shortcut to suspend. Closing then opening the lid wakes it up. I'm eager to see how you resolve this. If you file a bug, please post the number so I can add my case. Regards, Ralph
Re: system won't suspend automatically
On 6/10/24 16:51, David Wright wrote: > On Mon 10 Jun 2024 at 15:05:23 (-0400), Eben King wrote: >> Hi, I have a Debian 12 (Bookworm?) installation with XFCE as my DE. I have >> three monitors, the left one is rotated CW so it's tall, and because lightdm >> can't seem to get that or the monitor positions correct I wrote a script >> that calls xrandr to set things up. >> >> I thought the errors from the monitor setup script (before I fixed it) were >> what was keeping the system from suspending. But now I've fixed the errors >> and it still doesn't suspend over night. Suspend works just fine when I go >> to log out and hit the suspend button. I don't see any obvious errors in >> journalctl. Where can I go to debug suspend? Thanks. > > Does xset -q show you anything like below? > >$ xset -q >Keyboard Control:... eben@cerberus:~$ xset -q Keyboard Control: auto repeat: onkey click percent: 0LED mask: 2002 XKB indicators: 00: Caps Lock: off01: Num Lock:on 02: Scroll Lock: off 03: Compose: off04: Kana:off05: Sleep: off 06: Suspend: off07: Mute:off08: Misc:off 09: Mail:off10: Charging:off11: Shift Lock: off 12: Group 2: off13: Mouse Keys: on auto repeat delay: 500repeat rate: 20 auto repeating keys: 00ffdbbf fadfffefffed 9fff fff7 bell percent: 50bell pitch: 400bell duration: 100 Pointer Control: acceleration: 2/1threshold: 4 Screen Saver: prefer blanking: yesallow exposures: yes timeout: 0cycle: 600 Colors: default colormap: 0x20BlackPixel: 0x0WhitePixel: 0xff Font Path: /usr/share/fonts/X11/misc,/usr/share/fonts/X11/100dpi/:unscaled,/usr/share/fonts/X11/75dpi/:unscaled,/usr/share/fonts/X11/Type1,/usr/share/fonts/X11/100dpi,/usr/share/fonts/X11/75dpi,built-ins DPMS (Energy Star): Standby: 1200Suspend: 0Off: 1800 DPMS is Enabled Monitor is On Like that, yes. What am I looking for? The DPMS stuff is just for monitors, correct? >> Thou shalt keep thine tongue prosperous, and thy mind numb. -Lusers 4:9 > > Thy tongue. This is correct. I'll change it, and note the change. Dang, it's too easy to just do ^R and not hit "reply list". Maybe there's a key command. I'll look into that. -- "The reason that the American Army does so well, is that war is chaos, and the American Army practices chaos on a daily basis." -Nazi German Officer
Re: system won't suspend automatically
On Mon 10 Jun 2024 at 15:05:23 (-0400), Eben King wrote: > Hi, I have a Debian 12 (Bookworm?) installation with XFCE as my DE. I have > three monitors, the left one is rotated CW so it's tall, and because lightdm > can't seem to get that or the monitor positions correct I wrote a script > that calls xrandr to set things up. > > I thought the errors from the monitor setup script (before I fixed it) were > what was keeping the system from suspending. But now I've fixed the errors > and it still doesn't suspend over night. Suspend works just fine when I go > to log out and hit the suspend button. I don't see any obvious errors in > journalctl. Where can I go to debug suspend? Thanks. Does xset -q show you anything like below? $ xset -q Keyboard Control: auto repeat: onkey click percent: 0LED mask: XKB indicators: 00: Caps Lock: off01: Num Lock:off02: Scroll Lock: off 03: Compose: off04: Kana:off05: Sleep: off 06: Suspend: off07: Mute:off08: Misc:off 09: Mail:off10: Charging:off11: Shift Lock: off 12: Group 2: off13: Mouse Keys: off auto repeat delay: 660repeat rate: 25 auto repeating keys: 00ffdbbf fedfffefffed 9fff fff7 bell percent: 50bell pitch: 400bell duration: 100 Pointer Control: acceleration: 2/1threshold: 4 Screen Saver: prefer blanking: yesallow exposures: yes timeout: 1000cycle: 1000 Colors: default colormap: 0x20BlackPixel: 0x0WhitePixel: 0xff Font Path: /usr/share/fonts/X11/misc,/usr/share/fonts/X11/100dpi/:unscaled,/usr/share/fonts/X11/75dpi/:unscaled,/usr/share/fonts/X11/Type1,/usr/share/fonts/X11/100dpi,/usr/share/fonts/X11/75dpi,built-ins DPMS (Energy Star): Standby: 1000Suspend: 1000Off: 1000 DPMS is Enabled Monitor is On $ > Thou shalt keep thine tongue prosperous, and thy mind numb. -Lusers 4:9 Thy tongue. Cheers, David.
system won't suspend automatically
Hi, I have a Debian 12 (Bookworm?) installation with XFCE as my DE. I have three monitors, the left one is rotated CW so it's tall, and because lightdm can't seem to get that or the monitor positions correct I wrote a script that calls xrandr to set things up. I thought the errors from the monitor setup script (before I fixed it) were what was keeping the system from suspending. But now I've fixed the errors and it still doesn't suspend over night. Suspend works just fine when I go to log out and hit the suspend button. I don't see any obvious errors in journalctl. Where can I go to debug suspend? Thanks. -- Thou shalt keep thine tongue prosperous, and thy mind numb. -Lusers 4:9 And if thy head doth leave thine own arse, thou shalt shove it back in. For in such a way does it keep thy minimal knowledge from leaving thine own head. -- Lusers 4:10-11 (ItsDragoniteBitches and mephron on Reddit)
Re: Problem of suspend activities ( debian 12 )
On Thu, Feb 29, 2024 at 06:41:42AM -0700, Charles Curley wrote: > On Thu, 29 Feb 2024 09:38:05 +0100 > Mansour Nasri wrote: > > > Hi I'm using debian 12 in Lenovo yoga legion core i5 12th gen with > > RTX 3050 and I'm figuring a serious issue using debian 12 on this PC, > > When the PC is on sleep mode ( suspend ) it's doesn't wake up anymore > > until forcing shutting down and this each time the PC turns on > > suspend mode, ( fastboot are disabled )of course, on my old PC dell > > i7 10th I never had this kind of issue, but this it it's the case, > > please help to resolve this problem I really don't want to back to > > windows anymore. Thank you so much > > You might look at installing the backports kernel. > You have a machine which has an Nvidia card in it - does it also have Intel graphics as well? If so, you may need to look at how to install ??Prime/bumblebee?? In order to do this, you may need to reinstall / fully disable the nouveau driver and then continue. If you choose to install the proprietary Nvidia drivers - these taint the kernel and so you may have issues with secure boot and enrolling keys. See also https://wiki.debian.org/NVIDIA%20Optimus With every good wish, as ever, Andy Cater (amaca...@debian.org) > -- > Does anybody read signatures any more? > > https://charlescurley.com > https://charlescurley.com/blog/ >
Re: Problem of suspend activities ( debian 12 )
On Thu, 29 Feb 2024 09:38:05 +0100 Mansour Nasri wrote: > Hi I'm using debian 12 in Lenovo yoga legion core i5 12th gen with > RTX 3050 and I'm figuring a serious issue using debian 12 on this PC, > When the PC is on sleep mode ( suspend ) it's doesn't wake up anymore > until forcing shutting down and this each time the PC turns on > suspend mode, ( fastboot are disabled )of course, on my old PC dell > i7 10th I never had this kind of issue, but this it it's the case, > please help to resolve this problem I really don't want to back to > windows anymore. Thank you so much You might look at installing the backports kernel. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Problem of suspend activities ( debian 12 )
Hi I'm using debian 12 in Lenovo yoga legion core i5 12th gen with RTX 3050 and I'm figuring a serious issue using debian 12 on this PC, When the PC is on sleep mode ( suspend ) it's doesn't wake up anymore until forcing shutting down and this each time the PC turns on suspend mode, ( fastboot are disabled )of course, on my old PC dell i7 10th I never had this kind of issue, but this it it's the case, please help to resolve this problem I really don't want to back to windows anymore. Thank you so much
Re: Change suspend type from kde menu
Il 12/01/2024 22:51, Valerio Vanni ha scritto: As Max replied to that post saying that you could avoid to kill Kaffeine now you can try to: - stop Kaffeine - rmmod the module (what happens if you force unloading: -f option) - suspend - resume - modprobe the module - play Kaffeine but I bet you've already realized that :) Yes, it's what I'm going to try :-) I found another issue: kaffeine also records DVB channels. So, if I stop play but it's recording, module cannot be removed. In method I find a "toggle instant record", but it doesn't help because it changes between on and off. If it's not recording and I "toggle", then it starts recording and grabs device. It doesn't seem simple to tell *if* it's recording.
Re: Change suspend type from kde menu
Il 14/01/2024 05:04, Max Nikulin ha scritto: lsof for the same process may be more informative, but currently it does not matter. Perhaps, opening devices in /dev/dvb, kaffeine does not set the O_CLOEXEC flag for open(2) (or does not call fcntl with FD_CLOEXEC). As a result, file descriptors leak to spawned processes. I suggest to reach a community more close to kaffeine (or maybe baloo) developers and ask if it could be improved. In my system baloo is disabled. Which package does tags.so belong to in your case? I believe you that file indexer is disabled, but some components may still be called for reasons unclear for me. Maybe they do something useful. tags.so belongs to baloo-kf5, but "balooctl --status" says that it's disabled.
Re: Change suspend type from kde menu
On 13/01/2024 22:37, Valerio Vanni wrote: Il 13/01/2024 16:20, Max Nikulin ha scritto: And this is one with a --lastchannel launch: lrwx-- 1 valerio valerio 64 12 gen 20.52 34 -> /dev/dvb/adapter0/frontend0 lsof for the same process may be more informative, but currently it does not matter. Perhaps, opening devices in /dev/dvb, kaffeine does not set the O_CLOEXEC flag for open(2) (or does not call fcntl with FD_CLOEXEC). As a result, file descriptors leak to spawned processes. I suggest to reach a community more close to kaffeine (or maybe baloo) developers and ask if it could be improved. In my system baloo is disabled. Which package does tags.so belong to in your case? I believe you that file indexer is disabled, but some components may still be called for reasons unclear for me. Maybe they do something useful. Leaking of file descriptors to child processes is not uncommon issue. Ideally both sides should take measures to avoid it, but to mitigate it is enough that any party handle file descriptors with care. However it is just my guess, maybe actual cause of the issue with tags.so is completely different. P.S. Years ago KDE developers decided to remove controls that allowed to disable file indexer. Otherwise nobody would use it since previous version caused enough troubles. Fortunately that times have gone.
Re: Change suspend type from kde menu
Il 13/01/2024 16:20, Max Nikulin ha scritto: And this is one with a --lastchannel launch: lrwx-- 1 valerio valerio 64 12 gen 20.52 34 -> /dev/dvb/adapter0/frontend0 lsof for the same process may be more informative, but currently it does not matter. Perhaps, opening devices in /dev/dvb, kaffeine does not set the O_CLOEXEC flag for open(2) (or does not call fcntl with FD_CLOEXEC). As a result, file descriptors leak to spawned processes. I suggest to reach a community more close to kaffeine (or maybe baloo) developers and ask if it could be improved. In my system baloo is disabled.
Re: Change suspend type from kde menu
On 13/01/2024 04:39, Valerio Vanni wrote: Il 12/01/2024 17:24, Max Nikulin ha scritto: On 12/01/2024 21:36, Valerio Vanni wrote: dbus-send --print-reply --dest=org.mpris.kaffeine /Player org.freedesktop.MediaPlayer.Stop It seems implementation of MPRIS in kaffeine differs from what other KDE components expect. E.g. media control buttons does not appear on the lock screen. What is baloo's tags.so doing with /dev/dvb devices accordingly to lsof report? I still had a hope that there is a workarond against its annoying behavior. And this is one with a --lastchannel launch: lrwx-- 1 valerio valerio 64 12 gen 20.52 34 -> /dev/dvb/adapter0/frontend0 lsof for the same process may be more informative, but currently it does not matter. Perhaps, opening devices in /dev/dvb, kaffeine does not set the O_CLOEXEC flag for open(2) (or does not call fcntl with FD_CLOEXEC). As a result, file descriptors leak to spawned processes. I suggest to reach a community more close to kaffeine (or maybe baloo) developers and ask if it could be improved.
Re: Change suspend type from kde menu
Il 12/01/2024 21:15, Franco Martelli ha scritto: > Tried, it works on DVB play. > > dbus-send --print-reply --dest=org.mpris.kaffeine /Player org.freedesktop.MediaPlayer.Stop As Max replied to that post saying that you could avoid to kill Kaffeine now you can try to: - stop Kaffeine - rmmod the module (what happens if you force unloading: -f option) - suspend - resume - modprobe the module - play Kaffeine but I bet you've already realized that :) Yes, it's what I'm going to try :-) Force module unloading cannot work, it requires a specific option in kernel config that I've never enabled. You can also try to not remove the module and check if stop Kaffeine, suspend/resume, play Kaffeine is enough. The module does not support suspend / resume at all. If you boot the system, *don't* open kaffeine or anything, suspend and resume, module is already in an unworkable state.
Re: Change suspend type from kde menu
Il 12/01/2024 17:24, Max Nikulin ha scritto: On 12/01/2024 21:36, Valerio Vanni wrote: Tried, it works on DVB play. dbus-send --print-reply --dest=org.mpris.kaffeine /Player org.freedesktop.MediaPlayer.Stop The question is if this action can be a replacement for killing kaffeine before unloading the dvb kernel module. I'll try. It could make the script simpler. If I launch kaffeine without --lastchannel, it should work. That way I'd have to open tv interface by hand when I start kaffeine. What is baloo's tags.so doing with /dev/dvb devices accordingly to lsof report? I still had a hope that there is a workarond against its annoying behavior. This is a file descriptors list of kioslave process, with a plain launch: lrwx-- 1 valerio valerio 64 12 gen 20.53 0 -> /dev/pts/1 lrwx-- 1 valerio valerio 64 12 gen 20.53 1 -> /dev/pts/1 lrwx-- 1 valerio valerio 64 12 gen 20.53 19 -> '/memfd:pulseaudio (deleted)' lrwx-- 1 valerio valerio 64 12 gen 20.53 2 -> /dev/pts/1 lr-x-- 1 valerio valerio 64 12 gen 20.53 25 -> /run/user/1000/dvbpipe.m2t l-wx-- 1 valerio valerio 64 12 gen 20.53 26 -> /run/user/1000/dvbpipe.m2t lrwx-- 1 valerio valerio 64 12 gen 20.53 3 -> 'anon_inode:[eventfd]' lr-x-- 1 valerio valerio 64 12 gen 20.53 31 -> anon_inode:inotify lrwx-- 1 valerio valerio 64 12 gen 20.53 4 -> 'socket:[10323613]' And this is one with a --lastchannel launch: lr-x-- 1 valerio valerio 64 12 gen 20.52 0 -> 'pipe:[9256505]' lrwx-- 1 valerio valerio 64 12 gen 20.52 1 -> 'socket:[71658]' lrwx-- 1 valerio valerio 64 12 gen 20.52 19 -> '/memfd:pulseaudio (deleted)' lrwx-- 1 valerio valerio 64 12 gen 20.52 2 -> 'socket:[71658]' lr-x-- 1 valerio valerio 64 12 gen 20.52 25 -> /run/user/1000/dvbpipe.m2t l-wx-- 1 valerio valerio 64 12 gen 20.52 26 -> /run/user/1000/dvbpipe.m2t lrwx-- 1 valerio valerio 64 12 gen 20.52 3 -> 'anon_inode:[eventfd]' lr-x-- 1 valerio valerio 64 12 gen 20.52 31 -> anon_inode:inotify lrwx-- 1 valerio valerio 64 12 gen 20.52 34 -> /dev/dvb/adapter0/frontend0 lr-x-- 1 valerio valerio 64 12 gen 20.52 36 -> 'pipe:[9253331]' l-wx-- 1 valerio valerio 64 12 gen 20.52 37 -> 'pipe:[9253331]' lrwx-- 1 valerio valerio 64 12 gen 20.52 4 -> 'socket:[9247546]' lr-x-- 1 valerio valerio 64 12 gen 20.52 48 -> anon_inode:inotify lrwx-- 1 valerio valerio 64 12 gen 20.52 54 -> '/memfd:pulseaudio (deleted)' But perhaps it says nothing new.
Re: Change suspend type from kde menu
On 12/01/24 at 15:38, Valerio Vanni wrote: ~$ busctl --user tree | grep mpris Service org.mpris.kaffeine: Another question, can Kaffeine stop the video? Do you have a "Stop" button to click over? Yes, it has play/stop button. I saw that in another post you have find the dbus object and method to stop/play Kaffeine: > Tried, it works on DVB play. > > dbus-send --print-reply --dest=org.mpris.kaffeine /Player org.freedesktop.MediaPlayer.Stop As Max replied to that post saying that you could avoid to kill Kaffeine now you can try to: - stop Kaffeine - rmmod the module (what happens if you force unloading: -f option) - suspend - resume - modprobe the module - play Kaffeine but I bet you've already realized that :) You can also try to not remove the module and check if stop Kaffeine, suspend/resume, play Kaffeine is enough. -- Franco Martelli
Re: Change suspend type from kde menu
On 12/01/2024 21:36, Valerio Vanni wrote: Tried, it works on DVB play. dbus-send --print-reply --dest=org.mpris.kaffeine /Player org.freedesktop.MediaPlayer.Stop The question is if this action can be a replacement for killing kaffeine before unloading the dvb kernel module. What is baloo's tags.so doing with /dev/dvb devices accordingly to lsof report? I still had a hope that there is a workarond against its annoying behavior.
Re: Change suspend type from kde menu
Il 12/01/2024 15:03, Franco Martelli ha scritto: On 11/01/24 at 15:10, Valerio Vanni wrote: Yes, I tried, but I didn't see any "stop". There is a .Quit, but for this I already have "kill" command and I have to start it again. valerio@newton:~$ busctl --user introspect org.mpris.kaffeine / Out of curiosity could you post the output of the following command: ~$ busctl --user tree | grep mpris Service org.mpris.kaffeine: Another question, can Kaffeine stop the video? Do you have a "Stop" button to click over? Yes, it has play/stop button.
Re: Change suspend type from kde menu
Il 12/01/2024 12:08, Valerio Vanni ha scritto: Il 12/01/2024 03:52, Max Nikulin ha scritto: I assume that "org/mpris/MediaPlayer2" after "/" was lost during copy&paste. I don't have MediaPlayer2 there. busctl --user introspect org.mpris.kaffeine /Player # ... .Stop method - - - I saw that, but I think it's for media player component of kaffeine. With that, you could stop the play of an audio or video file. Do you think it can also act on DVB channels? I can give it a try. Tried, it works on DVB play. dbus-send --print-reply --dest=org.mpris.kaffeine /Player org.freedesktop.MediaPlayer.Stop dbus-send --print-reply --dest=org.mpris.kaffeine /Player org.freedesktop.MediaPlayer.Play
Re: Change suspend type from kde menu
On 11/01/24 at 15:10, Valerio Vanni wrote: Yes, I tried, but I didn't see any "stop". There is a .Quit, but for this I already have "kill" command and I have to start it again. valerio@newton:~$ busctl --user introspect org.mpris.kaffeine / Out of curiosity could you post the output of the following command: ~$ busctl --user tree | grep mpris Don't forget to run Kaffeine first. Another question, can Kaffeine stop the video? Do you have a "Stop" button to click over? -- Franco Martelli
Re: Change suspend type from kde menu
Il 12/01/2024 03:52, Max Nikulin ha scritto: I assume that "org/mpris/MediaPlayer2" after "/" was lost during copy&paste. I don't have MediaPlayer2 there. busctl --user introspect org.mpris.kaffeine /Player # ... .Stop method - - - I saw that, but I think it's for media player component of kaffeine. With that, you could stop the play of an audio or video file. Do you think it can also act on DVB channels? I can give it a try. So it is baloo (former nepomuk) search framework. A crazy idea is to add /dev to the list of directories that should not be indexed. I would try to disable baloo completely to see if behavior in respect to rmmmod changes. Baloo is already disabled. Finally I am confused. If tags.so processes die after some interval of time, does it mean that the kernel module can be unloaded even when kaffeine is started with --lastchannel and enough time has passed since its start? From its stop, not from its start. There are two main cases: plain kaffeine and lastchannel one. I open kaffeine without options, I play a DVB channel. kioslave process is active, but has no lock on /dev/dvb/* I stop play and I can immediately remove module. Even if that kioslave process is active. I open kaffeine with --lastchannel, and kioslave process already has a lock on /dev/dvb/* I stop play and cannot remove module, it's locked from kioslave. When some minute has passed, kioslave disappears and I can remove module. Now I see another case: even during channel play, some time kioslave process disappears. At that point, if I stop play, I can remove module.
Re: Change suspend type from kde menu
On 11/01/2024 22:45, Valerio Vanni wrote: Il 11/01/2024 16:25, Max Nikulin ha scritto: On 11/01/2024 21:10, Valerio Vanni wrote: valerio@newton:~$ busctl --user introspect org.mpris.kaffeine / I assume that "org/mpris/MediaPlayer2" after "/" was lost during copy&paste. I don't have MediaPlayer2 there. busctl --user introspect org.mpris.kaffeine /Player # ... .Stop method- -- I have no idea if MPRIS API spec prescribes to implement /org/mpris/MediaPlayer2 or /Player /lib/x86_64-linux-gnu/libexec/kf5/kioslave5 /usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/tags.so tags local:/run/user/1000/kaffeinerCGcGi.1.kioworker.socket lsof, unlike ps, reports a kind of access, e.g. CWD why some file is opened. So it is baloo (former nepomuk) search framework. A crazy idea is to add /dev to the list of directories that should not be indexed. I would try to disable baloo completely to see if behavior in respect to rmmmod changes. Have you checked if the tags.so process opens some devices under /dev/dvb? An idea is that this process seizes its read attempts after some timeout. I would not expect it from an indexing framework. From my point of view it should read only regular files, otherwise it is a bug. I do not know which way file tags are implemented in KDE (a hidden file inside a directory or some DB in the user home directory), so it hard to reason why baloo holds something in /dev Maybe it is something with "recently used" (~/.local/share/recently-used.xbel), but I am unsure if kaffeine intentionally notifies desktop environment or it calls a method that is not appropriate in the context of /dev/ Finally I am confused. If tags.so processes die after some interval of time, does it mean that the kernel module can be unloaded even when kaffeine is started with --lastchannel and enough time has passed since its start? From another message: I see that I must leave XDG_RUNTIME_DIR, if I remove it I get an error "Failed to connect to bus: No medium found" I can confirm it. Actually I was asking about "$kafdis XDG_CURRENT_DESKTOP=KDE", but Thunderbird broke formatting around. It has hidden notion of cited text and it affects wrapping in the case of flowed text format. E.g. "> some text" typed directly does not become a part of citation, it is necessary to paste "copy text" from clipboard using [Ctrl+Shift+O]. On the other hand "this line contains cited text" state may persist for lines having no text. Sometimes it happens during adding text between cited lines. I have not steps to reproduce suitable for bug report yet.
Re: Change suspend type from kde menu
Il 11/01/2024 16:25, Max Nikulin ha scritto: On 11/01/2024 21:10, Valerio Vanni wrote: There is a .Quit, but for this I already have "kill" command and I have to start it again. Applications might handle D-Bus messages more gracefully than SIGINT or SIGTERM signals. However in the case of kaffeine it is unlikely that some data may be lost. It's what I think too. valerio@newton:~$ busctl --user introspect org.mpris.kaffeine / I assume that "org/mpris/MediaPlayer2" after "/" was lost during copy&paste. I don't have MediaPlayer2 there. /lib/x86_64-linux-gnu/libexec/kf5/kioslave5 /usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/tags.so tags local:/run/user/1000/kaffeinerCGcGi.1.kioworker.socket So it is baloo (former nepomuk) search framework. A crazy idea is to add /dev to the list of directories that should not be indexed. I would try to disable baloo completely to see if behavior in respect to rmmmod changes. I am surprised that it dies immediately if you kill kaffeine. It seems to always die, I've never had an error during rmmod.
Re: Change suspend type from kde menu
Il 11/01/2024 15:21, Valerio Vanni ha scritto: Il 11/01/2024 04:57, Max Nikulin ha scritto: On 10/01/2024 04:43, Valerio Vanni wrote: Il 07/01/2024 06:44, Max Nikulin ha scritto: setpriv --reuid 1000 --regid 1000 --init-groups --reset-env -- \ env XDG_RUNTIME_DIR="/run/user/1000" \ systemd-run --user --slice=app.slice -- \ xterm setpriv --reuid="$kafuid" --regid="$kafgid" --init-groups --reset-env \ env XDG_RUNTIME_DIR=/run/user/"$kafuid" > $kafdis XDG_CURRENT_DESKTOP=KDE \ ---^^^ Do you really need it? It's all left there from when I used setpriv to launch directly kaffeine, before I decided to use systemd-run. I'll try to remove it, now I checked and they are all listed in systemd user environment. I see that I must leave XDG_RUNTIME_DIR, if I remove it I get an error "Failed to connect to bus: No medium found"
Re: Change suspend type from kde menu
On 11/01/2024 21:10, Valerio Vanni wrote: There is a .Quit, but for this I already have "kill" command and I have to start it again. Applications might handle D-Bus messages more gracefully than SIGINT or SIGTERM signals. However in the case of kaffeine it is unlikely that some data may be lost. valerio@newton:~$ busctl --user introspect org.mpris.kaffeine / I assume that "org/mpris/MediaPlayer2" after "/" was lost during copy&paste. org.freedesktop.MediaPlayer interface - - - .Identity method - s - .MprisVersion method - (qq) - .Quit method - - - Looks quite useless. Does ".Stop" appear when kaffeine is playing some channel? lsof | grep /dev/dvb shows 10315 ? S 0:00 /lib/x86_64-linux-gnu/libexec/kf5/kioslave5 /usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/tags.so tags local:/run/user/1000/kaffeinerCGcGi.1.kioworker.socket So it is baloo (former nepomuk) search framework. A crazy idea is to add /dev to the list of directories that should not be indexed. I would try to disable baloo completely to see if behavior in respect to rmmmod changes. I am surprised that it dies immediately if you kill kaffeine. Actually I run out of ideas. It seems you have a working solution and further polishing is optional. On 10/01/2024 01:32, Valerio Vanni wrote: So systemd-run should talk to the systemd --user instance. I have tried to set XDG_RUNTIME_DIR="/run/user/1000" BUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus" in setpriv ... env, but systemd requires authentication. I don't see authentication requests, but it still stays under system.slice. By mistake, I tried something like (missed --user) setpriv --reuid 1000 --regid 1000 --init-groups --reset-env -- \ env XDG_RUNTIME_DIR="/run/user/1000" \ systemd-run --slice=app.slice -- \ xterm and I wrongly decided that systemd *user* session rejects D-Bus messages basing on some process attributes, e.g. looking into /proc/PID/sessionid (set by pam_loginuid) and comparing it with logind state (loginctl list-sessions). The user is not added to any groups with higher privileges. Fortunately proper command works and no tricks are required besides setting the path where D-Bus socket should be found.
Re: Change suspend type from kde menu
Il 11/01/2024 04:57, Max Nikulin ha scritto: On 10/01/2024 04:43, Valerio Vanni wrote: Il 07/01/2024 06:44, Max Nikulin ha scritto: setpriv --reuid 1000 --regid 1000 --init-groups --reset-env -- \ env XDG_RUNTIME_DIR="/run/user/1000" \ systemd-run --user --slice=app.slice -- \ xterm setpriv --reuid="$kafuid" --regid="$kafgid" --init-groups --reset-env \ env XDG_RUNTIME_DIR=/run/user/"$kafuid" > $kafdis XDG_CURRENT_DESKTOP=KDE \ ---^^^ Do you really need it? It's all left there from when I used setpriv to launch directly kaffeine, before I decided to use systemd-run. I'll try to remove it, now I checked and they are all listed in systemd user environment. I find it not really safe to use $kafdis without quotes. Yes, neither I liked to catch that string. But I considered it a temporary solution.
Re: Change suspend type from kde menu
Il 11/01/2024 05:10, Max Nikulin ha scritto:
On 10/01/2024 01:59, Valerio Vanni wrote:
Il 06/01/2024 17:38, Max Nikulin ha scritto:
I would expect something like "Stop" either from /Player or from
org.mpris.kaffeine.
I too expected something similar: stop and play (play for resume)
Have you tried "tree" and "introspect" for org.mpris.kaffeine (not
org.kde.kaffeine)? It works for mpv:
Yes, I tried, but I didn't see any "stop". There is a .Quit, but for
this I already have "kill" command and I have to start it again.
valerio@newton:~$ busctl --user introspect org.mpris.kaffeine /
NAMETYPE SIGNATURE RESULT/VALUE FLAGS
org.freedesktop.DBus.Introspectable interface - --
.Introspect method- s-
org.freedesktop.DBus.Peer interface - --
.GetMachineId method- s-
.Ping method- --
org.freedesktop.DBus.Properties interface - --
.Getmethodssv-
.GetAll methods a{sv}-
.Setmethodssv --
.PropertiesChanged signalsa{sv}as --
org.freedesktop.MediaPlayer interface - --
.Identity method- s-
.MprisVersion method- (qq) -
.Quit method- --
busctl --user call org.mpris.MediaPlayer2.mpv \
/org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player \
Stop
For this we don't need to look here:
"rmmod: ERROR: Module cx23885 is in use" seems enough to see that
kernel module cannot be removed.
I am surprised by it. You have shown that kaffeine closes the device, so
it should be possible to remove the kernel module:
Started with --lastchannel
Video stopped:
lrwx-- 1 valerio valerio 64 9 gen 19.51 6 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64 9 gen 19.51 62 -> /dev/dri/renderD128
lrwx-- 1 valerio valerio 64 9 gen 19.51 7 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64 9 gen 19.51 8 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64 9 gen 19.51 9 -> /dev/dri/card0
no more /dev/dvb/, but still unable to remove module cx23885
My hypotheses:
- there are more kaffeine processes (ps xuwf)
No, it has only one.
- some external process is holding the device, e.g. pulseaudio or
pipeware sound server. Tools that might help to find it: lsof or fuser
(unsure concerning proper options)
- Some other IPC exposed by the driver and used by kaffeine.
- I have not idea if it is possible to create direct connection between
the dvb device and the video card so that data pass without intermediate
interaction with kaffeine.
fuser -a /dev/dvb/adapter0/demux0 shows nothing
lsof | grep /dev/dvb shows
10315 ?S 0:00
/lib/x86_64-linux-gnu/libexec/kf5/kioslave5
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/tags.so tags
local:/run/user/1000/kaffeinerCGcGi.1.kioworker.socket
But after some minutes this process disappeared, and I could rmmod.
Perhaps with --lastchannel it's slower to release it?
Re: Change suspend type from kde menu
Il 11/01/2024 04:48, Max Nikulin ha scritto: So your idea would be stopping and starting channel play by dbus messages? I'm looking again with introspect, and I don't see anything like "stop" in kaffeine. It is independent ideas: - Do not deal with user processes in system context (like /usr/lib/systemd/system-sleep/ scripts) - Try to release dvb tuner device, so module can be unloaded. I believe, it is a bug in the cx23885 module that it can not handle suspend/resume (and probably hibernate/thaw). I agree. If cx23885 module could handle suspend/resume, we wouldn't need all this mess. Since we are talking about this module, I quote from another of your messages: P.S. You have explicit modprobe cx23885. Does it mean that this module is not autoloaded when udev discovers the device? The module is autoloaded when system boots. But if I (after having moved away the script from /usr/lib/systemd/system-sleep/) rmmod systemctl-suspend resume pc the module is not loaded. When I used pm-suspend, remove and reload was managed from the line SUSPEND_MODULES="cx23885" in /etc/pm/config.d/modules And now from rmmod and modprobe in my script. By itself... no load. The following is related to avoiding "setpriv" in system context and listening for D-Bus events in user session scope: $ dbus-monitor --system "type='signal',interface='org.freedesktop.login1.Manager',member='PrepareForSleep'" suspend: signal time=1704679441.870349 sender=:1.6 -> destination=(null destination) serial=3187 path=/org/freedesktop/login1; interface=org.freedesktop.login1.Manager; member=PrepareForSleep^^^ boolean true resume: signal time=1704679448.065409 sender=:1.6 -> destination=(null destination) serial=3233 path=/org/freedesktop/login1; interface=org.freedesktop.login1.Manager; member=PrepareForSleep boolean false ---^ A tiny python script may be more convenient than dbus-monitor and similar tools. Killing and starting kaffeine in response to these signals may be a workaround if the application does not allow to release the device. Not stopping playback and not releasing the device in response to the PrepareForSleep signal, from my point of view, is a bug in kaffeine. I have no idea if vlc (broken hardware acceleration in bookworm) or another application may be an alternative for you. To watch television, kaffeine seems very good to me.
Re: Change suspend type from kde menu
On 10/01/2024 01:59, Valerio Vanni wrote: Il 06/01/2024 17:38, Max Nikulin ha scritto: I would expect something like "Stop" either from /Player or from org.mpris.kaffeine. I too expected something similar: stop and play (play for resume) Have you tried "tree" and "introspect" for org.mpris.kaffeine (not org.kde.kaffeine)? It works for mpv: busctl --user call org.mpris.MediaPlayer2.mpv \ /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player \ Stop For this we don't need to look here: "rmmod: ERROR: Module cx23885 is in use" seems enough to see that kernel module cannot be removed. I am surprised by it. You have shown that kaffeine closes the device, so it should be possible to remove the kernel module: Started with --lastchannel Video stopped: lrwx-- 1 valerio valerio 64 9 gen 19.51 6 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.51 62 -> /dev/dri/renderD128 lrwx-- 1 valerio valerio 64 9 gen 19.51 7 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.51 8 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.51 9 -> /dev/dri/card0 no more /dev/dvb/, but still unable to remove module cx23885 My hypotheses: - there are more kaffeine processes (ps xuwf) - some external process is holding the device, e.g. pulseaudio or pipeware sound server. Tools that might help to find it: lsof or fuser (unsure concerning proper options) - Some other IPC exposed by the driver and used by kaffeine. - I have not idea if it is possible to create direct connection between the dvb device and the video card so that data pass without intermediate interaction with kaffeine.
Re: Change suspend type from kde menu
On 10/01/2024 04:43, Valerio Vanni wrote: Il 07/01/2024 06:44, Max Nikulin ha scritto: setpriv --reuid 1000 --regid 1000 --init-groups --reset-env -- \ env XDG_RUNTIME_DIR="/run/user/1000" \ systemd-run --user --slice=app.slice -- \ xterm setpriv --reuid="$kafuid" --regid="$kafgid" --init-groups --reset-env \ env XDG_RUNTIME_DIR=/run/user/"$kafuid" > $kafdis XDG_CURRENT_DESKTOP=KDE \ ---^^^ Do you really need it? I find it not really safe to use $kafdis without quotes. The pattern in grep is rather loose one, it may capture several variables and some of variables may have spaces in their values. On the other hand the current pattern should capture WAYLAND_DISPLAY. The point is that kaffeine inherits environment from systemd user session. I have all necessary variables set in systemctl --user show-environment My command works for me without explicit environment tricks. systemd-run --user --slice=app.slice /usr/bin/kaffeine --lastchannel > /dev/null 2>&1 P.S. You have explicit modprobe cx23885. Does it mean that this module is not autoloaded when udev discovers the device?
Re: Change suspend type from kde menu
On 11/01/2024 02:32, Valerio Vanni wrote: Il 08/01/2024 04:29, Max Nikulin ha scritto: On 07/01/2024 12:44, Max Nikulin wrote: setpriv --reuid 1000 --regid 1000 --init-groups --reset-env -- \ env XDG_RUNTIME_DIR="/run/user/1000" \ systemd-run --user --slice=app.slice -- \ xterm Instead of tricks with setting proper context for a process executed system-wide, I would consider a process running in user sessions and listening for D-Bus events: So your idea would be stopping and starting channel play by dbus messages? I'm looking again with introspect, and I don't see anything like "stop" in kaffeine. It is independent ideas: - Do not deal with user processes in system context (like /usr/lib/systemd/system-sleep/ scripts) - Try to release dvb tuner device, so module can be unloaded. I believe, it is a bug in the cx23885 module that it can not handle suspend/resume (and probably hibernate/thaw). The following is related to avoiding "setpriv" in system context and listening for D-Bus events in user session scope: $ dbus-monitor --system "type='signal',interface='org.freedesktop.login1.Manager',member='PrepareForSleep'" suspend: signal time=1704679441.870349 sender=:1.6 -> destination=(null destination) serial=3187 path=/org/freedesktop/login1; interface=org.freedesktop.login1.Manager; member=PrepareForSleep^^^ boolean true resume: signal time=1704679448.065409 sender=:1.6 -> destination=(null destination) serial=3233 path=/org/freedesktop/login1; interface=org.freedesktop.login1.Manager; member=PrepareForSleep boolean false ---^ A tiny python script may be more convenient than dbus-monitor and similar tools. Killing and starting kaffeine in response to these signals may be a workaround if the application does not allow to release the device. Not stopping playback and not releasing the device in response to the PrepareForSleep signal, from my point of view, is a bug in kaffeine. I have no idea if vlc (broken hardware acceleration in bookworm) or another application may be an alternative for you. Stopping playback through D-Bus by a custom script might be performed either from PrepareForSleep D-Bus signal listener or from a system-sleep script. I will respond to another message.
Re: Change suspend type from kde menu
Il 08/01/2024 04:29, Max Nikulin ha scritto: On 07/01/2024 12:44, Max Nikulin wrote: setpriv --reuid 1000 --regid 1000 --init-groups --reset-env -- \ env XDG_RUNTIME_DIR="/run/user/1000" \ systemd-run --user --slice=app.slice -- \ xterm Instead of tricks with setting proper context for a process executed system-wide, I would consider a process running in user sessions and listening for D-Bus events: So your idea would be stopping and starting channel play by dbus messages? I'm looking again with introspect, and I don't see anything like "stop" in kaffeine. $ dbus-monitor --system "type='signal',interface='org.freedesktop.login1.Manager',member='PrepareForSleep'" dbus-monitor: unable to enable new-style monitoring: org.freedesktop.DBus.Error.AccessDenied: "Rejected send message, 1 matched rules; type="method_call", sender=":1.1080" (uid=1000 pid=48803 comm="dbus-monitor --system type='signal',interface='org") interface="org.freedesktop.DBus.Monitoring" member="BecomeMonitor" error name="(unset)" requested_reply="0" destination="org.freedesktop.DBus" (bus)". Falling back to eavesdropping. signal time=1704679328.754948 sender=org.freedesktop.DBus -> destination=:1.1080 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired string ":1.1080" signal time=1704679441.870349 sender=:1.6 -> destination=(null destination) serial=3187 path=/org/freedesktop/login1; interface=org.freedesktop.login1.Manager; member=PrepareForSleep boolean true signal time=1704679448.065409 sender=:1.6 -> destination=(null destination) serial=3233 path=/org/freedesktop/login1; interface=org.freedesktop.login1.Manager; member=PrepareForSleep boolean false A tiny python script may be more convenient than dbus-monitor and similar tools. It seems too complex for me.
Re: Change suspend type from kde menu
Il 07/01/2024 06:44, Max Nikulin ha scritto: It seems neither su nor sudo add process to the user context (proper cgroup, XDG session), so attempts to talk to the systemd user session through D-Bus fail. setpriv --reuid 1000 --regid 1000 --init-groups --reset-env -- \ env XDG_RUNTIME_DIR="/run/user/1000" \ systemd-run --user --slice=app.slice -- \ xterm I have realized that earlier I forgot to add --user to systemd-run. To my surprise, it does not work if I set BUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus" instead of XDG_RUNTIME_DIR. I expected that the former is required for systemd-run. This command works from a root shell prompt, I hope it should work during resume as well. It works :-) setpriv --reuid="$kafuid" --regid="$kafgid" --init-groups --reset-env \ env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis XDG_CURRENT_DESKTOP=KDE \ systemd-run --user --slice=app.slice /usr/bin/kaffeine --lastchannel > /dev/null 2>&1 Even during resume it goes into right slice.
Re: Change suspend type from kde menu
Il 06/01/2024 17:38, Max Nikulin ha scritto: On 06/01/2024 00:07, Valerio Vanni wrote: Now I'm looking: services are ├─/MainApplication ├─/Player ├─/Television ├─/TrackList └─/org └─/org/kde └─/org/kde/kaffeine I tried to introspect the more likely, MainApplication and Television .RemoveProgram method u - - Do you have any idea what it should do? I would expect something like "Stop" either from /Player or from org.mpris.kaffeine. I too expected something similar: stop and play (play for resume) If it's started with "-lastchannel" no, you have to close it. But then you have also to request it to play again. Is there an action that releases the device? "ls -l /proc/PID/fd" to check. What should I find here? If no file descriptor is resolved to /dev/ (or maybe /sys) then likely the kernel module may be removed without killing the application. For this we don't need to look here: "rmmod: ERROR: Module cx23885 is in use" seems enough to see that kernel module cannot be removed. Compare opened file descriptors when video is playing and when it is stopped. Started with --lastchannel Video playing: lr-x-- 1 valerio valerio 64 9 gen 19.47 0 -> /dev/null lrwx-- 1 valerio valerio 64 9 gen 19.47 34 -> /dev/dvb/adapter0/frontend0 lr-x-- 1 valerio valerio 64 9 gen 19.47 35 -> /dev/dvb/adapter0/dvr0 lr-x-- 1 valerio valerio 64 9 gen 19.47 40 -> /dev/dvb/adapter0/demux0 lr-x-- 1 valerio valerio 64 9 gen 19.47 41 -> /dev/dvb/adapter0/demux0 lr-x-- 1 valerio valerio 64 9 gen 19.47 42 -> /dev/dvb/adapter0/demux0 lr-x-- 1 valerio valerio 64 9 gen 19.47 43 -> /dev/dvb/adapter0/demux0 lr-x-- 1 valerio valerio 64 9 gen 19.47 44 -> /dev/dvb/adapter0/demux0 lrwx-- 1 valerio valerio 64 9 gen 19.47 55 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.47 56 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.47 57 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.47 59 -> /dev/dri/renderD128 lrwx-- 1 valerio valerio 64 9 gen 19.47 6 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.47 7 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.47 8 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.47 9 -> /dev/dri/card0 Video stopped: lrwx-- 1 valerio valerio 64 9 gen 19.51 6 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.51 62 -> /dev/dri/renderD128 lrwx-- 1 valerio valerio 64 9 gen 19.51 7 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.51 8 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.51 9 -> /dev/dri/card0 no more /dev/dvb/, but still unable to remove module cx23885 Started without --lastchannel Video playing: lrwx-- 1 valerio valerio 64 9 gen 19.56 37 -> /dev/dvb/adapter0/frontend0 lr-x-- 1 valerio valerio 64 9 gen 19.56 43 -> /dev/dvb/adapter0/dvr0 lr-x-- 1 valerio valerio 64 9 gen 19.56 47 -> /dev/dvb/adapter0/demux0 lr-x-- 1 valerio valerio 64 9 gen 19.56 49 -> /dev/dvb/adapter0/demux0 lr-x-- 1 valerio valerio 64 9 gen 19.56 50 -> /dev/dvb/adapter0/demux0 lr-x-- 1 valerio valerio 64 9 gen 19.56 51 -> /dev/dvb/adapter0/demux0 lr-x-- 1 valerio valerio 64 9 gen 19.56 52 -> /dev/dvb/adapter0/demux0 lrwx-- 1 valerio valerio 64 9 gen 19.56 58 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.56 59 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.56 6 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.56 60 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.56 62 -> /dev/dri/renderD128 lrwx-- 1 valerio valerio 64 9 gen 19.56 7 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.56 8 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.56 9 -> /dev/dri/card0 Video stopped: lrwx-- 1 valerio valerio 64 9 gen 19.56 6 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.56 62 -> /dev/dri/renderD128 lrwx-- 1 valerio valerio 64 9 gen 19.56 7 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.56 8 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.56 9 -> /dev/dri/card0 It all seems like before, but this time module can be removed.
Re: Change suspend type from kde menu
Il 06/01/2024 16:19, Max Nikulin ha scritto: On 06/01/2024 19:44, Valerio Vanni wrote: systemd-run --unit=kaffeine-resumed --uid="$kafuid" --gid="$kafgid" \ env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis XDG_CURRENT_DESKTOP=KDE \ /usr/bin/kaffeine --lastchannel > /dev/null 2>&1 I have not figured out how to do it, but systemd-run should not use --uid since this way it makes the application a part of system.slice. Instead the application should be in app.slice that is a child of user@1000.service. Inspect output of systemd-cgls. I confirm, it's under system.slice. So systemd-run should talk to the systemd --user instance. I have tried to set XDG_RUNTIME_DIR="/run/user/1000" BUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus" in setpriv ... env, but systemd requires authentication. I don't see authentication requests, but it still stays under system.slice.
Re: Change suspend type from kde menu
On 07/01/2024 12:44, Max Nikulin wrote: setpriv --reuid 1000 --regid 1000 --init-groups --reset-env -- \ env XDG_RUNTIME_DIR="/run/user/1000" \ systemd-run --user --slice=app.slice -- \ xterm Instead of tricks with setting proper context for a process executed system-wide, I would consider a process running in user sessions and listening for D-Bus events: $ dbus-monitor --system "type='signal',interface='org.freedesktop.login1.Manager',member='PrepareForSleep'" dbus-monitor: unable to enable new-style monitoring: org.freedesktop.DBus.Error.AccessDenied: "Rejected send message, 1 matched rules; type="method_call", sender=":1.1080" (uid=1000 pid=48803 comm="dbus-monitor --system type='signal',interface='org") interface="org.freedesktop.DBus.Monitoring" member="BecomeMonitor" error name="(unset)" requested_reply="0" destination="org.freedesktop.DBus" (bus)". Falling back to eavesdropping. signal time=1704679328.754948 sender=org.freedesktop.DBus -> destination=:1.1080 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired string ":1.1080" signal time=1704679441.870349 sender=:1.6 -> destination=(null destination) serial=3187 path=/org/freedesktop/login1; interface=org.freedesktop.login1.Manager; member=PrepareForSleep boolean true signal time=1704679448.065409 sender=:1.6 -> destination=(null destination) serial=3233 path=/org/freedesktop/login1; interface=org.freedesktop.login1.Manager; member=PrepareForSleep boolean false A tiny python script may be more convenient than dbus-monitor and similar tools.
Re: Change suspend type from kde menu
On 06/01/2024 22:19, Max Nikulin wrote: On 06/01/2024 19:44, Valerio Vanni wrote: systemd-run --unit=kaffeine-resumed --uid="$kafuid" --gid="$kafgid" \ env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis XDG_CURRENT_DESKTOP=KDE \ /usr/bin/kaffeine --lastchannel > /dev/null 2>&1 Instead the application should be in app.slice that is a child of user@1000.service. Inspect output of systemd-cgls. It seems neither su nor sudo add process to the user context (proper cgroup, XDG session), so attempts to talk to the systemd user session through D-Bus fail. setpriv --reuid 1000 --regid 1000 --init-groups --reset-env -- \ env XDG_RUNTIME_DIR="/run/user/1000" \ systemd-run --user --slice=app.slice -- \ xterm I have realized that earlier I forgot to add --user to systemd-run. To my surprise, it does not work if I set BUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus" instead of XDG_RUNTIME_DIR. I expected that the former is required for systemd-run. This command works from a root shell prompt, I hope it should work during resume as well.
Re: Change suspend type from kde menu
On 06/01/2024 00:07, Valerio Vanni wrote: Now I'm looking: services are ├─/MainApplication ├─/Player ├─/Television ├─/TrackList └─/org └─/org/kde └─/org/kde/kaffeine I tried to introspect the more likely, MainApplication and Television .RemoveProgram method u - - Do you have any idea what it should do? I would expect something like "Stop" either from /Player or from org.mpris.kaffeine. I have not tried MPRIS D-Bus interface in action though. If it's started with "-lastchannel" no, you have to close it. But then you have also to request it to play again. Is there an action that releases the device? "ls -l /proc/PID/fd" to check. What should I find here? If no file descriptor is resolved to /dev/ (or maybe /sys) then likely the kernel module may be removed without killing the application. Compare opened file descriptors when video is playing and when it is stopped.
Re: Change suspend type from kde menu
On 06/01/2024 19:44, Valerio Vanni wrote: systemd-run --unit=kaffeine-resumed --uid="$kafuid" --gid="$kafgid" \ env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis XDG_CURRENT_DESKTOP=KDE \ /usr/bin/kaffeine --lastchannel > /dev/null 2>&1 I have not figured out how to do it, but systemd-run should not use --uid since this way it makes the application a part of system.slice. Instead the application should be in app.slice that is a child of user@1000.service. Inspect output of systemd-cgls. So systemd-run should talk to the systemd --user instance. I have tried to set XDG_RUNTIME_DIR="/run/user/1000" BUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus" in setpriv ... env, but systemd requires authentication. It seems neither su nor sudo add process to the user context (proper cgroup, XDG session), so attempts to talk to the systemd user session through D-Bus fail. I tried command from a ssh session root@... Behavior may be different from suspend/resume tasks since the session is associated with a pty.
Re: Change suspend type from kde menu
Il 06/01/2024 01:04, Greg Wooledge ha scritto: On Fri, Jan 05, 2024 at 11:37:41PM +0100, Valerio Vanni wrote: This way works, I don't know if it has security flaws. systemd-run --unit=kaffeine-resumed setpriv --reuid "$kafuid" --regid "$kafgid" --init-groups --reset-env \ env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis XDG_CURRENT_DESKTOP=KDE \ /usr/bin/kaffeine --lastchannel > /dev/null 2>&1 systemd-run(1) appears to have its own --uid and --gid options. If you can live without supplementary groups and the variables that are set by --reset-env, you can probably drop the setpriv part and just use systemd-run's --uid and --gid. On the other hand, if it ain't broke I tried the options when I tried systemd-run, but it didn't work. I only added them, but now I see that you have to choose: or them or setpriv. Now it's: systemd-run --unit=kaffeine-resumed --uid="$kafuid" --gid="$kafgid" \ env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis XDG_CURRENT_DESKTOP=KDE \ /usr/bin/kaffeine --lastchannel > /dev/null 2>&1 Outcome is the same. The only difference is that a line is added to syslog about unit creation: Started kaffeine-resumed.service - /usr/bin/env XDG_RUNTIME_DIR=/run/user/1000 DISPLAY=:0 XDG_CURRENT_DESKTOP=KDE /usr/bin/kaffeine --lastchannel.
Re: Change suspend type from kde menu
On Fri, Jan 05, 2024 at 11:37:41PM +0100, Valerio Vanni wrote: > This way works, I don't know if it has security flaws. > > systemd-run --unit=kaffeine-resumed setpriv --reuid "$kafuid" --regid > "$kafgid" --init-groups --reset-env \ > env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis > XDG_CURRENT_DESKTOP=KDE \ > /usr/bin/kaffeine --lastchannel > /dev/null 2>&1 > systemd-run(1) appears to have its own --uid and --gid options. If you can live without supplementary groups and the variables that are set by --reset-env, you can probably drop the setpriv part and just use systemd-run's --uid and --gid. On the other hand, if it ain't broke
Re: Change suspend type from kde menu
Il 05/01/2024 21:47, Valerio Vanni ha scritto: Il 05/01/2024 21:24, Valerio Vanni ha scritto: For what I've seen, the issue is that kaffeine is started in another unit, systemd-suspend.service instead of user@1000.service. systemd-suspend.service is deactivated after 90 seconds from resume, and kaffeine is shut down some msec before. If I use "su" method instead of "setpriv" one, kaffeine doesn't go into systemd-suspend.service unit, and neither to user@1000.service one. Instead, it goes to session-c2.scope. And works. And systemd-suspend.service is finished and deactivated at the moment of resume. It seems that systemd-suspend.service wants to end as soon as possible, but it cannot because it has kaffeine inside. So it waits 90 seconds, and then terminates kaffeine. This way works, I don't know if it has security flaws. systemd-run --unit=kaffeine-resumed setpriv --reuid "$kafuid" --regid "$kafgid" --init-groups --reset-env \ env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis XDG_CURRENT_DESKTOP=KDE \ /usr/bin/kaffeine --lastchannel > /dev/null 2>&1 All is launched from systemd-run. I choosed kaffeine-resumed as unit name, but if you don't put any a casual name one is created. So systemd-suspend.service unit is free and can close.
Re: Change suspend type from kde menu
Il 05/01/2024 21:24, Valerio Vanni ha scritto: For what I've seen, the issue is that kaffeine is started in another unit, systemd-suspend.service instead of user@1000.service. systemd-suspend.service is deactivated after 90 seconds from resume, and kaffeine is shut down some msec before. And I found now that whole script cannot continue after this "takeover": final "rm" commands are not run. - 2024-01-05T19:39:20.40+01:00 newton kded5[14911]: Service ":1.299" unregistered 2024-01-05T19:39:20.491999+01:00 newton ksmserver[16627]: org.kde.kmix: Could not get icon for "audio-card-analog-pci" 2024-01-05T19:39:20.494975+01:00 newton kwin_x11[14912]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 18596, resource id: 134217740, major code: 15 (QueryTree), minor code: 0 2024-01-05T19:39:20.501014+01:00 newton systemd[1]: systemd-suspend.service: Deactivated successfully. 2024-01-05T19:39:20.501146+01:00 newton systemd[1]: Finished systemd-suspend.service - System Suspend. 2024-01-05T19:39:20.501227+01:00 newton systemd[1]: systemd-suspend.service: Consumed 1min 10.023s CPU time. 2024-01-05T19:39:20.501296+01:00 newton systemd[1]: Stopped target sleep.target - Sleep. 2024-01-05T19:39:20.501404+01:00 newton systemd[1]: Reached target suspend.target - Suspend. 2024-01-05T19:39:20.501662+01:00 newton systemd[1]: Stopped target suspend.target - Suspend. If I use "su" method instead of "setpriv" one, kaffeine doesn't go into systemd-suspend.service unit, and neither to user@1000.service one. Instead, it goes to session-c2.scope. And works. And systemd-suspend.service is finished and deactivated at the moment of resume. It seems that systemd-suspend.service wants to end as soon as possible, but it cannot because it has kaffeine inside. So it waits 90 seconds, and then terminates kaffeine.
Re: Change suspend type from kde menu
Il 05/01/2024 20:47, Franco Martelli ha scritto: On 05/01/24 at 20:01, Greg Wooledge wrote: On Fri, Jan 05, 2024 at 05:52:43PM +0100, Valerio Vanni wrote: setpriv --reuid "$kafuid" --regid "$kafgid" --init-groups --reset-env \ env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis XDG_CURRENT_DESKTOP=KDE \ /usr/bin/kaffeine --lastchannel >/dev/null 2>&1 Adding the parameter --reset-env seems to fix, kaffeine restarts. But, after some minutes, it closes. I don't understand why. My first guess would be that you also need $HOME to be set, or perhaps the current working directory, or both. --reset-env sets HOME, SHELL, USER, LOGNAME and PATH. That seems like a reasonable addition. I have no idea why it crashes later. Could it be that he doesn't run Kaffeine in the background? ... /usr/bin/kaffeine --lastchannel >/dev/null 2>&1 & If I add that final &, kaffeine doesn't start at all. For what I've seen, the issue is that kaffeine is started in another unit, systemd-suspend.service instead of user@1000.service. systemd-suspend.service is deactivated after 90 seconds from resume, and kaffeine is shut down some msec before. And I found now that whole script cannot continue after this "takeover": final "rm" commands are not run. - 2024-01-05T19:39:20.40+01:00 newton kded5[14911]: Service ":1.299" unregistered 2024-01-05T19:39:20.491999+01:00 newton ksmserver[16627]: org.kde.kmix: Could not get icon for "audio-card-analog-pci" 2024-01-05T19:39:20.494975+01:00 newton kwin_x11[14912]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 18596, resource id: 134217740, major code: 15 (QueryTree), minor code: 0 2024-01-05T19:39:20.501014+01:00 newton systemd[1]: systemd-suspend.service: Deactivated successfully. 2024-01-05T19:39:20.501146+01:00 newton systemd[1]: Finished systemd-suspend.service - System Suspend. 2024-01-05T19:39:20.501227+01:00 newton systemd[1]: systemd-suspend.service: Consumed 1min 10.023s CPU time. 2024-01-05T19:39:20.501296+01:00 newton systemd[1]: Stopped target sleep.target - Sleep. 2024-01-05T19:39:20.501404+01:00 newton systemd[1]: Reached target suspend.target - Suspend. 2024-01-05T19:39:20.501662+01:00 newton systemd[1]: Stopped target suspend.target - Suspend.
Re: Change suspend type from kde menu
On 05/01/24 at 20:01, Greg Wooledge wrote: On Fri, Jan 05, 2024 at 05:52:43PM +0100, Valerio Vanni wrote: setpriv --reuid "$kafuid" --regid "$kafgid" --init-groups --reset-env \ env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis XDG_CURRENT_DESKTOP=KDE \ /usr/bin/kaffeine --lastchannel >/dev/null 2>&1 - Uid, gid and display are saved and restored, so it can works also for other users and x servers. But with setpriv kaffeine was complaining it couldn't find .config/, database etc and so it wasn't able to start. It seems that was ignorming original user's home and tried to access root home. Adding the parameter --reset-env seems to fix, kaffeine restarts. But, after some minutes, it closes. I don't understand why. My first guess would be that you also need $HOME to be set, or perhaps the current working directory, or both. --reset-env sets HOME, SHELL, USER, LOGNAME and PATH. That seems like a reasonable addition. I have no idea why it crashes later. Could it be that he doesn't run Kaffeine in the background? ... /usr/bin/kaffeine --lastchannel >/dev/null 2>&1 & ^ Cheers, -- Franco Martelli
Re: Change suspend type from kde menu
Il 05/01/2024 20:10, Valerio Vanni ha scritto: My first guess would be that you also need $HOME to be set, or perhaps the current working directory, or both. --reset-env sets HOME, SHELL, USER, LOGNAME and PATH. That seems like a reasonable addition. I have no idea why it crashes later. If you see my latest message, it goes in a different unit and is shut down at the end of resume. Perhaps I could try to remove --reset-env and set some parameter by hand If I remove --reset-env and set HOME, kaffeine starts. It seems that issue was to find file in home directory. But still in systemd-suspend.service unit. If, in a root shell, I launch setpriv --reuid 1000 --regid 1000 --init-groups \ env XDG_RUNTIME_DIR=/run/user/1000 DISPLAY=:0 HOME=/home/valerio XDG_CURRENT_DESKTOP=KDE \ /usr/bin/kaffeine --lastchannel > /home/valerio/kaffeine_log_resumed 2>&1 kaffeine starts in user@1000.service. Also with --reset-env. It's only during resume that it gets into systemd-suspend.service.
Re: Change suspend type from kde menu
Il 05/01/2024 20:01, Greg Wooledge ha scritto: On Fri, Jan 05, 2024 at 05:52:43PM +0100, Valerio Vanni wrote: setpriv --reuid "$kafuid" --regid "$kafgid" --init-groups --reset-env \ env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis XDG_CURRENT_DESKTOP=KDE \ /usr/bin/kaffeine --lastchannel >/dev/null 2>&1 - Uid, gid and display are saved and restored, so it can works also for other users and x servers. But with setpriv kaffeine was complaining it couldn't find .config/, database etc and so it wasn't able to start. It seems that was ignorming original user's home and tried to access root home. Adding the parameter --reset-env seems to fix, kaffeine restarts. But, after some minutes, it closes. I don't understand why. My first guess would be that you also need $HOME to be set, or perhaps the current working directory, or both. --reset-env sets HOME, SHELL, USER, LOGNAME and PATH. That seems like a reasonable addition. I have no idea why it crashes later. If you see my latest message, it goes in a different unit and is shut down at the end of resume. Perhaps I could try to remove --reset-env and set some parameter by hand
Re: Change suspend type from kde menu
On Fri, Jan 05, 2024 at 05:52:43PM +0100, Valerio Vanni wrote: > setpriv --reuid "$kafuid" --regid "$kafgid" --init-groups > --reset-env \ > env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis > XDG_CURRENT_DESKTOP=KDE \ > /usr/bin/kaffeine --lastchannel >/dev/null 2>&1 > - > Uid, gid and display are saved and restored, so it can works also for other > users and x servers. > But with setpriv kaffeine was complaining it couldn't find .config/, > database etc and so it wasn't able to start. It seems that was ignorming > original user's home and tried to access root home. > > Adding the parameter --reset-env seems to fix, kaffeine restarts. > But, after some minutes, it closes. I don't understand why. My first guess would be that you also need $HOME to be set, or perhaps the current working directory, or both. --reset-env sets HOME, SHELL, USER, LOGNAME and PATH. That seems like a reasonable addition. I have no idea why it crashes later.
Re: Change suspend type from kde menu
Il 05/01/2024 17:52, Valerio Vanni ha scritto: Adding the parameter --reset-env seems to fix, kaffeine restarts. But, after some minutes, it closes. I don't understand why. -Kaffeine launched by hand stays up -Kaffeine restored with "su" method stays up -Kaffeine restored with "setpriv" method lasts only some minute I looked better: it lasts 90 seconds. Not from kaffeine launch, from PC resume. If I try to set a delay inside the script, so that kaffeine launches after 80 seconds, it starts and then after 10 seconds it's closed. If I set the delay after 90 seconds, it doesn't start at all. I tried to redirect output to a file /usr/bin/kaffeine --lastchannel > /home/valerio/kaffeine_log_resumed 2>&1 The file is created and gets data, but nothing is added at the moment of termination. In syslog I found these lines at that moment: - 2024-01-05T19:39:20.40+01:00 newton kded5[14911]: Service ":1.299" unregistered 2024-01-05T19:39:20.491999+01:00 newton ksmserver[16627]: org.kde.kmix: Could not get icon for "audio-card-analog-pci" 2024-01-05T19:39:20.494975+01:00 newton kwin_x11[14912]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 18596, resource id: 134217740, major code: 15 (QueryTree), minor code: 0 2024-01-05T19:39:20.501014+01:00 newton systemd[1]: systemd-suspend.service: Deactivated successfully. 2024-01-05T19:39:20.501146+01:00 newton systemd[1]: Finished systemd-suspend.service - System Suspend. 2024-01-05T19:39:20.501227+01:00 newton systemd[1]: systemd-suspend.service: Consumed 1min 10.023s CPU time. 2024-01-05T19:39:20.501296+01:00 newton systemd[1]: Stopped target sleep.target - Sleep. 2024-01-05T19:39:20.501404+01:00 newton systemd[1]: Reached target suspend.target - Suspend. 2024-01-05T19:39:20.501662+01:00 newton systemd[1]: Stopped target suspend.target - Suspend. 2024-01-05T19:39:20.505334+01:00 newton NetworkManager[3208]: [1704479960.5049] manager: sleep: wake requested (sleeping: yes enabled: yes) 2024-01-05T19:39:20.505722+01:00 newton ModemManager[3206]: [sleep-monitor-systemd] system is resuming -- It seems that something of resume process is ending 90 seconds after resume. And Service ":1.299" that gets unregistered is just kaffeine. And now I see a difference between kaffeine launched by hand and resumed one: busctl --user | grep kaffeine with manual start -- :1.30544374 kaffeinevalerio :1.305user@1000.service - - :1.30644374 kaffeinevalerio :1.306user@1000.service - - :1.30744374 kaffeinevalerio :1.307user@1000.service - - org.kde.kaffeine 44374 kaffeinevalerio :1.305user@1000.service - - org.mpris.kaffeine44374 kaffeinevalerio :1.305user@1000.service - - -- after resume -- 1.31245857 kaffeinevalerio :1.312systemd-suspend.service - - :1.31345857 kaffeinevalerio :1.313systemd-suspend.service - - :1.31445857 kaffeinevalerio :1.314systemd-suspend.service - - org.kde.kaffeine 45857 kaffeinevalerio :1.312systemd-suspend.service - - org.mpris.kaffeine45857 kaffeinevalerio :1.312systemd-suspend.service - - --
Re: Change suspend type from kde menu
Il 04/01/2024 17:11, Max Nikulin ha scritto:
On 04/01/2024 22:21, Valerio Vanni wrote:
Il 04/01/2024 15:48, Max Nikulin ha scritto:
Is it really necessary to kill kaffeine or it is enough to pause or
to stop playing? It might be possible using a D-Bus query.
[...]
If it's started normally, it's enough to stop playing
But how would you try to request it to stop?
I would play with "busctl --user", "busctl --user tree SERVICE", "busctl
--user introspect SERVICE OBJECT" to figure out if suitable methods are
available.
I never used busctl.
Now I'm looking: services are
├─/MainApplication
├─/Player
├─/Television
├─/TrackList
└─/org
└─/org/kde
└─/org/kde/kaffeine
I tried to introspect the more likely, MainApplication and Television
/MainApplication
AMETYPE SIGNATURE RESULT/VALUE
FL>
org.freedesktop.DBus.Introspectable interface - - -
.Introspect method- s -
org.freedesktop.DBus.Peer interface - - -
.GetMachineId method- s -
.Ping method- - -
org.freedesktop.DBus.Properties interface - - -
.Getmethodssv -
.GetAll methods a{sv} -
.Setmethodssv - -
.PropertiesChanged signalsa{sv}as - -
org.qtproject.Qt.QApplication interface - - -
.aboutQtmethod- - -
.autoSipEnabled method- b -
.closeAllWindowsmethod- - -
.setAutoSipEnabled methodb - -
.setStyleSheet methods - -
lines 1-17
/Television
AMETYPE SIGNATURE RESULT/VALUE FLAGS
org.freedesktop.DBus.Introspectable interface - --
.Introspect method- s-
org.freedesktop.DBus.Peer interface - --
.GetMachineId method- s-
.Ping method- --
org.freedesktop.DBus.Properties interface - --
.Getmethodssv-
.GetAll methods a{sv}-
.Setmethodssv --
.PropertiesChanged signalsa{sv}as --
org.freedesktop.MediaPlayer interface - --
.DigitPressed methodi --
.ListProgramSchedulemethod- a(uib) -
.PlayChannelmethods --
.PlayLastChannelmethod- --
.RemoveProgram methodu --
If it's started with "-lastchannel" no, you have to close it.
But then you have also to request it to play again.
Is there an action that releases the device? "ls -l /proc/PID/fd" to check.
What should I find here?
Ideally kaffeine should implement the Inhibit interface and should close
devices on suspend or on user session switch.
Ideally...
Re: Change suspend type from kde menu
Il 04/01/2024 16:27, Greg Wooledge ha scritto: On Thu, Jan 04, 2024 at 03:07:59PM +0100, Valerio Vanni wrote: Il 03/01/2024 17:41, Greg Wooledge ha scritto: The su command is not an ideal choice for this, in fact. The setpriv(1) command is better suited for running programs as other user accounts, without doing crazy PAM stuff like su does. Can you explain better? http://jdebp.info/FGA/dont-abuse-su-for-dropping-privileges.html Thank you. Now I'm trying this way: - #!/bin/bash case "$1" in pre) #code execution BEFORE sleeping/hibernating/suspending kafpid=$(pgrep kaffeine) kafuid=$(stat -c "%u" /proc/$kafpid) kafgid=$(stat -c "%g" /proc/$kafpid) kafdis=$(cat /proc/$kafpid/environ | tr '\0' '\n' | grep DISPLAY) echo $kafuid > /temp/kafuid.txt echo $kafgid > /temp/kafgid.txt echo $kafdis > /temp/kafdis.txt kaffeine_killed=$(/usr/bin/killall kaffeine 2>&1) echo $kaffeine_killed > /temp/kafstate.txt /usr/bin/sleep 2 /usr/sbin/rmmod cx23885 ;; post) #code execution AFTER resuming /usr/sbin/modprobe cx23885 /usr/bin/sleep 3 kaffeine_killed=$(cat /temp/kafstate.txt) kafuid=$(cat /temp/kafuid.txt) kafgid=$(cat /temp/kafgid.txt) kafdis=$(cat /temp/kafdis.txt) if [[ $kaffeine_killed == "" ]]; then setpriv --reuid "$kafuid" --regid "$kafgid" --init-groups --reset-env \ env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis XDG_CURRENT_DESKTOP=KDE \ /usr/bin/kaffeine --lastchannel >/dev/null 2>&1 fi rm -f /temp/kafstate.txt rm -f /temp/kafuid.txt rm -f /temp/kafgid.txt rm -f /temp/kafdis.txt ;; esac - Uid, gid and display are saved and restored, so it can works also for other users and x servers. But with setpriv kaffeine was complaining it couldn't find .config/, database etc and so it wasn't able to start. It seems that was ignorming original user's home and tried to access root home. Adding the parameter --reset-env seems to fix, kaffeine restarts. But, after some minutes, it closes. I don't understand why. -Kaffeine launched by hand stays up -Kaffeine restored with "su" method stays up -Kaffeine restored with "setpriv" method lasts only some minute
Re: Change suspend type from kde menu
On 04/01/2024 22:21, Valerio Vanni wrote: Il 04/01/2024 15:48, Max Nikulin ha scritto: Is it really necessary to kill kaffeine or it is enough to pause or to stop playing? It might be possible using a D-Bus query. [...] If it's started normally, it's enough to stop playing But how would you try to request it to stop? I would play with "busctl --user", "busctl --user tree SERVICE", "busctl --user introspect SERVICE OBJECT" to figure out if suitable methods are available. If it's started with "-lastchannel" no, you have to close it. But then you have also to request it to play again. Is there an action that releases the device? "ls -l /proc/PID/fd" to check. Ideally kaffeine should implement the Inhibit interface and should close devices on suspend or on user session switch.
Re: Change suspend type from kde menu
On Thu, Jan 04, 2024 at 03:07:59PM +0100, Valerio Vanni wrote: > Il 03/01/2024 17:41, Greg Wooledge ha scritto: > > The su command is not an ideal choice for this, in fact. The setpriv(1) > > command is better suited for running programs as other user accounts, > > without doing crazy PAM stuff like su does. > > Can you explain better? http://jdebp.info/FGA/dont-abuse-su-for-dropping-privileges.html
Re: Change suspend type from kde menu
Il 04/01/2024 15:48, Max Nikulin ha scritto: On 04/01/2024 21:03, Valerio Vanni wrote: kaffeine_killed=$(/usr/bin/killall kaffeine 2>&1) echo $kaffeine_killed > /temp/kafstate.txt /usr/bin/sleep 2 /usr/sbin/rmmod cx23885 Is it really necessary to kill kaffeine or it is enough to pause or to stop playing? It might be possible using a D-Bus query. My expectation is that the device should be closed. I choosed to kill it because it seemed easier. If it's started normally, it's enough to stop playing But how would you try to request it to stop? If it's started with "-lastchannel" no, you have to close it. But then you have also to request it to play again.
Re: Change suspend type from kde menu
On 04/01/2024 21:03, Valerio Vanni wrote: kaffeine_killed=$(/usr/bin/killall kaffeine 2>&1) echo $kaffeine_killed > /temp/kafstate.txt /usr/bin/sleep 2 /usr/sbin/rmmod cx23885 Is it really necessary to kill kaffeine or it is enough to pause or to stop playing? It might be possible using a D-Bus query. My expectation is that the device should be closed.
Re: Change suspend type from kde menu
Il 03/01/2024 17:41, Greg Wooledge ha scritto: The UID of 1000 will have to be verified, as well as the YOURUSER. UID 1000 is what Debian uses for the initial user account that's created during installation, but if for some reason that's not the account who's currently logged in, then obviously this won't work. In my case it's ok The su command is not an ideal choice for this, in fact. The setpriv(1) command is better suited for running programs as other user accounts, without doing crazy PAM stuff like su does. Can you explain better? It also has the advantage of not needing a username -- it can work with just the UID. uid=1000 gid=1000 setpriv --reuid "$uid" --regid "$gid" --init-groups \ env XDG_RUNTIME_DIR=/run/user/"$uid" DISPLAY=:0 XDG_CURRENT_DESKTOP=KDE \ keffeine >/dev/null 2>&1 & In a (used like a) single user system like this, I know both username and uid. In a multi-user one, you have to find them. And it doesn't seem simple.
Re: Change suspend type from kde menu
Il 03/01/2024 23:52, Valerio Vanni ha scritto: Il 03/01/2024 17:18, Franco Martelli ha scritto: On 02/01/24 at 19:15, Valerio Vanni wrote: This way, I don't have to remember to close kaffeine before suspend. If you have Kaffeine always running on your system you can try this script: I had an idea to do a relaunch, but it's not always running. Now I've done this, to relaunch only if it was running: -- #!/bin/bash case "$1" in pre) #code execution BEFORE sleeping/hibernating/suspending kaffeine_killed=$(/usr/bin/killall kaffeine 2>&1) echo $kaffeine_killed > /temp/kafstate.txt /usr/bin/sleep 2 /usr/sbin/rmmod cx23885 ;; post) #code execution AFTER resuming /usr/sbin/modprobe cx23885 /usr/bin/sleep 3 kaffeine_killed=$(cat /temp/kafstate.txt) if [[ $kaffeine_killed == "" ]]; then /usr/bin/su valerio -c 'XDG_RUNTIME_DIR=/run/user/1000 DISPLAY=:0 XDG_CURRENT_DESKTOP=KDE /usr/bin/kaffeine --lastchannel >/dev/null 2>&1 &' fi rm -f /temp/kafstate.txt ;; esac --
Re: Change suspend type from kde menu
Il 03/01/2024 17:18, Franco Martelli ha scritto: On 02/01/24 at 19:15, Valerio Vanni wrote: This way, I don't have to remember to close kaffeine before suspend. If you have Kaffeine always running on your system you can try this script: I had an idea to do a relaunch, but it's not always running. In the end don't put your script in /usr/sbin or /usr/bin use /usr/local/bin or /usr/local/sbin instead. I'll do :-)
Re: Change suspend type from kde menu
Am 03.01.2024 um 17:41 schrieb Greg Wooledge:
...
Bear in mind that this entire approach is a bit of a hack, with some
baked-in assumptions about who's logged in on which DISPLAY. If this
works for you, then that's great.
Manually restarting whatever application was affected would be simpler,
but...
But some people might need to extend
this to check for the actual logged-in account, rather than assuming it's
the primary user. (Left as an exercise, because unfortunately there is
no good way to do that, as far as I know anyway.)
I would start with something like
w | awk -e '$3==":0" { print $1 }'
A cleaner approach would be to record what was killed in the pre-suspend
phase and recreate that post wakeup, in my opinion.
Cheers,
Arno
--
Arno Lehmann
IT-Service Lehmann
Sandstr. 6, 49080 Osnabrück
Re: Change suspend type from kde menu
On Wed, Jan 03, 2024 at 05:18:19PM +0100, Franco Martelli wrote: > /usr/bin/su YOURUSER -c 'XDG_RUNTIME_DIR=/run/user/1000 > DISPLAY=:0 XDG_CURRENT_DESKTOP=KDE /usr/bin/kaffeine >/dev/null 2>&1 &' > In place of YOURUSER you've to put your username, if you doubt the command > "whoami" will tell you. Check if XDG_RUNTIME_DIR, XDG_CURRENT_DESKTOP and > DISPLAY have the same value that I set, use the command "echo $variableName" > to verify. The UID of 1000 will have to be verified, as well as the YOURUSER. UID 1000 is what Debian uses for the initial user account that's created during installation, but if for some reason that's not the account who's currently logged in, then obviously this won't work. The su command is not an ideal choice for this, in fact. The setpriv(1) command is better suited for running programs as other user accounts, without doing crazy PAM stuff like su does. It also has the advantage of not needing a username -- it can work with just the UID. uid=1000 gid=1000 setpriv --reuid "$uid" --regid "$gid" --init-groups \ env XDG_RUNTIME_DIR=/run/user/"$uid" DISPLAY=:0 XDG_CURRENT_DESKTOP=KDE \ keffeine >/dev/null 2>&1 & Bear in mind that this entire approach is a bit of a hack, with some baked-in assumptions about who's logged in on which DISPLAY. If this works for you, then that's great. But some people might need to extend this to check for the actual logged-in account, rather than assuming it's the primary user. (Left as an exercise, because unfortunately there is no good way to do that, as far as I know anyway.)
Re: Change suspend type from kde menu
On 02/01/24 at 19:15, Valerio Vanni wrote: This way, I don't have to remember to close kaffeine before suspend. If you have Kaffeine always running on your system you can try this script: #!/bin/sh # Run from systemd-suspend.service to place under /usr/lib/systemd/system-sleep/ PATH=/sbin:/usr/sbin:/bin:/usr/bin case "$1" in pre) #code execution BEFORE sleeping/hibernating/suspending /usr/bin/killall kaffeine /usr/bin/sleep 2 /usr/sbin/rmmod cx23885 ;; post) #code execution AFTER resuming /usr/sbin/modprobe cx23885 /usr/bin/sleep 3 /usr/bin/su YOURUSER -c 'XDG_RUNTIME_DIR=/run/user/1000 DISPLAY=:0 XDG_CURRENT_DESKTOP=KDE /usr/bin/kaffeine >/dev/null 2>&1 &' /usr/bin/sleep 1 ;; esac exit 0 In place of YOURUSER you've to put your username, if you doubt the command "whoami" will tell you. Check if XDG_RUNTIME_DIR, XDG_CURRENT_DESKTOP and DISPLAY have the same value that I set, use the command "echo $variableName" to verify. In the end don't put your script in /usr/sbin or /usr/bin use /usr/local/bin or /usr/local/sbin instead. Cheers -- Franco Martelli
Re: Change suspend type from kde menu
Il 28/12/2023 23:17, Valerio Vanni ha scritto: I found that pm-suspend works because it unloads and reloades that module In "/etc/pm/config.d/modules" there is --- SUSPEND_MODULES="cx23885" --- Now I've replicated this on systemd side with this script similar to yours: /usr/lib/systemd/system-sleep/dvb-suspend.sh --- #!/bin/bash [ "$1" = "post" ] && exec /usr/sbin/modprobe cx23885 [ "$1" = "pre" ] && exec /usr/sbin/rmmod cx23885 exit 0 Now I've made a little change: #!/bin/bash [ "$1" = "post" ] && exec /usr/sbin/modprobe cx23885 [ "$1" = "pre" ] && exec /usr/sbin/tv-sleep exit 0 and tv-sleep does: #!/bin/bash /usr/bin/killall kaffeine sleep 2 /usr/sbin/rmmod cx23885 This way, I don't have to remember to close kaffeine before suspend. At this point, there's a couple of improvements from pm-suspend method. One is this, the other is that pm-suspend required sudo.
Re: Change suspend type from kde menu
Il 29/12/2023 02:53, Max Nikulin ha scritto: systemd-sleep(8) does not mention /etc/systemd/system-sleep/ I am a bit puzzled by the following: https://www.freedesktop.org/software/systemd/man/latest/systemd-sleep.html Note that scripts or binaries dropped in /usr/lib/systemd/system-sleep/ are intended for local use only and should be considered hacks. If applications want to react to system suspend/hibernation and resume, they should rather use the Inhibitor interface. https://www.freedesktop.org/wiki/Software/systemd/inhibit/ From my point of view dealing with D-Bus just to unload a kernel module is inconvenient. It is not an application that is started before suspend and should be running after resume. I am curious what is the recommended way for this particular use case. It seems to me something that should be done from an application. For example, in my case kaffeine could: stop dvb stream, unload module, and inverse actions after resume. But it wouldn't help: it would work only if kaffeine is open. This kernel module is unable to be suspended and resumed regardless of applications.
Re: Change suspend type from kde menu
On 29/12/2023 08:26, Valerio Vanni wrote: Il 29/12/2023 00:12, Charles Curley ha scritto: That may work, but by putting the script in /usr/lib/systemd, you run the risk of it being clobbered on the next update to systemd. Better to put it in /etc/systemd/system-sleep/. Files in /etc/systemd over-ride their analogs in /usr/lib/systemd, so it should continue to work. You may need to do a "systemctl daemon-reload". This way it doesn't work. systemd-sleep(8) does not mention /etc/systemd/system-sleep/ I am a bit puzzled by the following: https://www.freedesktop.org/software/systemd/man/latest/systemd-sleep.html Note that scripts or binaries dropped in /usr/lib/systemd/system-sleep/ are intended for local use only and should be considered hacks. If applications want to react to system suspend/hibernation and resume, they should rather use the Inhibitor interface. https://www.freedesktop.org/wiki/Software/systemd/inhibit/ From my point of view dealing with D-Bus just to unload a kernel module is inconvenient. It is not an application that is started before suspend and should be running after resume. I am curious what is the recommended way for this particular use case.
Re: Change suspend type from kde menu
Il 29/12/2023 00:12, Charles Curley ha scritto: On Thu, 28 Dec 2023 23:17:06 +0100 Valerio Vanni wrote: /usr/lib/systemd/system-sleep/dvb-suspend.sh That may work, but by putting the script in /usr/lib/systemd, you run the risk of it being clobbered on the next update to systemd. Better to put it in /etc/systemd/system-sleep/. Files in /etc/systemd over-ride their analogs in /usr/lib/systemd, so it should continue to work. You may need to do a "systemctl daemon-reload". This way it doesn't work. I don't have an /etc/systemd/system-sleep directory. I created it by hand, but scripts inside are ignored.
Re: Change suspend type from kde menu
On Thu, 28 Dec 2023 23:17:06 +0100 Valerio Vanni wrote: > /usr/lib/systemd/system-sleep/dvb-suspend.sh That may work, but by putting the script in /usr/lib/systemd, you run the risk of it being clobbered on the next update to systemd. Better to put it in /etc/systemd/system-sleep/. Files in /etc/systemd over-ride their analogs in /usr/lib/systemd, so it should continue to work. You may need to do a "systemctl daemon-reload". -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: Change suspend type from kde menu
Il 28/12/2023 15:48, Franco Martelli ha scritto: Using systemctl, kernel module is broken after every suspend, even if kaffeine is not running. My system, if I don't restart Picom, freeze after a resume from suspend. To fix it I've placed this shell script in "/usr/lib/systemd/system-sleep/" directory ~$ cat /usr/lib/systemd/system-sleep/00_sleep.sh I found that pm-suspend works because it unloads and reloades that module In "/etc/pm/config.d/modules" there is --- SUSPEND_MODULES="cx23885" --- Now I've replicated this on systemd side with this script similar to yours: /usr/lib/systemd/system-sleep/dvb-suspend.sh --- #!/bin/bash [ "$1" = "post" ] && exec /usr/sbin/modprobe cx23885 [ "$1" = "pre" ] && exec /usr/sbin/rmmod cx23885 exit 0 --- This way it works, both with "systemctl suspend" and from kde menu.
Re: Change suspend type from kde menu
On 27/12/23 at 21:54, Valerio Vanni wrote: Il 25/12/2023 04:25, Valerio Vanni ha scritto: Is there any way to change the way system is suspended from kde menu and from power saving in kde settings? I mean changing the command issued. I don't know exactly what the default command is, probably systemctl. /usr/sbin/pm-suspend works better with kernel modules, and I'd like to use that It seems that kde uses "systemctl suspend": if I use it from shell, result is bad as if I suspend from menu. The defective kernel module cx23885: it doesn't support suspend and resume. It's a module for a DVB-T PCIe card. If I'm using kaffeine to watch DVB-T channels, I have to close it before suspending. If I leave it opened, kernel module comes up in a broken state. Closing and opening again kaffeine doesn't help, I have to -close kaffeine -rmmod cx23885 -modprobe cx23885 -open kaffeine This happens suspending with pm-suspend. Using systemctl, kernel module is broken after every suspend, even if kaffeine is not running. My system, if I don't restart Picom, freeze after a resume from suspend. To fix it I've placed this shell script in "/usr/lib/systemd/system-sleep/" directory ~$ cat /usr/lib/systemd/system-sleep/00_sleep.sh #!/bin/sh # Run from systemd-suspend.service to place under /usr/lib/systemd/system-sleep/ PATH=/sbin:/usr/sbin:/bin:/usr/bin case "$1" in pre) #code execution BEFORE sleeping/hibernating/suspending ;; post) #code execution AFTER resuming /usr/bin/sleep 5 /usr/bin/touch /home/frank/.config/picom.conf /usr/bin/sleep 1 ;; esac exit 0 So I think you've to do the same once you'll have a system that suspend to RAM properly. kind regards -- Franco Martelli
Re: Change suspend type from kde menu
On 28/12/2023 03:54, Valerio Vanni wrote: -close kaffeine -rmmod cx23885 -modprobe cx23885 -open kaffeine This happens suspending with pm-suspend. Using systemctl, kernel module is broken after every suspend, even if kaffeine is not running. I have never tried to tune suspend systemd settings, but I would try to create a single-shot service with "ExecStart=rmmod cx23885" that is "WantedBy" and "Before" suspend.target. Perhaps it is possible to find more details related to suspend.target and hibernate.target.
Re: Change suspend type from kde menu
Il 25/12/2023 04:25, Valerio Vanni ha scritto: Is there any way to change the way system is suspended from kde menu and from power saving in kde settings? I mean changing the command issued. I don't know exactly what the default command is, probably systemctl. /usr/sbin/pm-suspend works better with kernel modules, and I'd like to use that It seems that kde uses "systemctl suspend": if I use it from shell, result is bad as if I suspend from menu. The defective kernel module cx23885: it doesn't support suspend and resume. It's a module for a DVB-T PCIe card. If I'm using kaffeine to watch DVB-T channels, I have to close it before suspending. If I leave it opened, kernel module comes up in a broken state. Closing and opening again kaffeine doesn't help, I have to -close kaffeine -rmmod cx23885 -modprobe cx23885 -open kaffeine This happens suspending with pm-suspend. Using systemctl, kernel module is broken after every suspend, even if kaffeine is not running.
Change suspend type from kde menu
Is there any way to change the way system is suspended from kde menu and from power saving in kde settings? I mean changing the command issued. I don't know exactly what the default command is, probably systemctl. /usr/sbin/pm-suspend works better with kernel modules, and I'd like to use that
Re: Sound loses my analog speakers after suspend, and power settings don't affect monitor poweroff
On 8/12/23 01:05, Marco wrote: sudo dmesg | grep snd So I did that, and whether or not my analog audio was recognized, the output was: [ 4.199233] snd_pci_acp6x :66:00.5: enabling device ( -> 0002) [ 4.241643] snd_hda_intel :66:00.1: enabling device ( -> 0002) [ 4.241700] snd_hda_intel :66:00.1: Handle vga_switcheroo audio client [ 4.241952] snd_hda_intel :66:00.6: enabling device ( -> 0002) [ 4.291237] snd_hda_intel :66:00.1: bound :66:00.0 (ops amdgpu_dm_audio_component_bind_ops [amdgpu]) [ 4.323237] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC256: line_outs=1 (0x21/0x0/0x0/0x0/0x0) type:hp [ 4.323241] snd_hda_codec_realtek hdaudioC1D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 4.323243] snd_hda_codec_realtek hdaudioC1D0: hp_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 4.323244] snd_hda_codec_realtek hdaudioC1D0: mono: mono_out=0x0 [ 4.323245] snd_hda_codec_realtek hdaudioC1D0: inputs: [ 4.323247] snd_hda_codec_realtek hdaudioC1D0: Mic=0x19 -Carl Fink
Re: Sound loses my analog speakers after suspend, and power settings don't affect monitor poweroff
Now run sudo dmesg | grep snd to see if any error in the kernel module occurs.
Re: Sound loses my analog speakers after suspend, and power settings don't affect monitor poweroff
On 8/10/23 02:54, Marco wrote: Am 09.08.2023 schrieb Carl Fink : I suspended my system from the System menu Monday night. When I woke it up Tuesday morning, sound was coming from the HDMI monitor. The Sound Settings didn't know about any other sound system. This sounds like a driver problem with the soundcard. HDMI is realized with the graphics card, analog with a onboard sound card, mostly integrated into the chipset. Run lspci -nnk when it works and when it doesn't work. Thanks. I did just that, and I attach the output of both commands here. I switched from Mate to xfce4, which didn't affect anything from my previous message. The sound subsystem still forgets the external speakers exist. No matter what power settings I use, they don't shut off the monitors. I am thinking this is likely to be related to the power management system, rather than the sound support built into the Ryzen 6800. -Carl Fink 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h-19h PCIe Root Complex [1022:14b5] (rev 01) Subsystem: ASUSTeK Computer Inc. Family 17h-19h PCIe Root Complex [1043:8870] 00:00.2 IOMMU [0806]: Advanced Micro Devices, Inc. [AMD] Family 17h-19h IOMMU [1022:14b6] Subsystem: ASUSTeK Computer Inc. Family 17h-19h IOMMU [1043:8870] 00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h-19h PCIe Dummy Host Bridge [1022:14b7] (rev 01) 00:01.3 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 17h-19h PCIe GPP Bridge [1022:14ba] Subsystem: ASUSTeK Computer Inc. Family 17h-19h PCIe GPP Bridge [1043:8870] Kernel driver in use: pcieport 00:02.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h-19h PCIe Dummy Host Bridge [1022:14b7] (rev 01) DeviceName: Onboard IGD 00:02.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 17h-19h PCIe GPP Bridge [1022:14ba] Subsystem: ASUSTeK Computer Inc. Family 17h-19h PCIe GPP Bridge [1043:8870] Kernel driver in use: pcieport 00:02.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 17h-19h PCIe GPP Bridge [1022:14ba] Subsystem: ASUSTeK Computer Inc. Family 17h-19h PCIe GPP Bridge [1043:8870] Kernel driver in use: pcieport 00:02.3 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 17h-19h PCIe GPP Bridge [1022:14ba] Subsystem: ASUSTeK Computer Inc. Family 17h-19h PCIe GPP Bridge [1043:8870] Kernel driver in use: pcieport 00:02.4 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 17h-19h PCIe GPP Bridge [1022:14ba] Subsystem: ASUSTeK Computer Inc. Family 17h-19h PCIe GPP Bridge [1043:8870] Kernel driver in use: pcieport 00:03.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h-19h PCIe Dummy Host Bridge [1022:14b7] (rev 01) 00:03.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 19h USB4/Thunderbolt PCIe tunnel [1022:14cd] Subsystem: Advanced Micro Devices, Inc. [AMD] Family 19h USB4/Thunderbolt PCIe tunnel [1022:1453] Kernel driver in use: pcieport 00:04.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h-19h PCIe Dummy Host Bridge [1022:14b7] (rev 01) 00:04.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 19h USB4/Thunderbolt PCIe tunnel [1022:14cd] Subsystem: Advanced Micro Devices, Inc. [AMD] Family 19h USB4/Thunderbolt PCIe tunnel [1022:1453] Kernel driver in use: pcieport 00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h-19h PCIe Dummy Host Bridge [1022:14b7] (rev 01) 00:08.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 17h-19h Internal PCIe GPP Bridge [1022:14b9] (rev 10) Subsystem: Device [8870:1043] Kernel driver in use: pcieport 00:08.3 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 17h-19h Internal PCIe GPP Bridge [1022:14b9] (rev 10) Subsystem: Device [8870:1043] Kernel driver in use: pcieport 00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller [1022:790b] (rev 71) Subsystem: ASUSTeK Computer Inc. FCH SMBus Controller [1043:8870] Kernel driver in use: piix4_smbus Kernel modules: i2c_piix4, sp5100_tco 00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge [1022:790e] (rev 51) Subsystem: ASUSTeK Computer Inc. FCH LPC Bridge [1043:8870] 00:18.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Rembrandt Data Fabric: Device 18h; Function 0 [1022:1679] 00:18.1 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Rembrandt Data Fabric: Device 18h; Function 1 [1022:167a] 00:18.2 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Rembrandt Data Fabric: Device 18h; Function 2 [1022:167b] 00:18.3 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Rembrandt Data Fabric: Device 18h; Function 3 [1022:167c] Kernel driver in use: k10temp Kernel modules: k1
Re: Sound loses my analog speakers after suspend, and power settings don't affect monitor poweroff
Am 09.08.2023 schrieb Carl Fink : > I suspended my system from the System menu Monday night. When I woke > it up Tuesday morning, sound was coming from the HDMI monitor. The > Sound Settings didn't know about any other sound system. This sounds like a driver problem with the soundcard. HDMI is realized with the graphics card, analog with a onboard sound card, mostly integrated into the chipset. Run lspci -nnk when it works and when it doesn't work.
Sound loses my analog speakers after suspend, and power settings don't affect monitor poweroff
Hi, I recently installed Debian Bookworm using the Mate environment. I noticed that no matter what power settings I choose, the monitors never power off. The screensaver can lock the screen, but it then just stays on for many hours. I have external analog speakers that I use, and also terrible, tinny speakers built into my HDMI monitor that i never use because they suck. I suspended my system from the System menu Monday night. When I woke it up Tuesday morning, sound was coming from the HDMI monitor. The Sound Settings didn't know about any other sound system. I tried killing/restarting pulseaudio, but of course, Mate's seemingly-similar audio system was installed instead. I then uninstalled that and installed pulseaudio. This did not help. I had to reboot to get audio back through the speakers. This sort of defeats the point of suspending. I suspended before leaving for the office today. When I came back, the sound system still didn't admit the existence of the analog speakers. I had to reboot again. Now "Analog Stereo Duplex" is there again. Yes, I did try unplugging and replugging the speaker wire. Please let me know what other information would help debug this problem. Also, should it become necessary, what packages would I report these bugs in? Perhaps, mate-power-manager and pulseaudio? This is an ASUS PN53 small form-factor unit, if that helps any. Thank you. -Carl Fink
Disable laptop suspend and hibernate when plugged-in or charging?
Hi Everyone, I have a Pinebook Pro, https://www.pine64.org/pinebook-pro/ . The laptop suspends or hibernates even when charging. I cannot SSH into it. I want to disable suspend or hibernate while the laptop is plugged-in. I visited https://wiki.debian.org/Suspend , but it does not discuss the laptop being plugged into the power cord or charging. (I make a small distinction between "plugged-in" and "charging." The laptop may be fully charged and plugged-in, but it may not be charging since it is fully charged). How do I disable suspend or hibernate when the laptop is plugged into the power cord or charging? Thanks in advance.
Re: xfce suspend not working
Hi Richmond, Why don't you make an experiment? Make a full backup of your ssystem Do some serious testing in your spare time. Publish the results, please. You might do others a favour (now and in the future). Arne On Wed, 16 Mar 2022 12:48:27 + Richmond wrote: > Richmond writes: > > > I was using MATE but I installed xfce. When I select the suspend button > > a message appears saying suspend in 30 seconds. If I click suspend the > > screen locks. If I wait the system does not suspend. If I log in again > > an error message says suspend failed timeout reached. > > > > There seem to be conflicting settings available for example in power > > management and in session management for lock before suspend. I tried > > using slim instead of lightdm but this has removed the suspend options. > > > > What I want is for the system to suspend to ram if it is left > > unattended, and to suspend to ram when I request it to do so, and in > > both cases to lock the screen so that it is locked on return from > > suspend. How do I do this with XFCE (4?) ? > > I think I have fixed it. It was caused by the mate-screensaver dialog > running. >
Re: (suspend && lock screen) vs (lock screen && suspend)
On Thu 12 May 2022 at 17:34:55 (+0100), Ottavio Caruso wrote: > On 12/05/2022 14:31, Greg Wooledge wrote: > > On Thu, May 12, 2022 at 02:06:24PM +0100, Ottavio Caruso wrote: > > > #!/bin/sh > > > systemctl suspend && mate-screensaver-command -l > > > This one seems to work, however I would have thought that the logical > > > sequence would be: > > > > > > mate-screensaver-command -l && systemctl suspend > > > > > > that is, a) lock screen; b) suspend; c) resume with lock screen on. > > > > > > Instead, if I use the latter syntax, upon resuming, there is a 10 second > > > delay before locking the screen, which is not ideal for obvious privacy > > > reasons. > > > > > > Any input on that? > "race condition" or not, it doesn't make sense that, upon resume, the > screen lock pauses for 10 seconds and then reactivates. https://github.com/mate-desktop/mate-screensaver/issues/231 Cheers, David.
Re: (suspend && lock screen) vs (lock screen && suspend)
On Thu, May 12, 2022 at 02:06:24PM +0100, Ottavio Caruso wrote: > #!/bin/sh > systemctl suspend && mate-screensaver-command -l > This one seems to work, however I would have thought that the logical > sequence would be: > > mate-screensaver-command -l && systemctl suspend > > that is, a) lock screen; b) suspend; c) resume with lock screen on. > > Instead, if I use the latter syntax, upon resuming, there is a 10 second > delay before locking the screen, which is not ideal for obvious privacy > reasons. > > Any input on that? Any analysis here would require some knowledge of what each of these commands actually *does*. I know nothing about mate-screensaver-command, so I can only focus on systemctl. Normally, the systemctl command either requests information from systemd and writes it to stdout (or pipes it into a pager), *or* it sends an action request to systemd. I'm not a laptop guy, and I've never suspended anything, and I don't really understand the basic concepts of that. But "systemctl suspend" sounds like the sort of command that sends an action request to systemd, and then terminates without waiting for systemd to actually do its thing. That's how commands like "systemctl restart servicename" work. So, in your script (the one that works), you first run a command that requests an action from systemd and terminates immediately after sending the request; and then, if it returns a successful exit status, you run the mate-screensaver-command. Meanwhile, systemd is presumably doing this "suspend" thing at the same time as mate-screensaver-command is doing whatever it does. To me this sounds like a classic race condition. Two things are going at the same time, and the end result depends on which one finishes first. But without knowing the full details of how these two things actually work, I can't say much more.
Re: xfce suspend not working
Richmond writes: > I was using MATE but I installed xfce. When I select the suspend button > a message appears saying suspend in 30 seconds. If I click suspend the > screen locks. If I wait the system does not suspend. If I log in again > an error message says suspend failed timeout reached. > > There seem to be conflicting settings available for example in power > management and in session management for lock before suspend. I tried > using slim instead of lightdm but this has removed the suspend options. > > What I want is for the system to suspend to ram if it is left > unattended, and to suspend to ram when I request it to do so, and in > both cases to lock the screen so that it is locked on return from > suspend. How do I do this with XFCE (4?) ? I think I have fixed it. It was caused by the mate-screensaver dialog running.
xfce suspend not working
I was using MATE but I installed xfce. When I select the suspend button a message appears saying suspend in 30 seconds. If I click suspend the screen locks. If I wait the system does not suspend. If I log in again an error message says suspend failed timeout reached. There seem to be conflicting settings available for example in power management and in session management for lock before suspend. I tried using slim instead of lightdm but this has removed the suspend options. What I want is for the system to suspend to ram if it is left unattended, and to suspend to ram when I request it to do so, and in both cases to lock the screen so that it is locked on return from suspend. How do I do this with XFCE (4?) ?
Re: Debian 11 doesn't suspend properly on Acer Aspire 5 A515-51G-52GM
On 26/08/2021 14:41, Piotr A. Dybczyński wrote: Hi, I have similar problem on Dell Inspiron 3580 Both after upgrade from Buster to Bullseye and after clean install on a seprate partition laptop does not wake up (in fact it sometimes does) but completely freezes, only power off can help. You forgot to include system logs showing the problem. -- With kindest regards, piorunz. ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org ⠈⠳⣄
Re: Debian 11 doesn't suspend properly on Acer Aspire 5 A515-51G-52GM
Hi, I have similar problem on Dell Inspiron 3580 Both after upgrade from Buster to Bullseye and after clean install on a seprate partition laptop does not wake up (in fact it sometimes does) but completely freezes, only power off can help. When I booted Bullseye with the previous kernel (4.19) it works OK. My hardware is (from lspci): 00:02.0 VGA compatible controller: Intel Corporation WhiskeyLake-U GT2 [UHD Graphics 620] 01:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Jet PRO [Radeon R5 M230 / R7 M260DX / Radeon 520 Mobile] (rev c3) Regards, Piotr -- /** dr Piotr A. Dybczyński homepage: https://www.dybczynski.pl/Piotr e-mail: pi...@dybczynski.pl PAD***/
Re: Debian 11 doesn't suspend properly on Acer Aspire 5 A515-51G-52GM
On 2021-08-21 3:03 p.m., piorunz wrote: > On 21/08/2021 19:38, Mislav Jurić wrote: > >> I have a bug related to Debian 11 (codename Bullseye). I tried to report >> it using /*reportbug*/, but /*reportbug*/ led me to this email address. >> >> I am using Debian 11 on Acer Aspire 5 A515-51G-52GM. *My issue is that >> when I close my laptop screen for the 5th or 6th time, my laptop doesn't >> suspend properly. *Again, this issue doesn't happen every time. It >> happens after I close and then re-open the laptop screen for the 5th or >> 6th time in a row. >> >> I am using NVIDIA drivers and CUDA for Debian 11 which I obtained >> following instructions from this link >> <https://wiki.debian.org/NvidiaGraphicsDrivers>. I am also using the >> Atheros firmware package, as well as some other non-driver related >> packages. Some *other non-driver related packages* this could hardly be more vague. The more information you give, the more information you'll have chance to get help from people on this mailing list. Are you using the plain install of Debian 11 ? Have you made some configuration changes regarding hibernation and power management ? What what does *does not suspend properly* is supposed to mean ? It may be clear in your own mind but for everyone else it could mean many things. For example : Does not suspend at all It only turn off the display but does not suspend the computer itself. The computer suspend but doesn't resume properly. The system start to suspend but crash doing so. The system suspend properly but crash waking up. The system suspend properly but wake up as if it was turned off. The system start to suspend but goes into a unknown state... etc. Also your computer may have many configurations, which one you have ? Maybe installing hwinfo package and sending the dump of *hwinfo -all* here could help. You can use *apt-get install hwinfo* and after use the following command in a terminal *hwinfo > hwinfo.txt* then send the content of *hwinfo.txt* (for example opening in a text editor and copying into a message). > > NVIDIA drivers are closed source and proprietary. If they are cause of > this problem, Debian or kernel developers might not be able to help you. > > Try to uninstall NVIDIA drivers and use nouveau drivers for a few days. > See if you can reproduce this problem on nouveau. Please note that > nouveau are very basic and 3D acceleration or other things may not work > at all. > Also when you report a problem, even here, it would be useful to include > your hardware specification and cuts from dmesg or other logs showing > this problem, maybe someone will be more able to help after seeing > specific details, not only vague description of the problem. > > -- > > With kindest regards, piorunz. > > ⢀⣴⠾⠻⢶⣦⠀ > ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system > ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org > ⠈⠳⣄ > -- Polyna-Maude R.-Summerside -Be smart, Be wise, Support opensource development OpenPGP_signature Description: OpenPGP digital signature
Re: Debian 11 doesn't suspend properly on Acer Aspire 5 A515-51G-52GM
On 21/08/2021 19:38, Mislav Jurić wrote: I have a bug related to Debian 11 (codename Bullseye). I tried to report it using /*reportbug*/, but /*reportbug*/ led me to this email address. I am using Debian 11 on Acer Aspire 5 A515-51G-52GM. *My issue is that when I close my laptop screen for the 5th or 6th time, my laptop doesn't suspend properly. *Again, this issue doesn't happen every time. It happens after I close and then re-open the laptop screen for the 5th or 6th time in a row. I am using NVIDIA drivers and CUDA for Debian 11 which I obtained following instructions from this link <https://wiki.debian.org/NvidiaGraphicsDrivers>. I am also using the Atheros firmware package, as well as some other non-driver related packages. NVIDIA drivers are closed source and proprietary. If they are cause of this problem, Debian or kernel developers might not be able to help you. Try to uninstall NVIDIA drivers and use nouveau drivers for a few days. See if you can reproduce this problem on nouveau. Please note that nouveau are very basic and 3D acceleration or other things may not work at all. Also when you report a problem, even here, it would be useful to include your hardware specification and cuts from dmesg or other logs showing this problem, maybe someone will be more able to help after seeing specific details, not only vague description of the problem. -- With kindest regards, piorunz. ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org ⠈⠳⣄
Debian 11 doesn't suspend properly on Acer Aspire 5 A515-51G-52GM
Dear Debian users, I have a bug related to Debian 11 (codename Bullseye). I tried to report it using *reportbug*, but *reportbug* led me to this email address. I am using Debian 11 on Acer Aspire 5 A515-51G-52GM. *My issue is that when I close my laptop screen for the 5th or 6th time, my laptop doesn't suspend properly. *Again, this issue doesn't happen every time. It happens after I close and then re-open the laptop screen for the 5th or 6th time in a row. I am using NVIDIA drivers and CUDA for Debian 11 which I obtained following instructions from this link <https://wiki.debian.org/NvidiaGraphicsDrivers>. I am also using the Atheros firmware package, as well as some other non-driver related packages. If you could give me further guidance on this, I'd greatly appreciate it. Best regards
