Skip to content
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

Not all monitors are working #8481

Closed
manio opened this issue Nov 27, 2024 · 8 comments
Closed

Not all monitors are working #8481

manio opened this issue Nov 27, 2024 · 8 comments
Labels
bug Not working as intended

Comments

@manio
Copy link
Contributor

manio commented Nov 27, 2024

  • Sway Version:

Latest git version

  • wlroots version:

applied https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4923

  • Debug Log:

https://skyboo.net/temp/sway/sway-not-starting3.log

  • Description
    It is starting, but only one graphic card is available from two (2 monitors working, 4 are black)

for the reference:
this bug started with my report in #8465, then it has moved to #8442 and after @emersion request I am creating this one

@manio manio added the bug Not working as intended label Nov 27, 2024
@manio
Copy link
Contributor Author

manio commented Nov 27, 2024

@emersion
If you like I can try to bisect this. This is related to sway only, not a wlroots. As when I downgrade only sway then it is working fine. New version is not working - only with your #4923 it is starting but not all monitors.

@emersion
Copy link
Member

This is a copy-paste of #8465, which is not helpful. When I asked to re-open an issue, I was asking about the stuff in #8442 (comment) instead.

@manio manio changed the title Cannot start after upgrade Not all monitors are working Nov 27, 2024
@manio
Copy link
Contributor Author

manio commented Nov 27, 2024

@emersion I've updated the issue body. Is it ok now?

@ethanalker
Copy link

I'm experiencing a similar (but possibly different) issue on sway 1.10. Making an app fullscreen on a second monitor doesn't work (screen freezes), and it also crashed a few times when playing around. It was fixed by downgrading. I'll give more detail and include logs when I get the chance (which might not be soon).

@manio
Copy link
Contributor Author

manio commented Nov 28, 2024

@emersion
As this is a regression (working with arch package 1:1.9-5, but not working with 1:1.10-1) so I was trying to bisect this to help you track the problem down.

Unfortunately I've encounter multiple problems:
I thought that I will just mark good/bad commit based on tags to begin the bisect process but I have to admit that I am a little lost in the development workflow:
I can see all tags and version branches but when I do a git log on specific tag, e.g. 1.10 then looking down there is a huge gap between tagged 1.10-rc1 and 1.6-rc2. Where is the 1.7, 1.8, 1.9?

I suspect that each release have own branch - so I need to compare branch-to-branch to make the bisect between those two versions? Is this possible?

Another problem is that each version needs specific wlroots which complicates the problem. Even when I am trying hard to match the version, then it seems I am doing something wrong, e.g.:
I am at sway tag v1.9 and it is telling me:
Dependency wlroots found: NO found 0.18.0-dev but need: '>=0.17.0', '<0.18.0' (overridden)
It is telling me needs version >=0.17 and < 0.18. When I checkout wlroots 0.17 it can't compile:
https://pastebin.com/D3HXrT13
but when I choose 0.18 then it is also complaining (because it is too high). I tested something in the middle and also can't compile :(

@emersion
Copy link
Member

Does this help? https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4930

Relevant part of the log:

00:00:00.593 [DEBUG] [wlr] [types/wlr_output_swapchain_manager.c:160] Preparing test commit for 6 outputs with explicit modifiers
00:00:00.593 [DEBUG] [wlr] [types/output/render.c:194] Failed to pick output format

I suspect that each release have own branch

Yes

so I need to compare branch-to-branch to make the bisect between those two versions? Is this possible?

You can probably compare with the base commit each branch is based on.

Another problem is that each version needs specific wlroots which complicates the problem

Yes, this makes it pretty tricky to bisect. Sway master branch tracks wlroots master, which means each time a breaking wlroots change is made, a matching Sway change is made. This PR contains a script to checkout the right wlroots commit: #8347

@manio
Copy link
Contributor Author

manio commented Nov 29, 2024

@emersion
This was it! All monitors are working now :)
Thank you! Closing.

@manio manio closed this as completed Nov 29, 2024
@manio
Copy link
Contributor Author

manio commented Dec 1, 2024

@emersion
Can I somehow configure a display/all displays as non-hotplug? I have a static configuration - all 6 monitors are constantly connected.

I have a problem using this new sway version that is it far more "sensitive" to turning ON/OFF the TV set (I am using one as a monitor). I can see that all windows/workspaces from this TV is going to another monitor, then on DPMS-ON after some seconds it is going back to TV. I didn't notice it with earlier sway version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Not working as intended
Development

No branches or pull requests

3 participants