I share my home computer with my family. At the moment it is only possible for one person at a time to use gsconnect. The second one to log on will receive a error message from GSConnect.
It would be nice to have a setting or a documentation on how to configure gsconnect both on the desktop and the phone.
System Details:
@siegfriedhuber Hmm... how do the multiple users access the computer? By remote login, or by switching users via the lock screen?
GSConnect is sort of inherently single-use on a given device. (Only one process can be listening on the port(s) specified by the KDE Connect protocol.) But if all the logins are local, there may be some way to detect the user switch and have gsconnect for the previously-logged-in user drop its port bindings.
Computer is shared by switching users.
I thought of something like detecting the user switch myself. That really would be a great improvement for me.
So, from a little dbus-monitor --system --monitor "type='signal'" snooping, it seems every time a session change occurs, org.freedesktop.login1.Seat signals a PropertiesChanged for its ActiveSession. Potentially we could listen for that, and take action to release the ports if a session becomes ActiveSession that's not ours. (And not the greeter session, which does also become active in between user sessions when the switch is being performed. But it always has the session path /org/freedesktop/login1/session/c1, at least on my system, so it's easy to identify.)
Starting with my own user session logged in, I select "Switch User"...
// Greeter activates
signal time=1559567080.617497 sender=:1.16 -> destination=(null destination) serial=696 path=/org/freedesktop/login1/seat/seat0; interface=org.freedesktop.DBus.Properties; member=PropertiesChanged
string "org.freedesktop.login1.Seat"
array [
dict entry(
string "ActiveSession"
variant struct {
string "c1"
object path "/org/freedesktop/login1/session/c1"
}
)
]
array [
]
//
// Other-user session logs in
signal time=1559567086.944996 sender=:1.16 -> destination=(null destination) serial=739 path=/org/freedesktop/login1/seat/seat0; interface=org.freedesktop.DBus.Properties; member=PropertiesChanged
string "org.freedesktop.login1.Seat"
array [
dict entry(
string "ActiveSession"
variant struct {
string "11"
object path "/org/freedesktop/login1/session/_311"
}
)
]
array [
]
//
// 'They' select "Log out", back to the greeter...
signal time=1559567098.878477 sender=:1.16 -> destination=(null destination) serial=859 path=/org/freedesktop/login1/seat/seat0; interface=org.freedesktop.DBus.Properties; member=PropertiesChanged
string "org.freedesktop.login1.Seat"
array [
dict entry(
string "ActiveSession"
variant struct {
string "c1"
object path "/org/freedesktop/login1/session/c1"
}
)
]
array [
]
//
// My own session is restored to `ActiveSession`
signal time=1559567103.344480 sender=:1.16 -> destination=(null destination) serial=901 path=/org/freedesktop/login1/seat/seat0; interface=org.freedesktop.DBus.Properties; member=PropertiesChanged
string "org.freedesktop.login1.Seat"
array [
dict entry(
string "ActiveSession"
variant struct {
string "2"
object path "/org/freedesktop/login1/session/_32"
}
)
]
array [
]
As far as getting _our own_ session ID, well that can be accessed at /org/freedesktop/login1/session/self, but there doesn't seem to be any way to translate that back into a "real" ID to match against ActiveSession.
But there's also /org/freedesktop/login1/user/self, which has the org.freedesktop.login1.User interface with a Sessions property that contains an array of session identifiers, that does contain the "real" session ID/path.
$ dbus-send --system --print-reply --type=method_call --dest='org.freedesktop.login1' \
$ /org/freedesktop/login1/user/self org.freedesktop.DBus.Properties.Get \
$ string:'org.freedesktop.login1.User' string:'Sessions'
method return time=1559568760.355394 sender=:1.16 -> destination=:1.2180 serial=1382 reply_serial=2
variant array [
struct {
string "2"
object path "/org/freedesktop/login1/session/_32"
}
]
There's also the org.freedesktop.login1.Manager.GetSessionByPID method, which can be used to translate _some_ PIDs to session identifiers — but the GSConnect gjs process registers as not being attached to any known session (probably a function of its daemon-hood), and if it can't use its own PID for the lookup I'm not sure there's really any point.
$ dbus-send --system --print-reply --type=method_call --dest='org.freedesktop.login1' \
$ /org/freedesktop/login1 org.freedesktop.login1.Manager.GetSessionByPID \
$ uint32:"$(pidof gnome-session-binary)"
method return time=1559569580.769252 sender=:1.16 -> destination=:1.2381 serial=1595 reply_serial=2
object path "/org/freedesktop/login1/session/_32"
$ dbus-send --system --print-reply --type=method_call --dest='org.freedesktop.login1' \
$ /org/freedesktop/login1 org.freedesktop.login1.Manager.GetSessionByPID uint32:"$(pidof gjs)"
Error org.freedesktop.login1.NoSessionForPID: PID 2795 does not belong to any known session
$ dbus-send --system --print-reply --type=method_call --dest='org.freedesktop.login1' \
$ /org/freedesktop/login1 org.freedesktop.login1.Manager.GetSessionByPID \
$ uint32:"$(pgrep -u gdm gdm-x-session)"
method return time=1559569902.125015 sender=:1.16 -> destination=:1.2464 serial=1659 reply_serial=2
object path "/org/freedesktop/login1/session/c1"
I'm going to mark this as upstream since there's really no decent way to do this until the mDNS link provider is written. The only alternative to this is really closing the other users' default port, and given how often KDE Connect hotswaps socket connections that basically amounts to overruling the other users' instance.
Best short term solution is for the inactive user to actually log out, otherwise there's no way to ensure a primary user can maintain authority over the system.
Upstream work that will allow this is at [Android] Multicast backend, although it's still only a WIP.
Most helpful comment
I'm going to mark this as
upstreamsince there's really no decent way to do this until the mDNS link provider is written. The only alternative to this is really closing the other users' default port, and given how often KDE Connect hotswaps socket connections that basically amounts to overruling the other users' instance.Best short term solution is for the inactive user to actually log out, otherwise there's no way to ensure a primary user can maintain authority over the system.