search

rust-x-bindings / rust-xcb

Rust bindings and wrapper for XCB.
MIT License
165 stars 64 forks source link

panic: Could not resolve randr Event with response_type 120 and first_event 89 #204

Closed dch closed 2 years ago

dch commented 2 years ago

reporting this as discovered in wezterm project, crashes on startup, i.e. at moment of trying to spawn a new window.

thread 'main' panicked at 'internal error: entered unreachable code:
  Could not resolve randr Event with response_type 120 and first_event 89',
  /wrkdirs/usr/ports/x11/wezterm/work/target/x86_64-unknown-freebsd/release/build/xcb-ad01777c72ac85b1/out/randr.rs:777:18

https://github.com/wez/wezterm/issues/2559#issuecomment-1264340175 has following logs

bt.txt xorg.log xrandr_properties.txt

rtbo commented 2 years ago

I tried to launch wezterm, and it seems to run without problem. Please post the output of 

xdpyinfo -queryExtensions | awk '/^number of extensions:/,/^default screen number/'
dch commented 2 years ago

thanks @rtbo yes this is very specific - same wezterm, same OS + packages, shows no issue on NVIDIA and other systems. Only on intel i915 graphics cards, definitely on this Dell XPS13, and a few other systems reported in the OP.

# xps13 fail
number of extensions:    27
    BIG-REQUESTS  (opcode: 133)
    Composite  (opcode: 142)
    DAMAGE  (opcode: 143, base event: 91, base error: 152)
    DOUBLE-BUFFER  (opcode: 145, base error: 153)
    DPMS  (opcode: 147)
    DRI2  (opcode: 154, base event: 119)
    GLX  (opcode: 151, base event: 95, base error: 158)
    Generic Event Extension  (opcode: 128)
    MIT-SCREEN-SAVER  (opcode: 144, base event: 92)
    MIT-SHM  (opcode: 130, base event: 65, base error: 128)
    Present  (opcode: 148)
    RANDR  (opcode: 140, base event: 89, base error: 147)
    RECORD  (opcode: 146, base error: 154)
    RENDER  (opcode: 139, base error: 142)
    SECURITY  (opcode: 137, base event: 86, base error: 138)
    SHAPE  (opcode: 129, base event: 64)
    SYNC  (opcode: 134, base event: 83, base error: 134)
    X-Resource  (opcode: 149)
    XC-MISC  (opcode: 136)
    XFIXES  (opcode: 138, base event: 87, base error: 140)
    XFree86-DGA  (opcode: 153, base event: 112, base error: 179)
    XFree86-VidModeExtension  (opcode: 152, base error: 172)
    XINERAMA  (opcode: 141)
    XInputExtension  (opcode: 131, base event: 66, base error: 129)
    XKEYBOARD  (opcode: 135, base event: 85, base error: 137)
    XTEST  (opcode: 132)
    XVideo  (opcode: 150, base event: 93, base error: 155)
default screen number:    0

For comparison, my working NVIDIA has:

# nvidia working
number of extensions:    31
    BIG-REQUESTS  (opcode: 133)
    Composite  (opcode: 142)
    DAMAGE  (opcode: 143, base event: 91, base error: 152)
    DOUBLE-BUFFER  (opcode: 145, base error: 153)
    DPMS  (opcode: 147)
    DRI2  (opcode: 155, base event: 119)
    DRI3  (opcode: 149)
    GLX  (opcode: 152, base event: 95, base error: 158)
    Generic Event Extension  (opcode: 128)
    MIT-SCREEN-SAVER  (opcode: 144, base event: 92)
    MIT-SHM  (opcode: 130, base event: 65, base error: 128)
    NV-CONTROL  (opcode: 157, base event: 121)
    NV-GLX  (opcode: 156)
    Present  (opcode: 148)
    RANDR  (opcode: 140, base event: 89, base error: 147)
    RECORD  (opcode: 146, base error: 154)
    RENDER  (opcode: 139, base error: 142)
    SECURITY  (opcode: 137, base event: 86, base error: 138)
    SHAPE  (opcode: 129, base event: 64)
    SYNC  (opcode: 134, base event: 83, base error: 134)
    X-Resource  (opcode: 150)
    XC-MISC  (opcode: 136)
    XFIXES  (opcode: 138, base event: 87, base error: 140)
    XFree86-DGA  (opcode: 154, base event: 112, base error: 179)
    XFree86-VidModeExtension  (opcode: 153, base error: 172)
    XINERAMA  (opcode: 141)
    XINERAMA  (opcode: 141)
    XInputExtension  (opcode: 131, base event: 66, base error: 129)
    XKEYBOARD  (opcode: 135, base event: 85, base error: 137)
    XTEST  (opcode: 132)
    XVideo  (opcode: 151, base event: 93, base error: 155)
rtbo commented 2 years ago

@wez @dch I see what happens. You are receiving DRI2 events from the X server which can happen on some driver configs when activating hardware acceleration even if you don't perform any DRI2 direct request. This is really related to Xlib and to specific GPU drivers.

To clarify a bit, the extensions you pass to xcb::Connection::connect*** only affect rust-xcb event and error resolution, but will not affect which event you can receive from the server.

Because xcb::Extension::Dri2 was not activated when opening the connection, rust-xcb does not try to look-up those events and hit the unreachable code. You see a RandR related error because it is the extension activated with highest base_event lower than 120 (which was a bug on my side).

The PR #205 is normally fixing this bug, Event::Unknown is returned instead of a panic.

I'm not sure though that it is 100% OK to ignore the event though. @wez You should check my opengl_window example. There is some code handling DRI2 events and some references to email threads. On a previous computer I had, not handling the events resulted in rendering problems which I solved with the code in rewire_event that rewires those events back to libgl. (Since #205 you can forward forward directly UnknownEvent raw pointer, you don't need to activate DRI2 in rust-xcb).

wez commented 2 years ago

Hmmm, that makes sense. I pushed a commit that requests Dri2. I already had the rewire_event stuff in the code: https://github.com/wez/wezterm/blob/main/window/src/os/x11/connection.rs#L432-L445 Let's see if that resolves this!

dch commented 2 years ago

reporting here for completeness, thanks @rtbo and @wez its resolved!