Unfortunately I am clueless at this point. Given that the issue also
occurs with TigerVNC and doesn't occur with any other WM or any other
O/S distribution, there isn't much I can do to isolate it. I googled
around and didn't find any other reports of it. There unfortunately
isn't anything e
At least in my testing, IdleSinceHint is 0 for the SSH sessions that the
TurboVNC Viewer creates for tunneling, so I doubt that any of those
sessions would stop the suspend. Also, the SSH sessions (and associated
logind sessions) created for tunneling only persist while the TurboVNC
Viewer is
hello DRC,
thank you for looking into this issue! A colleague and I tried the setup
again (we are both in HO),
and we also cannot see a login session generated by (turbo-)VNC. Probably
this is never generated,
and we were wrong :-/
Are you saying that a TurboVNC session that uses ssh tunneling li
Disregard my previous remark about a black screen. That was user
error. I can now reproduce exactly the issue you report. In fact,
specifying any resolution that is in the default list of resolutions
reported by X RandR causes the failure. If I remove 1440x900 and
1920x1080 from that list,
Reproduced. In my case, specifying -geometry (or $geometry in
turbovncserver.conf) never works. It fails with the "Oh No! Something
has gone wrong!" screen if I specify 1440x900, but it fails with a black
screen otherwise. The same happens with TigerVNC, and TigerVNC's startup
mechanism is so
I can't make the TurboVNC sessions show up with 'loginctl list-sessions'
at all. The only thing I see in that list are GDM and the SSH sessions,
so there will be a login session associated with a TurboVNC session only
if there is an active connection to that TurboVNC session that uses SSH
tunn
