Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #265238 > unrolled thread
| Started by | Valerio Vanni <valerio.vanni@inwind.it> |
|---|---|
| First post | 2023-12-25 04:40 +0100 |
| Last post | 2024-01-15 14:50 +0100 |
| Articles | 20 on this page of 63 — 6 participants |
Back to article view | Back to linux.debian.user
Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2023-12-25 04:40 +0100
Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2023-12-27 22:00 +0100
Re: Change suspend type from kde menu Max Nikulin <manikulin@gmail.com> - 2023-12-28 02:50 +0100
Re: Change suspend type from kde menu Franco Martelli <martellif67@gmail.com> - 2023-12-28 15:50 +0100
Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2023-12-28 23:20 +0100
Re: Change suspend type from kde menu Charles Curley <charlescurley@charlescurley.com> - 2023-12-29 00:20 +0100
Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2023-12-29 02:30 +0100
Re: Change suspend type from kde menu Max Nikulin <manikulin@gmail.com> - 2023-12-29 03:00 +0100
Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2023-12-29 23:00 +0100
Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-02 19:20 +0100
Re: Change suspend type from kde menu Franco Martelli <martellif67@gmail.com> - 2024-01-03 17:20 +0100
Re: Change suspend type from kde menu Greg Wooledge <greg@wooledge.org> - 2024-01-03 17:50 +0100
Re: Change suspend type from kde menu Arno Lehmann <al@its-lehmann.de> - 2024-01-03 18:40 +0100
Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-04 15:10 +0100
Re: Change suspend type from kde menu Greg Wooledge <greg@wooledge.org> - 2024-01-04 16:30 +0100
Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-05 18:00 +0100
Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-05 20:00 +0100
Re: Change suspend type from kde menu Greg Wooledge <greg@wooledge.org> - 2024-01-05 20:10 +0100
Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-05 20:20 +0100
Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-05 20:40 +0100
Re: Change suspend type from kde menu Franco Martelli <martellif67@gmail.com> - 2024-01-05 20:50 +0100
Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-05 21:30 +0100
Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-05 21:50 +0100
Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-05 23:40 +0100
Re: Change suspend type from kde menu Greg Wooledge <greg@wooledge.org> - 2024-01-06 01:10 +0100
Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-06 13:50 +0100
Re: Change suspend type from kde menu Max Nikulin <manikulin@gmail.com> - 2024-01-06 16:30 +0100
Re: Change suspend type from kde menu Max Nikulin <manikulin@gmail.com> - 2024-01-07 06:50 +0100
Re: Change suspend type from kde menu Max Nikulin <manikulin@gmail.com> - 2024-01-08 04:40 +0100
Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-10 20:40 +0100
Re: Change suspend type from kde menu Max Nikulin <manikulin@gmail.com> - 2024-01-11 04:50 +0100
Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-11 14:50 +0100
Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-09 22:50 +0100
Re: Change suspend type from kde menu Max Nikulin <manikulin@gmail.com> - 2024-01-11 05:00 +0100
Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-11 15:30 +0100
Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-11 16:40 +0100
Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-09 19:40 +0100
Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-04 00:00 +0100
Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-04 15:10 +0100
Re: Change suspend type from kde menu Max Nikulin <manikulin@gmail.com> - 2024-01-04 15:50 +0100
Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-04 16:30 +0100
Re: Change suspend type from kde menu Max Nikulin <manikulin@gmail.com> - 2024-01-04 17:20 +0100
Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-05 18:10 +0100
Re: Change suspend type from kde menu Max Nikulin <manikulin@gmail.com> - 2024-01-06 17:40 +0100
Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-09 20:00 +0100
Re: Change suspend type from kde menu Max Nikulin <manikulin@gmail.com> - 2024-01-11 05:20 +0100
Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-11 15:20 +0100
Re: Change suspend type from kde menu Max Nikulin <manikulin@gmail.com> - 2024-01-11 16:30 +0100
Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-11 16:50 +0100
Re: Change suspend type from kde menu Max Nikulin <manikulin@gmail.com> - 2024-01-12 04:00 +0100
Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-12 12:10 +0100
Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-12 15:40 +0100
Re: Change suspend type from kde menu Max Nikulin <manikulin@gmail.com> - 2024-01-12 17:30 +0100
Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-12 22:40 +0100
Re: Change suspend type from kde menu Max Nikulin <manikulin@gmail.com> - 2024-01-13 16:30 +0100
Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-13 16:40 +0100
Re: Change suspend type from kde menu Max Nikulin <manikulin@gmail.com> - 2024-01-14 05:10 +0100
Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-15 14:40 +0100
Re: Change suspend type from kde menu Franco Martelli <martellif67@gmail.com> - 2024-01-12 15:10 +0100
Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-12 15:40 +0100
Re: Change suspend type from kde menu Franco Martelli <martellif67@gmail.com> - 2024-01-12 21:20 +0100
Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-12 23:00 +0100
Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-15 14:50 +0100
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
| From | Valerio Vanni <valerio.vanni@inwind.it> |
|---|---|
| Date | 2024-01-04 16:30 +0100 |
| Message-ID | <HSxPr-Lwi-7@gated-at.bofh.it> |
| In reply to | #265506 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2024-01-04 17:20 +0100 |
| Message-ID | <HSyBP-MeV-3@gated-at.bofh.it> |
| In reply to | #265509 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Valerio Vanni <valerio.vanni@inwind.it> |
|---|---|
| Date | 2024-01-05 18:10 +0100 |
| Message-ID | <HSVRL-11q6-3@gated-at.bofh.it> |
| In reply to | #265511 |
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
AME TYPE 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 - - -
.Get method ss v -
.GetAll method s a{sv} -
.Set method ssv - -
.PropertiesChanged signal sa{sv}as - -
org.qtproject.Qt.QApplication interface - - -
.aboutQt method - - -
.autoSipEnabled method - b -
.closeAllWindows method - - -
.setAutoSipEnabled method b - -
.setStyleSheet method s - -
lines 1-17
/Television
AME TYPE 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 - - -
.Get method ss v -
.GetAll method s a{sv} -
.Set method ssv - -
.PropertiesChanged signal sa{sv}as - -
org.freedesktop.MediaPlayer interface - - -
.DigitPressed method i - -
.ListProgramSchedule method - a(ussssib) -
.PlayChannel method s - -
.PlayLastChannel method - - -
.RemoveProgram method u - -
>> 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...
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2024-01-06 17:40 +0100 |
| Message-ID | <HThSh-1fCH-17@gated-at.bofh.it> |
| In reply to | #265541 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Valerio Vanni <valerio.vanni@inwind.it> |
|---|---|
| Date | 2024-01-09 20:00 +0100 |
| Message-ID | <HUpuq-1X6H-21@gated-at.bofh.it> |
| In reply to | #265589 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2024-01-11 05:20 +0100 |
| Message-ID | <HUUHT-2hr2-1@gated-at.bofh.it> |
| In reply to | #265726 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Valerio Vanni <valerio.vanni@inwind.it> |
|---|---|
| Date | 2024-01-11 15:20 +0100 |
| Message-ID | <HV44x-2naC-3@gated-at.bofh.it> |
| In reply to | #265772 |
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 /
NAME TYPE 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 - - -
.Get method ss v -
.GetAll method s a{sv} -
.Set method ssv - -
.PropertiesChanged signal sa{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?
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2024-01-11 16:30 +0100 |
| Message-ID | <HV5ah-2nMq-1@gated-at.bofh.it> |
| In reply to | #265789 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Valerio Vanni <valerio.vanni@inwind.it> |
|---|---|
| Date | 2024-01-11 16:50 +0100 |
| Message-ID | <HV5tD-2nTI-1@gated-at.bofh.it> |
| In reply to | #265793 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2024-01-12 04:00 +0100 |
| Message-ID | <HVfW2-2u8S-5@gated-at.bofh.it> |
| In reply to | #265796 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Valerio Vanni <valerio.vanni@inwind.it> |
|---|---|
| Date | 2024-01-12 12:10 +0100 |
| Message-ID | <HVnAd-2zex-1@gated-at.bofh.it> |
| In reply to | #265812 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Valerio Vanni <valerio.vanni@inwind.it> |
|---|---|
| Date | 2024-01-12 15:40 +0100 |
| Message-ID | <HVqRr-2B6n-7@gated-at.bofh.it> |
| In reply to | #265817 |
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
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2024-01-12 17:30 +0100 |
| Message-ID | <HVszU-2CaA-3@gated-at.bofh.it> |
| In reply to | #265831 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Valerio Vanni <valerio.vanni@inwind.it> |
|---|---|
| Date | 2024-01-12 22:40 +0100 |
| Message-ID | <HVxpT-2F29-11@gated-at.bofh.it> |
| In reply to | #265839 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2024-01-13 16:30 +0100 |
| Message-ID | <HVO7n-2PDc-3@gated-at.bofh.it> |
| In reply to | #265856 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Valerio Vanni <valerio.vanni@inwind.it> |
|---|---|
| Date | 2024-01-13 16:40 +0100 |
| Message-ID | <HVOh4-2PGr-11@gated-at.bofh.it> |
| In reply to | #265884 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2024-01-14 05:10 +0100 |
| Message-ID | <HVZYR-2X01-3@gated-at.bofh.it> |
| In reply to | #265885 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Valerio Vanni <valerio.vanni@inwind.it> |
|---|---|
| Date | 2024-01-15 14:40 +0100 |
| Message-ID | <HWvm1-3gd2-5@gated-at.bofh.it> |
| In reply to | #265911 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Franco Martelli <martellif67@gmail.com> |
|---|---|
| Date | 2024-01-12 15:10 +0100 |
| Message-ID | <HVqop-2AXr-1@gated-at.bofh.it> |
| In reply to | #265789 |
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
[toc] | [prev] | [next] | [standalone]
| From | Valerio Vanni <valerio.vanni@inwind.it> |
|---|---|
| Date | 2024-01-12 15:40 +0100 |
| Message-ID | <HVqRr-2B6n-9@gated-at.bofh.it> |
| In reply to | #265830 |
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.
[toc] | [prev] | [next] | [standalone]
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
Back to top | Article view | linux.debian.user
csiph-web