Multi Monitor Management is broken #10

Closed romangg closed 7 months ago

In GitLab by @Sebastian-Hirsch on Aug 1, 2020, 13:20

I have tried kwinft and it's components right now and had serious issues running it.

I Don't know if this is the right component to report this so please tell me if it belongs elsewhere.

I have two 24 inch monitors with UHD Resolution, 60Hz refresh rate and 200% global scaling. I run them side by side. The issues I have are the following:

After first start, the resolution and arrangement are correct, but only the cursor runs at 60fps, everything else runs at 30fps for no known reason.
After changing the refresh rate in the settings to 30Hz everything runs at 30Hz like you would expect.
After changing back both monitors to 60Hz, they run at 60Hz, but the display output is broken. The first monitor is divided in the middle and it looks like the other half gets treated as the second monitor. The second monitor has this issue too.
After a reboot, the content of all monitors are zoomed and the resolution is wrong. After changing the resolution and refresh rate, point 2 and 3 get repeated and I'm unable to configure my monitor setup properly.

I have used the wayland session. If there are any debug outputs I can provide, please tell me how to so that I can help with proper debug output. As I am not a QT/C++ Programmer I can't really help fixing the code. But I will try to help as much as I can.

If you need more information, please ask!

I have the following setup:

OS: Arch Linux Kernel: 5.7.11 Mesa: 20.1.4 GPU: Radeon RX Vega 56 Plasma: 5.19.4 Qt: 5.15 KwinFT: Git from first august 2020 Disman: Git from first august 2020 KDisplay: Git from first august 2020 Wrapland: Git from first august 2020

I have tried kwinft and it's components right now and had serious issues running it.

Thanks for trying it out. Sorry for the problems you encountered.

I Don't know if this is the right component to report this so please tell me if it belongs elsewhere.

Yes, this is the right component. Disman sends output configurations received from KDisplay to KWinFT. In theory the issue could also lie in KDisplay or KWinFT, but Disman is a good starting point.

KwinFT: Git from first august 2020 Disman: Git from first august 2020 KDisplay: Git from first august 2020 Wrapland: Git from first august 2020

That's great. By incident I just started two days ago to work on #6. Current progress is here: https://gitlab.com/romangg/disman/-/commits/auxiliary-properties/

With this work I plan to iron out remaining issues that there are with output management. I noticed also a few in the past when I did connect multiple outputs and the new design should allow us to have perfect results in the end.

If you want to help with that it would be extremely helpful if you can try out above branch from time to time and write down your experience (prior bugs fixed, new regressions). At some point, when the API breaks changes will be needed for KDisplay too. I will tell you about it then.

Important debugging techniques for Disman and KDisplay are the following:

Write Qt logging categories levels to $HOME/.config/QtProject/qtlogging.ini:
```
disman*=true
kdisplay*=true
```
Restart Disman's D-Bus backend launcher process to see its debug output:
```
killall -9 disman_backend_launcher ; disman_backend_launcher
```
Restart the KDE daemon process to see the KDisplay daemon debug output:
```
killall -9 kded5 ; kded5
```
Start the KDisplay KCM, try something, check its debug output:
```
kcmshell5 kcm_kdisplay
```

Note that on master branch the Wayland session is run without the D-Bus backend process, but I'm planning to change this with #6. Above branch already includes this change.

Debugging KWinFT is a bit more difficult since for outputs it only really makes sense via an SSH session to a VT. You can read this blog post about developing/testing KWin what can be transferred to KWinFT one-to-one. But as a first step (and as long as KWinFT is not crashing) it would be enough to try above debugging of Disman and KDisplay.

In GitLab by @Sebastian-Hirsch on Aug 1, 2020, 18:56

Thank for the answer @romangg ! I will reinstall kwinft and its dependencies and try it out. The pkgbuild for disman-git seems to have a configurable git url with an preconfigured branch. Icould try to set the branch to the one you mentioned. Is there any way to control if the code got compiled with the correct branch?

I will try to setup a test pc for debugging and trying out different distros soon. So I don't have to break my main pc.

I will try to test it tomorrow.

Is there any way to control if the code got compiled with the correct branch?

Most safe is to add to the PKGBUILD source checkout

qDebug() << "XXXXXXXX THIS IS WHAT YOU'RE LOOKING FOR";

here in the constructor body and start KDisplay KCM as seen above. Then grep for the XXX. If it's there the compilation of the code was succesful.

Maybe it's easier to just directly git-clone the repo with

git clone https://gitlab.com/kwinft/disman.git

and repeat the steps from the PKGBUILD in there manually.

In GitLab by @Sebastian-Hirsch on Aug 1, 2020, 21:48

I tried the disman branch now and it still was really odd. I kinda managed to get my setup to work but it was more like randomly setting options instead of properly working. The symptoms described in the first comment still showed.

The killall -9 disman_backend_launcher ; disman_backend_launcher command did not work (see screenshot).

The other commands didn't reveal anything useful. I will try to recreate the issue and send the output.

The windows flicker with kwinft a lot and get often invisible. It was really hard to write this with kwinft, but that's a different issue.

Screenshot_20200801_214332

In GitLab by @Sebastian-Hirsch on Aug 1, 2020, 21:53

Okay, I could recreate the issue and got this output from the killall -9 kded5 ; kded5 line:

kdisplay.kded:  Failed to find a matching mode - this means that our config is corruptedor a different device with the same serial number has been connected (very unlikely).Falling back to preferred modes.
kdisplay.kded:  Failed to find a matching mode - this means that our config is corruptedor a different device with the same serial number has been connected (very unlikely).Falling back to preferred modes.

I set the refresh rate for both displays to 30Hz and back to 60Hz. I added an camera image of the desktop as spectacle can't capture the corrupted desktop. I hope this gives a bit more information.

I still only tested everything with the wayland session.

Please move the directory $HOME/.local/share/kdisplay to a different directorym for example to $HOME/kdisplay-config-backup and then restart the session without disconnecting any display.

Then start the KCM again, change some arbitrary value and see which files have been recreated in $HOME/.local/share/kdisplay.

Paste the content of these recreated files here and also from the files with the same name in $HOME/kdisplay-config-backup (there will likely be other configuration files too that were created for other combinations of displays you were at one point in the past running, for example for a single display being connected only).

In GitLab by @Sebastian-Hirsch on Aug 1, 2020, 22:16

Okay, deleting this folder fixes the setup. I have created zip files of the folder with the names, you suggested.

kdisplay.zip

kdisplay-config-backup.zip

In GitLab by @Sebastian-Hirsch on Aug 2, 2020, 10:14

After a reboot, the multi-monitor setup was broken again.

That's bad on one side but also good on the other since the issue is reproducible it seems. You can upload the current configuration after reboot (in the broken state) again?

In GitLab by @Sebastian-Hirsch on Aug 2, 2020, 10:35

Here are the config files.

kdisplay_1.zip

I decided to flesh this out some more and create chapters for that in KWinFT, Disman and KDisplay CONTRIBUTING.md documents.

If you wanna check them out (not yet on master, links between the documents therefore not yet working):

Feedback welcome!

Yea that was my fault, the binary must be executed directly by path. See the documentation drafts I have above:

https://gitlab.com/romangg/disman/-/blob/auxiliary-properties/CONTRIBUTING.md#dismans-d-bus-backend-service

The config files look pretty normal. In the first one the refresh rate is set to 30 but other than that there is no major difference.

Give me some time to work on the auxiliary-properties branch and I'll tell you when it's a good time to test it (probably not today though anymore).

In GitLab by @Sebastian-Hirsch on Aug 2, 2020, 11:56

Okay, no problem ;-). The thing is, both monitors should run at 60Hz, so it is odd, that they get configured as 30Hz.

In GitLab by @Sebastian-Hirsch on Aug 2, 2020, 11:59

Thanks for your effort. When i finished preparing my test pc i will try this out. The pc is probably ready at the end of the week.

But again, thanks for the documentation. This is especially useful for newcomers!

If possible please test out the branches in https://gitlab.com/kwinft/disman/-/issues/6#note_391457432. The branches are now in a somewhat complete state. Haven't tested much stability yet though.

There are a few open tasks still listed but especially the one to move all config handling to Disman I will likely put into a separate GitLab issue and then tackle the other ones with that together.

In GitLab by @Sebastian-Hirsch on Aug 6, 2020, 14:31

Okay, I updated everything an it seems to work at first try :smiley: . But I can't open the display settings in the system settings as they crash when I try to open them.

Indeed they crash for me too. I only always tested with kcmshell5 kcm_kdisplay. This way it works for you too, right?

Thanks for testing! :)

Backtrace:

#5  0x00007f38900d9b0b in Disman::Config::connectedOutputs (this=0x0) at
/home/roman/dev/kde/disman/src/src/config.cpp:296

In GitLab by @Sebastian-Hirsch on Aug 6, 2020, 14:51

Opening it with your command does crash too. The backtrace is visible in the image. Screenshot_20200806_144919

Ok, you have also compiled KDisplay from the branch https://gitlab.com/romangg/kdisplay/-/commits/auxiliary-properties, right?

Then please do coredumpctl gdb for the backtrace (above is just the log) as explained here: https://gitlab.com/romangg/kwinft/-/blob/debug-docs/CONTRIBUTING.md#access-backtrace-of-past-crashes

In GitLab by @Sebastian-Hirsch on Aug 6, 2020, 15:05

Okay, this is what I get. If I use anything different than kwin_wayland, it can't find a match for a backtrace. Screenshot_20200806_150324

To see all backtraces just issue first coredumpctl. You then get a list of all last coredumps which you scroll down. At the end are the most recent ones. You can read a PID from one of the columns to the process you want to trace. This PID number you then have to add to the command, something like: coredumpctl gdb 1234

And also please try DISMAN_BACKEND_INPROCESS=1 kcmshell5 kcm_kdisplay.

In GitLab by @Sebastian-Hirsch on Aug 6, 2020, 15:16

Okay, here is a backtrace of the kcm crash. Screenshot_20200806_151515

Ok, thanks. The backtrace sadly doesn't show so much. In most of it there are no debug signals. For Qt it's clear because you use the system libraries (Arch still has no debug signals for these compiled).

But there should be debug signals for Disman. Maybe they were unflagged at the compilation because the type of build is release instead of debug. Can you check your compilation settings in the PKGBUILD?

Anyways I've pushed a new version with which I can open the KCM from System Settings. Can you too? The kcmshell5 command now also working?

In GitLab by @Sebastian-Hirsch on Aug 6, 2020, 17:27

I have updated disman and kdisplay and compile them with the debug flag. I can now open the settings dialog. I will play around with the settings and see if i can break stuff. Thanks for your hard work!

On another note:

In X11 there was an option to set the primary monitor. In wayland this option is missing. I sthis a wayland specific issue or is this feature not implemented yet?

I have updated disman and kdisplay and compile them with the debug flag. I can now open the settings dialog. I will play around with the settings and see if i can break stuff.

Thanks for testing. One issue I noticed already is that when "replicating" an output the picture is not shown completely on the replicated one. Can you confirm that?

If you wanna check back if a bug you notice could be caused by broken settings file and to try to reproduce it from a clean state: the config files are (at the moment) in $HOME/.local/share/disman and $HOME/.local/share/kdisplay. If the next open bullet point in https://gitlab.com/kwinft/disman/-/issues/6#note_391457432 works out they will soon be only in the disman subdirectory anymore.

In X11 there was an option to set the primary monitor. In wayland this option is missing. I sthis a wayland specific issue or is this feature not implemented yet?

In Wayland we don't have a concept of "primary" monitor. At least from window manager perspective. Monitors are just random free floating views into the compositor plane. But I know there are issues often with the shell (i.e. where panels are placed and so on) so there should/must be a similar concept. But I didn't have time yet to think about how this concept could be reformulated in Wayland. Maybe wlroots have something like that already?

In GitLab by @Sebastian-Hirsch on Aug 6, 2020, 17:57

I have tested your changes a bit more thoroughly.

The good things:

The resolution, refresh rate and display setup gets correctly configured all the time. The auto settings work fine all the time.
I can change the screen scaling and it scales everything as expected
If I make a bad config and reset everything to auto, everything gets setup correctly

The bad things:

If I change the scaling factor, the wallpaper on the second display is too small. If I open and close some program windows it sometimes fixes itself (see image 1).
Setting a different resolution does not work. The resolution still seems native and the bottom panel and display layout seem broken (see image 2).
If I press the identify button, the texts on my monitors are very similar. This is probably because I have a pair of identical monitors. An easier to read string with model number and "monitor x" where x is a number would make things more ergonomic.

I can't replicate your issue with the replication option. Seems fine on my end. I have two identical 24 inch UHD monitors.

I tried to run the following from your improved documentation:

killall -9 disman_backend_launcher ; /usr/lib/disman_backend_launcher

But nothing gets logged. After running this I can't change any options in the settings either. They won't apply after pressing the apply button. A reboot and reapplying the changes fixes this issue. There are also no crashes or backtraces.

I there anything else I can do to get you some useful information?

Screenshot_20200806_172835

That's awesome QA testing and super-helpful! :)

Just wanna let you know that I'll check on every single issue and will try to reproduce them here. But probably won't have time for that today anymore. Gonna check on it tomorrow. Thanks!

But I can say some general stuff to two of these issues already:

If I change the scaling factor, the wallpaper on the second display is too small. If I open and close some program windows it sometimes fixes itself (see image 1).

Yes, I know this bug. But I don't think I can do much about that. That's likely in the plasmashell process an issue. But maybe the scaling factor is not correctly communicated on change from KWinFT to the clients, then I could fix it in KWinFT.

If I press the identify button, the texts on my monitors are very similar. This is probably because I have a pair of identical monitors. An easier to read string with model number and "monitor x" where x is a number would make things more ergonomic.

Yea, the monitor names displayed in a Wayland session are shit anyway. I'll try to come up with something better but has low-priority for me at the moment (first need to get the basic operation right).

I can't replicate your issue with the replication option. Seems fine on my end. I have two identical 24 inch UHD monitors.

That's probably because they are identical. Try rotating one of the displays in KDisplay and then replicate the other one. You need additionally following patches though for KWinFT to not break: https://gitlab.com/kwinft/kwinft/-/merge_requests/34

If you like to you can try again the Disman and KDisplay branches. They changed quite a lot again. I decided to directly go with the full config-move to Disman. That means it should be possible to use it without any permanently active frontend like the KDisplay daemon. Have to test it in a sway session.

I'm currently working on some issues with Xwayland (might be in parts patches to Xwayland directly, see https://gitlab.com/kwinft/kwinft/-/issues/65) but the current state of the branches should be good or at least interesting.

I haven't tested X11 very much yet and not at all the KWayland backend with KWin.

In GitLab by @Sebastian-Hirsch on Aug 10, 2020, 20:36

I will test when everything for my new test pc is there. As I can connect all my monitors now to my test pc I can test a lot more scenarios. The new test pc allows me to test the kwinft components without breaking my work desktop anymore. The stuff should arrive on wednesday, then I will test the new updates. I can now also test mixed dpi setups. I will write a response when I am done testing.

One more controversial note: I think the development should completely focus on wayland and the X11 should be dropped as it is legacy tech. Xwayland support is important for backward compatibility. Whats your take on this? (I know its offtopic, but I am interested in your opinion on this matter)

Thanks again for your effort!

I think the development should completely focus on wayland and the X11 should be dropped as it is legacy tech.

I agree with that note in the sense that if X11 support is in the way of improving the Wayland session we should not care about the X11 support.

As long as the support for it is not too much of a burden I keep it around as it is useful for comparison but especially with the planned library split-out the support for it might be dropped rather sooner than later.

In GitLab by @sibbe.racer on Aug 12, 2020, 18:09

My new test pc is now mostly ready and I ran the current code of disman, kdisplay and kwinft.

My setup is now as follows:

OS: Arch Linux Plasma Version 5.19.4 GPU: Radeon Pro WX4100 Kernel: Linux-Zen 5.7.12 Monitors: 3 Monitors, one with FullHD Resolution, the others with UHD Resolution, so its a mixed DPI setup Session: Wayland

The good stuff:

All screens where detected.
The dpi configuration was fully automatic and worked flawless.
The resolutions and refresh rates got configured correctly.
Screen replication worked perfectly fine, see the bad stuff below.
All screens could be rotated.

The bad stuff:

When unplugging and replugging displays into the gpu, the session would often crash and sent me to the login screen.
At first all monitors where layouted on one another in the settings, which effectively cloned the outputs (even though they were correctly cloned). Rearranging them fixed the issue, its just a weird default.
The performance is kinda all over the place. sometimes very smooth, sometimes sluggish and slow. The gpu is no powerhouse but should be capable to handle this setup smoothly.
To not be able to tell where the windows of applications should open is very annoying. With three monitors having them open in more or less random locations is things very tedious. An option to atleast open windows in the center of the screen like gnome has would make it a bit less of an issue as the window placement can be predicted at least a bit.
The windows on the scaled monitor outputs are sometimes blurry. Clicking on them or trying to resize them can fix this. On the FullHD screen without scaling the windows are always sharp
The wallpaper scaling bug after changing the display settings is still there
When a screen was rotated, my cursor was trapped on a different screen and only an logout + login could fix this issue. The issue could also be fixed by rotation the rotated screen back to its default state. Then it could be accessed again.
Changing the resolution of a screen still does not work.

Some points got already mentioned but I wanted to list them to have a complete list. Is there an possibility to write a kwin crash log to a file? I think the output could help you but I don't know how to do it.

I hope this helps a bit. Should I make a tasklist to make it easier to mark problems as solved?

Radeon Pro WX4100

Interesting choice. GFX industry?

At first all monitors where layouted on one another in the settings, which effectively cloned the outputs (even though they were correctly cloned). Rearranging them fixed the issue, its just a weird default.

That sounds like Disman's Generator is not doing its job on first startup when no config was saved yet. Can you delete or move all the config files from its config directory ($HOME/.local/share/disman) and then log what Disman is doing on the next session start from VT or via SDDM (then it should be logged to $HOME/.local/share/sddm/wayland-session).

The performance is kinda all over the place. sometimes very smooth, sometimes sluggish and slow. The gpu is no powerhouse but should be capable to handle this setup smoothly.

That's difficult to debug and probably not related to my current work in Disman/KDisplay. The compositing pipeline of KWinFT still sucks. I want to look into improving it in my next steps with the library split-out. But will be a multi-months project.

To not be able to tell where the windows of applications should open is very annoying. With three monitors having them open in more or less random locations is things very tedious. An option to atleast open windows in the center of the screen like gnome has would make it a bit less of an issue as the window placement can be predicted at least a bit.

Yes, the usability is shit but I can't concentrate on improving that very soon.

The windows on the scaled monitor outputs are sometimes blurry. Clicking on them or trying to resize them can fix this. On the FullHD screen without scaling the windows are always sharp

I noticed that too. We are talking only about Wayland native apps, right? Xwayland will be blurry in any case. The Wayland native ones are only Qt apps? I have a suspicion the Qt Wayland client library has a bug not updating the client scale correctly.

The wallpaper scaling bug after changing the display settings is still there

Could be plasma-workspace, i.e. not KWinFT.

When a screen was rotated, my cursor was trapped on a different screen and only an logout + login could fix this issue. The issue could also be fixed by rotation the rotated screen back to its default state. Then it could be accessed again.

Was there a gap between the displays?

Changing the resolution of a screen still does not work.

I can't reproduce this issue. It's only on one of your 3 displays?

Is there an possibility to write a kwin crash log to a file?

For the crashes best would be the backtrace you get via GDB. Especially for the unplugging/replugging session crash this would be helpful.

Should I make a tasklist to make it easier to mark problems as solved?

Let's keep it here as long as the work branches are not merged to master yet.

In GitLab by @sibbe.racer on Aug 12, 2020, 20:07

Interesting choice. GFX industry?

No, I just needed a low profile gpu with a lot of uhd capable display outputs. got it used very cheap.

That sounds like Disman's Generator is not doing its job on first startup when no config was saved yet. Can you delete or move all the config files from its config directory ($HOME/.local/share/disman) and then log what Disman is doing on the next session start from VT or via SDDM (then it should be logged to $HOME/.local/share/sddm/wayland-session).

Odd, after deleting the directory it arranged the monitory better, but did not enable scaling on the UHD monitors. Perhaps the old config before the new code confused disman?

I noticed that too. We are talking only about Wayland native apps, right? Xwayland will be blurry in any case. The Wayland native ones are only Qt apps? I have a suspicion the Qt Wayland client library has a bug not updating the client scale correctly.

I just launched qt apps like dolphin and kate and saw this behaviour. I launched kate with -platform wayland and it was the same.

Was there a gap between the displays?

Yes, putting them to one another fixed the issue. Would be good if the screens would be atomatically arranged without a gap after rotating them to not have this problem.

I can't reproduce this issue. It's only on one of your 3 displays?

When I change the resolution on the FullHD screen to something like 1280x720 a part of the desktop bar gets shown on it and the resolution does not change. When I change the resolution on one of the UHD screens and set the scaling back to 100% the session crashed and I was sent to the login screen. I tried to get a crash dump, but I can't get anything useful, see screenshot.

Wait, I build the packages with the release and not debug config. I will recompile them. Then the core dumps should be more useful.

Sadly the kwin dumps aren't any more useful after compiling with the cmake debug flag.

Screenshot_20200812_200451 session_logs.zip

Hey, sorry for late reply and that I now come up with even more branches to compile but that's a big one: I worked since Wednesday on a patch series for Wrapland that changes the server output API and the internal handling of wl_globals fundamentally. I only tried it for around 10 seconds now in a live session but the unit tests pass and that in general is a good sign.

If you wanna test them out (together with the patch series for Disman and KDisplay) compile the branches from these two merge requests:

In GitLab by @sibbe.racer on Aug 16, 2020, 11:12

Okay, I had some time to test your new code. I recompiled kwinft, wrapland, kdisplay and disman.

Here are my new findings.

The good things:

The session does not crash anymore when re- and unplugging screens. Awesome!
Changing resolutions does not crash the session anymore!

The odd thing:

When unplugging the screen with the taskbar, it goes to another screen, seemingly at random. That's okay, but there is no option to out it back on the wanted screen after the other screen got replugged. This should be related to not be able to determine a primary screen, right? Also graphical effects like blur got disabled. Just changing the opengl mode in the compositor settings fixed the issue.

The bad thing:

Even though the session does not crash after changing the resolution of a screen, the resolution still does not change. The screen stays at its native resolution.

All in all another nice improvement in the matter of multi monitor support! It gets better with every update and that's nice to see.

When unplugging the screen with the taskbar, it goes to another screen, seemingly at random. That's okay, but there is no option to out it back on the wanted screen after the other screen got replugged. This should be related to not be able to determine a primary screen, right?

Yes, that's related to the missing concept of a primary screen. In the end it's not KWinFT's decision on which output which panels are placed. plasmashell does this and at least in the past to my knowledge it did this on X11 with the primary-output concept.

An alternative (even better) would be that plasmashell knows about all current outputs and then puts panels where they were before. For that it needs to get information about what outputs are connected and identifies them.

It might be the case that on Wayland plasmashell/Qt this is done via the name-field of xdg-output v2 which is currently supported in KWin but not yet in KWinFT (but what will be easy to implement with the new master-output class concept, I've created https://gitlab.com/kwinft/wrapland/-/issues/71 for that). At least for widgets that's the case according to the commit message. Don't know if that also includes panels but as soon as there is a first prototype of the implementation you could try it out.

Also graphical effects like blur got disabled. Just changing the opengl mode in the compositor settings fixed the issue.

That's an odd one. On an output unplugging? The KWinFT log would be helpful I think.

Even though the session does not crash after changing the resolution of a screen, the resolution still does not change. The screen stays at its native resolution.

I would really like to fix this. But this didn't happen to me once on my test machine. Maybe the KWinFT log would help here too.

All in all another nice improvement in the matter of multi monitor support! It gets better with every update and that's nice to see.

Great to hear. Thanks for testing. I'm now somewhat happy with the current state of the branches and will merge to master later today so we can continue work directly on master instead of on the separate work branches. I would then make the commit automatically close the issue here and for the remaining ones you mentioned we can work in separate issue tickets. The number of such looks to be low enough now.

In GitLab by @sibbe.racer on Aug 16, 2020, 12:33

Great to hear. Thanks for testing. I'm now somewhat happy with the current state of the branches and will merge to master later today so we can continue work directly on master instead of on the separate work branches. I would then make the commit automatically close the issue here and for the remaining ones you mentioned we can work in separate issue tickets. The number of such looks to be low enough now.

That would be good! Can you create and categorize them?

I would really like to fix this. But this didn't happen to me once on my test machine. Maybe the KWinFT log would help here too.

Here is a zip file with sddm session log and the complete journalctl output. Is there any way I could provide better logs/traces? Is there a better procedure?

logs.zip

The best way would be to isolate the occurrence of the issue in that only to log the point in time the issue occurs.

You can do that by running the Plasma session from a VT via SSH and watch and segragate (by pressing enter before that a few times) the log spilled out at the point in time.

Detailed instructions on how to do that is now available in KWinFT's CONTRIBUTING doc: https://gitlab.com/kwinft/kwinft/-/blob/master/CONTRIBUTING.md#logging-and-debugging

So step by step:

Make sure all Qt logging classes of KWinFT are enabled (see above document).
Remove all Disman control files.
Start a new session via SSH (see above document).
Press enter few times in the SSH output to have a visual gap in the live log.
Change the resolution.
Paste the log output.

You can also paste the output of the Disman D-Bus service and KDisplay (see links in this earlier reply how to do that best).

In GitLab by @Sebastian-Hirsch on Aug 16, 2020, 13:40

I tried to login with a ssh session, which worked, but after I start a plasma-session, nothing happens anymore neither on the ssh client, nor on the server. On the server I logged out and was only on the login screen.

I attached a screenshot to show the issue.

Screenshot_20200816_133825

There is not much log going on. The last line at least tells us that thekwin_wayland binary has been executed because it's part of the source.

Only thing that comes to mind is to try first to run KWinFT alone without the whole Plasma session via

dbus-run-session kwin_wayland --xwayland --exit-with-session konsole

Making that work would be a first step (and actually you could then test in there by running the KDisplay KCM with the DISMAN_IN_PROCESS env variable without the D-Bus service).

mentioned in commit d5ee6c7d47db94348bafc67053c7f37add2b702f

In GitLab by @sibbe.racer on Aug 16, 2020, 15:34

I could finally launch a plasma session from ssh. The solution was to use screen to set the session and not the xdg stuff. Sadly when running ssh in console, the scroll buffer gets not written to file so i can't retrieve crashes. The good thing is I could use systemctl to get a log with crash info. i hope it helps.

crash2.log

The systemctl log does not contain KWinFT's log.

Regarding the xdg stuff: Did you actually query the XDG_SESSION_ID variable from the VT before setting it in the SSH session? I.e. the XDG_SESSION_ID=6 was after a echo $XDG_SESSION_ID on the VT and it returned 6.

You can write everythign a process spits out to console also simultaneously to a file with some piping through tee. Here:

dbus-run-session startplasma-wayland 2>&1 | tee your-log-file.log

But with the XDG_SESSION_ID workflow you could just copy-paste from the SSH terminal of course (Screen probably also has some kind of buffer you could copy).

In GitLab by @sibbe.racer on Aug 16, 2020, 15:42

Yes I have did that with the ID. It didn't work for me.

In GitLab by @sibbe.racer on Aug 16, 2020, 15:53

I could finally retrieve useful logs for kwin. The issue was, that coredumpctl truncated the kwin coredumps because they where too large. After lifting the limits I finally got a more useful coredump. And thanks for the tee command, that seemed to work fine too. Here are some better logs!

more_useful_logs.zip

The issue was, that coredumpctl truncated the kwin coredumps because they where too large.

Oh yeah, I always have to do that in the beginning too. It's a common issue. If you want to you can create a docs-commit to draw attention to that in the GDB-debugging section in the CONTRIBUTING.md document of KWinFT.

After lifting the limits I finally got a more useful coredump.

Yes, that's a nice backtrace. Since you compile from code it should be also even possible to output the exact line number in the source code where we were in each step. Also step 4 has has no information about the function although it's still inside libkwin.so.5. Maybe you can enable this through CMake somehow? Is it already set to being a debug build?

I assume both files are about the same crash, one showing the program log and the other the backtrace. I'm a bit confused: this is an assert being triggered what will shut down KWinFT. But you said earlier that only the resolution is not changed while the session itself stays up. Is this about a different issue?

In GitLab by @Sebastian-Hirsch on Aug 16, 2020, 20:04

Maybe you can enable this through CMake somehow? Is it already set to being a debug build?

I enabled the debug build in CMake already. I don't know of anything else I could add to CMake. I set all the options in the qtlogging file as well. Do you know of anything?

But you said earlier that only the resolution is not changed while the session itself stays up. Is this about a different issue?

It's really odd sometimes just nothing happens, sometimes the session crashes when changing the resolution. I can't really tell if they are different issues.

In GitLab by @Sebastian-Hirsch on Aug 16, 2020, 20:05

I think it would be good to open a separate issue for this as this issue is closed and it is seemingly not about multi monitor setups.

Can you open a new issue?

winft / disman

Multi Monitor Management is broken #10