i3 says "could not create graphical context" with TigerVNC on NixOS #2729
Comments
|
It looks like this is NixOS-specific... |
ghost
mentioned this issue
|
Just adding some diagnostic details. Error code 9 is The error is logged from here: https://github.com/i3/i3/blob/next/libi3/draw_util.c#L48, after the call to -- Shot in the dark as to a workaround: It's been a minute since I've used VNC, but maybe there's something going on with NixOS and not properly setting the X11 Display for the |
|
If I use the default xstartup with twm, I can at least launch xterm and qutebrowser over VNC. I'm not sure what all i3 expects in its environment and if NixOS might be missing something there, though. |
ghost
changed the title
|
I tested this with Debian and i3 appears to work well in this scenario. @sphaugh, are you able to build i3 from source? The branch in #2731 simply adds a log message based upon a wild hunch, if you're bored. Building is as simple as something like this (though I prefer to use |
|
Awesome works over VNC same as dwm, and I was able to start an i3 session with Arch environment, works with vncserver locally and remotely: https://gist.github.com/bf55e9f494741e59b7cb0ea639bd7fe7 |
|
@nmschulte I tried building from |
|
This should build from Maybe take a look at https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/window-managers/i3/default.nix and see if anything stands out? |
|
@Airblader, I wonder if a call to I didn't see anything in that description that stood out, except that I've never used the |
|
I don't think the call is expensive like that; it's certainly not the reason we left it out. One thing that makes VNCs »special« is their usually limited support of X extensions. Why the issue only comes up with nixOS, though – I don't know, either. |
|
What makes i3 different from other window managers like twm, dwm, and awesome, though? Because they all seem fine with VNC. |
|
Tried starting And this is what I see starting i3 from a bare xterm: |
|
My usual shotgun-debugging approach would be: Can you run i3 under XTrace? For example, instead of Did someone look at the log file yet? There are other errors showing up in there: Error 8 is BadMatch and 3 is BadWindow. Also, the difference of the sequence numbers here is just 1, so I guess the first error is an error while CreateWindow and the second one is then a following request that tried to use that window. |
|
@psychon xtrace didn't have any output, sorry. I tried playing with it for a little bit. I can open st and it works after I mouse click the screen, for some reason. But all other functional behavior of i3 is still borked. |
|
@sphaugh What does Expected output: Note that I can’t reproduce the issue on a Debian system with 1.7.0. I wonder what makes this NixOS-specific. |
|
Thanks for the log. Here’s the part where the error message in question originates: As per the request serial number, it is indeed the CreateWindow which fails. I think the Issue #2435 was the last time we talked about colormaps, I think. Could you provide the output of |
|
Okay, so the colormap is 0x20 in either case, but the CreateWindow in your dwm xtrace doesn’t specify the colormap explicitly. AFAIR, dwm is not actually a reparenting window manager, so could you post the same logs with awesome, please? Also, do things start working once you apply the following patch to i3? diff --git i/src/x.c w/src/x.c
index 09a60493..bfc48059 100644
--- i/src/x.c
+++ w/src/x.c
@@ -142,8 +142,8 @@ void x_con_init(Con *con) {
mask |= XCB_CW_EVENT_MASK;
values[3] = FRAME_EVENT_MASK & ~XCB_EVENT_MASK_ENTER_WINDOW;
- mask |= XCB_CW_COLORMAP;
- values[4] = win_colormap;
+ // mask |= XCB_CW_COLORMAP;
+ // values[4] = win_colormap;
Rect dims = {-15, -15, 10, 10};
xcb_window_t frame_id = create_window(conn, dims, con->depth, visual, XCB_WINDOW_CLASS_INPUT_OUTPUT, XCURSOR_CURSOR_POINTER, false, mask, values);
|
|
I tried the patch and it didn't have any effect. Think I'm out of gists but I can try again later if you need logs. |
|
@sphaugh (If you have not already done so), could you provide A working 000:<:044a: 56: Request(1): CreateWindow depth=0x18 window=0x0040001a parent=0x00000267 x=0 y=0 width=1 height=1 border-width=0 class=CopyFromParent(0x0000) visual=0x00000021 value-list={border-pixel=0x00000000 bit-gravity=NorthWest(0x01) override-redirect=true(0x01) event-mask=ButtonPress,ButtonRelease,EnterWindow,LeaveWindow,PointerMotion,Exposure,StructureNotify,SubstructureNotify,SubstructureRedirect,PropertyChange colormap=0x00000020 cursor=0x00400008} A non-working 000:<:02a3: 52: Request(1): CreateWindow depth=0x18 window=0x00400030 parent=0x00000267 x=-15 y=-15 width=10 height=10 border-width=0 class=InputOutput(0x0001) visual=0x00000178 value-list={background-pixel=0x00000000 border-pixel=0x00000000 override-redirect=true(0x01) event-mask=ButtonPress,ButtonRelease,PointerMotion,Exposure,StructureNotify,SubstructureNotify,SubstructureRedirect colormap=0x00000020} Awesome seems to use a different visual and that's the only (relevant) difference... awesome's visual: i3's visual: Looks identical to me?!? But why does depth=24 appear twice in the list of allowed depths of the root window? And why does this server have so many apparently identical visuals? |
|
Weird... The code handling CreateWindow is here: https://cgit.freedesktop.org/xorg/xserver/tree/dix/window.c?id=f23e65f96365706c69fa781b2c6cbf3203619c9f#n761
None of this applies to the case we are looking at, I think. That leaves non-hardcoded error returns.
|
|
OHHHH!!!!! I found it. Both awesome and i3 use the default colormap, 0x20. However, there is this check: So since the default colormap, 0x20, is created for the default visual, 0x21, the two can only be used together. However, i3 tries to use colormap 0x20 with visual 0x178. It does not matter that the two visuals are identical, the colormap 0x20 may only be used with visual 0x21. |
|
And I guess it's this check in i3 which is wrong: Line 116 in 55bc674 This uses In the case we are investigating, there are two identical visuals (no idea why) and the default visual is later in the list than its duplicate. Thus, I'll leave writing a patch to someone actually involved with i3. Feel free to acknowledge that I might have been a tiny bit helpful. ;-) |
|
Thank you very much for your detective work on this issue, @psychon. It’s much appreciated! Be sure to remind me to offer you a beverage of your choice when we run into each other in person :). If anyone wants to go ahead with a pull request to address this issue, feel free. I’ll be relying on external patches for this issue. |
ghost
mentioned this issue
Airblader
added
help wanted
reproducible
Output of
i3 --moreversion 2>&- || i3 --version:Binary i3 version: 4.13 (2016-11-08) © 2009 Michael Stapelberg and contributorsURL to a logfile as per http://i3wm.org/docs/debugging.html:
http://logs.i3wm.org/logs/5637337312657408.bz2
What I did:
Install
tigervnc, then doWhat I saw:
What I expected instead:
A working VNC session using i3.
The text was updated successfully, but these errors were encountered: