-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
modes
array for output keeps growing
#5044
Comments
Have been stepping through sway and swaymsg with gdb but haven't been able to pinpoint anything yet. Interestingly, apart from get_tree and get_outputs, all the other commands work, even though they are all using the same socket fd... :/ |
OK I finally pinpointed it down. The server is shutting down the IPC connection because the response is too large (just over 4MB) (ipc-server:912 I dumped the response contents using gdb: The reason the response is so large is because the modes array for one of my three monitors has tens of thousands of entries:
@emersion Any pointers on how to continue debugging this issue? I have no idea why it's reporting so many different (refresh) modes. |
Eh, that's pretty interesting. It's a good thing that swaywm/wlroots#1968 has been merged, otherwise all these modes would have been sent to each client. Can you check whether https://github.com/ascent12/drm_info reports also these modes? And can you try reading the EDID with https://git.linuxtv.org/edid-decode.git/ too? |
I restarted my computer before I could check the output of those commands, but it just happened again so here they are: before=output of the command from 2 days ago drm_info -j (it cuts off at 612 lines if not in JSON format) Both appear to be the same to me. |
This seems like an amdgpu bug to me. |
Starting two days ago, I ran You can see the output start growing in size after the March 3 00:47 entry. cat swaymsg_getoutputs_382 | jq -r '.[] | select(.name=="HDMI-A-1")' | rg "refresh" | wc -l |
@emersion Was there something in the output that made you think that? |
Yes, the kernel reporting duplicate modes (see drm_info output). Please report this to amdgpu. |
OK, I will see if I can get around to reporting it to amdgpu sometime soon. Although I wonder what triggers sway to start increasing the |
Wait, can you dump your configuration? Do you use |
My config is here Not using --custom |
I see. Are you sure the drm_info output doesn't grow? |
I could try get a sway debug log as well, but I need something will autorotate/trim the log file while sway is running, otherwise it gets too big too soon and I don't have much HDD space at the moment. Would you happen to have any recommendations for that? |
This time I ran drm_info at the same time. The output of drm_size doesn't balloon, but it does fluctuate a little bit (haven't checked the actual files yet but I think the suspect monitor is dropping in and out), and when those fluctuations happen it affects sway. I may have a way to be able to trigger this without leaving it all day, so in that case I can provide a sway debug log as well. |
Haven't had time to cull it down further, but this is my sway debug log (cut columns to 150 chars): https://gist.github.com/324282fc87fdc32bded8b49972bf4143 The monitor in question (HDMI-A-1) is connecting/disconnecting a lot. I guess every time the modeset is requested it keeps adding the modes to the ever-growing
This is the size of
I will have a further look tomorrow to see if there is a smoking gun in the log. |
modes
array for output keeps growing
This suggests to me that the same modes are duplicated over and over again. @emersion Would checking for duplicates while building the modes_array JSON be an acceptable solution? Or is it just a bandaid fix? |
No, the root cause needs to be discovered. |
I believe I can reproduce this issue - in my case, it appears to coincide with a noticeable cursor lag when moving between window boundaries. Debug log here: https://gist.github.com/kliu128/8125d498a470f682726bce1389f80264 I'm using one HiDPI 3000x2000 internal monitor plus two HDMI monitors connected through separate USB-C adapters, which it seems every Linux display manager has choken on (GNOME refuses to use DPMS to turn them off, KDE Wayland thinks one of them disconnects whenever it turns off) except for sway for the most part. The issue seems to manifest primarily after using DPMS to turn off the displays and then waiting a long time. It seems like this cursor lag issue has also been seen on reddit, e.g. https://www.reddit.com/r/swaywm/comments/hf9b8r/cursor_lag_when_crossing_window_boundaries/, but not sure if it's the same cause. A temporary workaround I've found is to run |
I can easily reproduce by unplugging and plugging back HDMI cable in my AMD GPU connected to monitor through passive DVI-D to HDMI adapter. But |
Every now and again (usually after leaving the computer for several hours), I lose all ability to talk with the sway IPC, however it can work intermittently:
![image](https://user-images.githubusercontent.com/20397027/75349122-7b724f00-58e7-11ea-9fd3-1db4def1e9bb.png)
strace on the script when the above error has occurred, which seems like the sway server has gone:
![asciicast](https://camo.githubusercontent.com/d1884ba6aab7b1065999dbfa2edd6720091d175127ad8394eba5ab1f98e90b88/68747470733a2f2f61736369696e656d612e6f72672f612f59594a6a7a79314735586730786f4e3675304e325744426d4d2e737667)
For reference this is what normal output looks like:
![asciicast](https://camo.githubusercontent.com/9158816fcd0c1468562f2609b7a47708561c57803b0ff5334466cf021d43ec8b/68747470733a2f2f61736369696e656d612e6f72672f612f6a644e4e66474d587a4c70483663574c5652545a67454664782e737667)
So far the simplest way I have been able to reproduce this (albeit have only tried this once so maybe I just got lucky), was to have 5 terminals endlessly looping
swaymsg -t get_tree
and then leaving it until the next morning.Need some pointers on what else to try in order to pinpoint what is going on.
Environment
Possibly related to #5043
The text was updated successfully, but these errors were encountered: