ThinLinc client 4.19.0+ and fullscreen+multi-monitor session re-connect issue

ThinLinc
1

Hi,

Since we moved our ThinClient environment (https://github.com/jens-maus/thinRoot) to using the x86_64 native tlclient version 4.19.0 users with multi-monitor setups complain that once they are returning to their existing sessions, all application windows that were previously located on a secondary monitor are moved to the main (most-left) monitor. Thus, when these users re-connect to the ThinLinc server they always have to relocate their applications windows and once they are about to reconnect again, they find themselves in the same situation that they have to move the application windows around once more.

So does anyone else have noticed that change/issue since using ThinLinc client 4.19.0 in a similar full-screen+multi-monitor environment?

Note, that apart from having to move around application windows, the multi-monitor mode works correctly even with 4.19.0. After downgrading the tlclient to version 4.18.0 the issue vanishes immediately and users can return to their sessions with the same multi-monitor setup like before: As soon as they return to their sessions, all application windows are located at the monitor they disconnected from the session. I have already reported that issue in the bugzilla (https://bugzilla.cendio.com/show_bug.cgi?id=8686) since I have the feeling that this might be an actual bug in the tlclient 4.19.0 version. Furthermore, I think this might be related to another bug which was fixed in version 4.19.0 (https://bugzilla.cendio.com/show_bug.cgi?id=8199), thus could be the reason why multi-monitor setups are now behaving slightly different. Please note that our ThinLinc server is correctly at version 4.19.0 and apart from that issue works fine with tlclient 4.18.0 or 4.19.0 as long as no multi-monitor setup is used.

Removing 32-bit support
2

Hi @j.maus,

Thanks for the report!

@samuel I don’t have a suitable multi-monitor set up for testing this on unfortunately. Is this something we’re aware of?

3

Thanks for checkin back. If it might help I could perhaps try to get a short screencast of it uploaded here which demonstrates the issue where with the 4.19.0 client app windows are collected to a single screen upon session re-connect while with the 4.18.0 version it perfectly keeps windows at the position where they were left…

4

We tried replicating the issue here, but were unfortunately not able to do so. :confused:

The issue might depend on the desktop environment. We were using GNOME and KDE for our tests. Which desktop environment did you use when seeing the problem?

5

Hi Pierre,

Thanks for checking with a GNOME and KDE environment and sorry that it took so long to answer your question.

I just updated our server and ThinLinc client to 4.20.0 now (also in the hope that the issue might fade away) and the issue unfortunately still exists.

I debugged this a bit further now and could pinpoint it to our Lubuntu (LxQt/OpenBox) environment. So we are not using GNOME/KDE here, but have a Lubuntu-based environment for our users simply to keep things lightweight. And if I connect to the same server, but select a different window manager/environment then the issue vanishes. In fact, it seems to indeed be enough to change the window manager to xfwm4 and not use the default openbox window manager with LxQt. Then the issue is also gone and the windows that are on a second screen when re-connecting to a ThinLinc session are NOT moved to the primary screen (or towards it) anymore. So it seems the issue with ThinLinc client 4.19.0 and newer only appears if an openbox window-manager environment is used. I could also verify the same with a different Lubuntu system where a thinlinc server is running. As soon as I switch from openbox to e.g. xfwm4 the issue disappears.

So could you perhaps try to reproduce the issue with Lubuntu (LxQt/OpenBox)? To me it seems to be related to the point that somehow OpenBox things upon re-connection that it has to re-locate windows on the secondary display (probably because the full monitor setup is not yet fixed upon re-connection) to the primary (leftmost) display. In fact, looking very closely one can see that upon re-connection to the ThinLinc server there seems to be a somewhat more severe screen flickering at the very start of the re-connection when using 4.19.0 compared to 4.18.0 which looks like the connection first comes up with only one display and then a few milliseconds later the second display appears, which in fact could trigger the OpenBox window-manager to run the window re-location procedure. And other window managers do not seem to be affected here or handle this re-location a bit differently, e.g. later when both monitors are correctly assigned.

Would be great if you and your ThinLinc crew could try to reproduce this issue once more as I am sure this must be related to some change in the ThinLinc client from version 4.18.0 to 4.19.0 which might handle full-screen/multi-monitor setups a slightly bit differently, which triggers this OpenBox-related issue.

6

Thank you for the extra details. We can try to get a test system set up with OpenBox here and try.

But to our knowledge, OpenBox does not support full screen over multiple monitors:

Which version of OpenBox are you using? And have you applied any changes to better support this?

7

To clarify, the most interesting window manager is the one used on the client device. It sounds like you might have only tested which window manager is used inside the ThinLinc session?

8

Thanks for your reply. Indeed our thinclients (using our own thinRoot OS) are also using OpenBox internally. However, until ThinLinc client 4.19.0+ we never observed any issues with full screen support over multiple monitors even thought NET_WM_FULLSCREEN_MONITORS might not be supported (we use Openbox 3.6.1). This was and is working nicely as long as we don’t update the ThinLinc client to 4.19.0+ within our thinclients.

As said, the issue vanishes immediately when we switch from OpenBox on the Lubuntu/LxQt server (which is also using OpenBox 3.6.1) to e.g. xfwm4 or use any other WM like GNOME/KDE there. Or as said, we use the 4.18.0 client in our thinclient environment (like we still do).

9

I tried to reproduce the issue here, but I’m unable to get OpenBox to give me full screen over two monitors. It will just use a single monitor no matter what I configure in the client.

I tested this with ThinLinc 4.20.0 with “Full screen on all monitors”. OpenBox 3.6.1 was used without any special configuration.

How have you configured things to get this to work with OpenBox?

10

Hi Pierre,

thanks for your reply — and sorry again for the delay. I had to re-test everything.

You’re absolutely right that the local window manager also affects this issue. After some testing I noticed that if I kill OpenBox completely and run without any window manager, the problem is gone as well: when the ThinLinc client reconnects to a multi-screen session, all windows stay exactly where they are. So at the moment, we see three possible workarounds:

  1. Use e.g. “xfwm4” as the window manager on the server, so sessions would use xfwm4 instead of OpenBox. However, we would prefer to stay with OpenBox.
  2. Kill the local OpenBox window manager on our thin client so that, once the ThinLinc client connects, there is no local window manager at all.
  3. Use a different but similarly lightweight window manager on the thin client (e.g. matchbox-window-manager).

However, none of these workarounds is particularly appealing or satisfying.

Regarding your question about our environment and how we can span across multiple screens/monitors in our OpenBox-driven thin-client setup: our thin-client OS (thinRoot) does not use Xinerama. Instead, on boot it always spans all connected screens into a single X11 screen. That means if two HDMI monitors are connected, there is only one X11 display with double the horizontal resolution (rather than separate displays such as :0 and :1 or :0.0 and :0.1). In this setup, an application configured for fullscreen will automatically span the entire combined desktop area — regardless of whether a window manager is running or not.

Coming back to the difference between ThinLinc client versions: it looks like something changed starting with 4.19 in the client connection procedure that causes the server to briefly “see” a smaller available view area during reconnect. As a result, the server-side window manager (OpenBox in our case) starts moving windows into a “safe” position.

If I look closely at how the ThinLinc connection window appears and initializes, it seems that for the first few milliseconds it comes up with only a single-monitor width, and only shortly afterwards it expands to the full width (both monitors). There appears to be a short moment right after the connection is established where the server perceives a smaller desktop width, which then triggers OpenBox to relocate windows. When switching to another window manager like xfwm4, this relocation does not happen — likely because xfwm4 (and other WMs) either evaluate differently or wait a bit longer before enforcing window repositioning for windows outside the visible area.

Graphically, the difference between client 4.18 and 4.19 is also noticeable: starting with 4.19 there is a slight, visible flicker during session setup, which seems related to this window relocation behavior. With 4.18 (and earlier) I don’t see that.

So I’m wondering why the behavior changed in 4.19 when connecting/reconnecting to the ThinLinc server. Do you have any explanation for that? And would it be possible to review/diff the changes between client versions 4.18 and 4.19 to identify what might cause this different behavior in establishing the connection and in setting up the ThinLinc client window/fullscreen view? And of course, feel free to test with our ThinRoot OS yourself in which you just have to replace the ThinLinc client version form 4.18 to 4.20 to make the issue appear.

11

Ah. Given that setup, then this is not a multi monitor setup from the system’s point of view. So the issue will happen on a single monitor as well. It might just not be as noticeable.

I did some more testing with that in mind, and can see the same issue. The problem is that we’ve made resizing more responsive. Older versions had artificial delays, which could be annoying. But those delays apparently smoothed over some variations in window managers in how they implement full screen.

We’ll need to experiment and see if we can better detect when OpenBox is done adjusting the window for full-screen mode.

1 Like
12

This is great news that you are able to reproduce it given I provided a more detailed explanation! So please let me know once you have a workaround/fix for the issue integrated in some nightly/developer build of the ThinLinc client so that I can test it accordingly.

13

A fix for this is now included in the nightly builds of the client. Thanks @CendioOssman!

1 Like
14

Indeed! Many thanks to @CendioOssman for fixing the issue. I just integrated the latest nightly client build into our thinRoot system and now re-connecting to our ThinLinc server does not move windows around anymore. Great work! Looking forwarding to seeing this fixed anytime soon in the next official 4.21.0 version.

2 Likes