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
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
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
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,
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
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
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
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
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
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 /
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
I don't have MediaPlayer2 there.
busctl --user introspect org.mpris.kaffeine /Player
# ...
.Stop
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
Il 12/01/2024 03:52, Max Nikulin ha scritto:
I assume that "org/mpris/MediaPlayer2" after "/" was lost during
copy
I don't have MediaPlayer2 there.
busctl --user introspect org.mpris.kaffeine /Player
# ...
.Stop method - - -
I saw that,
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
I don't have MediaPlayer2
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
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" \
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
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 -- \
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
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
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
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"
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
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
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
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
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
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
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
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
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
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 \
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"
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,
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.
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
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 \
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
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 \
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
> -
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
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,
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
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
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
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
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
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
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
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
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,
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"
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
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:
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
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
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
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
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
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
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
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
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
63 matches
Mail list logo
