Cannot init renderer for external monitor on i915 (Requested display configuration exceeds system DDB limitations) #1877
Comments
|
Can you do this from a TTY: echo 0xFE | sudo tee /sys/module/drm/parameters/debug # Enable verbose DRM logging
sudo dmesg -C
dmesg -f >dmesg.log & # Continuously write DRM logs to a file
sway -d >sway.log 2>&1 # Run sway with the external monitor plugged, don't move the mouse, exit immediately when sway has started
fg # Kill dmesg with Ctrl+C
echo 0x00 | sudo tee /sys/module/drm/parameters/debug |
|
So, the external monitor works fine if it is attached when sway is started. I followed your instructions (through Do you want me to try anything different knowing this, or should I still try the scenario you suggested (start with ext monitor attached) even if it works normally? |
Oh, right, sorry about that, typo on my end. Can you try enabling DRM debug logs, starting sway without the external monitor, plugging it to reproduce the issue, then quit sway? |
|
This is a good copy/pastable one-liner. Run it, kill sway, tap ctrl-c, done: I don't see much jumping out at me, other than this. These fastset errors from the drm dmesg log pop up around the time of the atomic commit failing: |
|
Weird. Seems like we're still using Y_TILED even when we fallback to no modifiers. |
|
Would bisecting this help? |
|
Version 0.7.0-1 of wlroots works for me on archlinux with sway 1.2-5. I couldn't figure out how to get wlroots tag 0.7.0 to compile, but you can get the old version of the package from http://archive.virtapi.org/packages/w/wlroots/wlroots-0.7.0-1-x86_64.pkg.tar.xz if you need a working system. |
|
Thanks @jivox92362 but this doesn't block me, fortunately. If I have the output present when I start Sway... it will generally work. I might have to hotplug the monitor, it will work. However, if the output is not connected when Sway starts, I don't seem to ever get it to work until quitting and restarting sway. |
|
@emersion I'm seeing the same issue, but only with my second external monitor. I've attached the files you requested above. |
|
Any update on this issue? I can do another capture if it would help. |
|
Apparently Sway tries to use Maybe we need to re-allocate other FBs without modifiers as well. We have no way to know why an atomic commit failed from userspace, so some guessing will be involved anyway. This will be difficult to implement with the current wlroots architecture. It's something I've definitely been thinking about though and I have in mind for the future. As a workaround, adding an env variable to disable modifiers is probably a reasonable idea. This would short-circuit the logic here: https://github.com/swaywm/wlroots/blob/master/backend/drm/drm.c#L606 Patches to do this are welcome. |
|
@emersion I appreciate work you've done in looking at this. I wanted to share an odd workaround I seem to have found. To get the second monitor working I can do this:
I'm not sure if some steps are not needed, I may try to distill later. I'll attach my sway.log here in case it helps. I could do a |
|
Not sure if it's related, but I noticed from my |
|
This indicates that X with the modesetting driver was started, see https://patchwork.kernel.org/patch/11133739/ |
|
There is a zero percent chance that I'm starting sway under X. I run it
from a tty.
…On Mon, Jan 20, 2020, 08:02 Rouven Czerwinski ***@***.***> wrote:
This indicates that X with the modesetting driver was started, see
https://patchwork.kernel.org/patch/11133739/ Are you starting sway on X11?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1877?email_source=notifications&email_token=AACP25HWAFMKQBSNEXQA6P3Q6XDI5A5CNFSM4JFLKCGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJNDFWY#issuecomment-576336603>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACP25BKJDGHJPSPSVZZCQTQ6XDI5ANCNFSM4JFLKCGA>
.
|
|
Sorry, I meant to respond to the comment above which mentions the dmesg line. I did not quote unfortunately. |
|
@Emantor I'm following the list of steps in #1877 (comment). It's the only way I've found to get both external monitors working. I start sway on VT1, only 1 monitor starts. I switch to VT2 and start xorg. I switch back to VT1 and unplug-replug in my second monitor, and the second monitor starts working. I suspect it has something to do with how xorg is setting up the display. Switching to VT2 and back without starting X isn't enough even though I the 3 monitors work in the terminal in VT2. |
|
Please try #2009 while setting |
|
@Emantor Env works perfectly for me both when starting sway with the monitors plugged in, and when plugging them in afterwards. Thank you! |
|
Interesting. This confirms my guesses in #1877 (comment). |
I was affected by this, can confirm #2009 fixes it. On Arch Linux, you can just build and install |
|
Hello, im using wlroots on a project and can confirm this happens when plugging my external monitor in after booting the compositor. The env var workaround helps in the short term. |
|
My 2cents - the env var helps minimize the issue for me, but it still
occurs.
I've also noticed that this issue is MUCH worse when 'iris' is used instead
of the classic 'i915', maybe that will help others avoid this too.
…On Sat, Feb 8, 2020, 13:17 nitaigao ***@***.***> wrote:
im using wlroots on a project and can confirm this happens when plugging
my external monitor in. The env var workaround helps.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1877?email_source=notifications&email_token=AACP25DMPXHPYVVFYDQZUBTRB4ONTA5CNFSM4JFLKCGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELF33LA#issuecomment-583777708>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACP25APXJIQFQRC2B7XT4LRB4ONTANCNFSM4JFLKCGA>
.
|
|
Sway 1.4 I'm experiencing this too and it exhibits some interesting behaviour. In particular the following statements are true for me:
Having enabled DRM debug output my replication is in line with those above--roughly: I did however perform a comparison of its output when entering Sway with the monitor already connected (which works) vs hotplugging the monitor whilst already in Sway (which does not). I was interested to see that Sway seemed to take the same actions in both situations but that in the failing case it was using pipe C instead of B (see attached), and that after exiting Sway the tty KMS seemed to use B. I don't have a good enough understanding of CRTC allocation to know whether or not this is of significance. |
emersion
changed the title
emersion
changed the title
emersion
changed the title
|
The planned fix for this issue is #1873, however it requires a few architectural changes to wlroots. |
|
Running this does not fix it: WorkaroundI've this in my config: Closing the lid and re-opening it makes screen come back to life. Hopefully this'll serve as a workaround for others. Note: If you ever run |
|
It might be working if your laptop is going to sleep then waking up again? |
|
Nope, sleeping / suspending the laptop does not help |
|
64a2ca4 may help making |
|
Hm, disregard, I just need more coffee. |
Possibly due to sway exceeding intel bandwidth limits, by allocating new buffers before releasing old ones. See: swaywm/wlroots#1877, swaywm/sway#5008 and swaywm/wlroots#1873
|
Closing as a duplicate of #1873. |
and others
This is from the debug logs, after I've plugged in an external monitor, waited, and then tried to enable via an IPC command:
This used to work.
The text was updated successfully, but these errors were encountered: