Wezterm: WezTerm does not support non-24 bit displays.

[vifino]

Describe the bug

WezTerm refuses to run on non-8bpc (24 bit) displays, like 10bpc (30-bit) OLED displays.

Environment (please complete the following information):

• OS: Linux X11
• Version: wezterm 20200620-160318-e00b076c-13-gab1e83c7

To Reproduce

1) Have DefaultDepth 30 in the screen section of your X11 config and a compatible GPU/Display.
2) Attempt to run WezTerm in such a session.

Expected behavior

WezTerm displays as it would on a 24-bit session.

Additional context

On an OLED such as the one on the Lenovo ThinkPad P1 Gen 2 with OLED screen, the additional two bits allow for brightness control by scaling with xrandr (--brightness [0-1]) without much quality loss.
Additionally, there are high end displays with 10 bpc color.

I'm not sure I can give you an easy to use debug environment, but Xephyr should be able to dummy one up.

[wez]

Does wezterm emit any error messages when run in this configuration?
I don't believe that Xephyr will simulate 30bpp on a 24bpp display so I can't test that. It will let me test 16bpp and terminates with
did not find 24-bit visual; terminating. Does it behave the same for 30bpp?

[wez]

Would you mind also sharing the output from xdpyinfo on that system?

[wez]

I pushed a commit that seems to allow running with a 32bpp visual; I wonder if that unblocks running on your system?
The build will be available in the artifacts section of the commit linked above in ~20 minutes, and will show up in the nightly builds in about an hour or so.

[vifino]

Hey. It does, now it runs, albeit with the software renderer because it seems it cannot load EGL.

 2020-07-06T09:27:27.243Z ERROR window::egl > with_egl_lib failed: no compatible EGL configuration was found
 2020-07-06T09:27:27.260Z ERROR window::egl > with_egl_lib failed: no compatible EGL configuration was found
 2020-07-06T09:27:27.260Z ERROR wezterm::frontend::gui::termwindow > OpenGL init failed: EGL library not found

[vifino]

xdpyinfo output (with seemingly irrellevant information stripped):

name of display:    :0
version number:    11.0
vendor string:    The X.Org Foundation
vendor release number:    12008000
X.Org version: 1.20.8
maximum request size:  16777212 bytes
motion buffer size:  256
bitmap unit, bit order, padding:    32, LSBFirst, 32
image byte order:    LSBFirst
number of supported pixmap formats:    8
supported pixmap formats:
    depth 1, bits_per_pixel 1, scanline_pad 32
    depth 4, bits_per_pixel 8, scanline_pad 32
    depth 8, bits_per_pixel 8, scanline_pad 32
    depth 15, bits_per_pixel 16, scanline_pad 32
    depth 16, bits_per_pixel 16, scanline_pad 32
    depth 24, bits_per_pixel 32, scanline_pad 32
    depth 32, bits_per_pixel 32, scanline_pad 32
    depth 30, bits_per_pixel 32, scanline_pad 32
keycode range:    minimum 8, maximum 255
focus:  window 0xaa00002, revert to PointerRoot
number of extensions:    29
    BIG-REQUESTS
    Composite
    DAMAGE
    DOUBLE-BUFFER
    DPMS
    DRI2
    DRI3
    GLX
    Generic Event Extension
    MIT-SCREEN-SAVER
    MIT-SHM
    NV-CONTROL
    NV-GLX
    Present
    RANDR
    RECORD
    RENDER
    SHAPE
    SYNC
    X-Resource
    XC-MISC
    XFIXES
    XFree86-DGA
    XFree86-VidModeExtension
    XINERAMA
    XInputExtension
    XKEYBOARD
    XTEST
    XVideo
default screen number:    0
number of screens:    1

screen #0:
  dimensions:    3840x2160 pixels (1016x571 millimeters)
  resolution:    96x96 dots per inch
  depths (8):    30, 1, 4, 8, 15, 16, 24, 32
  root window id:    0x937
  depth of root window:    30 planes
  number of colormaps:    minimum 1, maximum 1
  default colormap:    0x20
  default number of colormap cells:    1024
  preallocated pixels:    black 0, white 1073741823
  options:    backing-store WHEN MAPPED, save-unders NO
  largest cursor:    256x256
  current input event mask:    0x7a8034
    ButtonPressMask          EnterWindowMask          LeaveWindowMask
    ExposureMask             StructureNotifyMask      SubstructureNotifyMask
    SubstructureRedirectMask FocusChangeMask          PropertyChangeMask
  number of visuals:    456
  default visual id:  0x21
  visual:
    visual id:    0x21
    class:    TrueColor
    depth:    30 planes
    available colormap entries:    1024 per subfield
    red, green, blue masks:    0x3ff00000, 0xffc00, 0x3ff
    significant bits in color specification:    10 bits
[SNIP]
  visual:
    visual id:    0x935
    class:    TrueColor
    depth:    32 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff0000, 0xff00, 0xff
    significant bits in color specification:    8 bits
[ S N I P ]

[wez]

OK, sounds like we're making progress; I was hoping to see the 32-bit TrueColor visual info from xdpyinfo!
However, since we got as far as running the software renderer, let's focus on the EGL config.
Please share the full output from glxinfo

[wez]

I've pushed another commit that may help!

[vifino]

Nope, still fails with this.

 2020-07-06T17:30:53.945Z ERROR window::egl > with_egl_lib failed: no compatible EGL configuration was found
 2020-07-06T17:30:53.960Z ERROR window::egl > with_egl_lib failed: no compatible EGL configuration was found
 2020-07-06T17:30:53.961Z ERROR wezterm::frontend::gui::termwindow > OpenGL init failed: EGL library not found

glxinfo output is here: https://0x0.st/iyyb.txt

Thanks, by the way! I appreciate you taking the time to debug this with me.

[wez]

I've pushed a commit which will log the configurations that we can detect; hopefully that will help to understand why we're not matching a working one for you.

You'll need to start wezterm using: RUST_LOG=info wezterm to turn up the log level to info level; the relevant part of the output starts with something like this:

 2020-07-07T15:59:28.920Z INFO  window::egl                        > initialized EGL version 1.5
 2020-07-07T15:59:28.920Z INFO  window::egl                        > Available Configuration(s):
 2020-07-07T15:59:28.920Z INFO  window::egl                        > ConfigInfo { config: 0x5601debd4fd0, alpha_size: Some(8), red_size: Some(8), green_size: Some(8), blue_size: Some(8), depth_size: Some(0), conformant: Some("OPENGL OPENGL_ES2 OPENGL_ES3 "), renderable_type: Some("OPENGL OPENGL_ES2 OPENGL_ES3 "), native_visual_id: Some(33), surface_type: Some("PBUFFER PIXMAP WINDOW ") }

please capture from that point through to the end of the output.

[vifino]

Hey.
I've done as you asked, here is the log: http://0x0.st/iyF3.log
Thanks!

[wez]

Thanks! Interesting; there appears to be an inconsistency between the glxinfo output and the configurations detected in the code; here's an entry from your glxinfo:

0x2d8 32 tc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None

and here's the corresponding entry detected in code; native visual id 728 is 0x2d8:

2020-07-08T18:58:10.996Z INFO  window::egl                        > ConfigInfo { config: 0x55574cdce860, alpha_size: Some(0), red_size: Some(8), green_size: Some(8), blue_size: Some(8), depth_size: Some(24), conformant: Some("OPENGL OPENGL_ES2 OPENGL_ES3 "), renderable_type: Some("OPENGL OPENGL_ES2 OPENGL_ES3 "), native_visual_id: Some(728), surface_type: Some("PIXMAP WINDOW ") }

if you're able to build wezterm locally on that system, I'd be interested to hear what happens if you change this 8 to 0:

https://github.com/wez/wezterm/blob/master/window/src/egl.rs#L368

(https://wezfurlong.org/wezterm/install/source.html has more info on building from source)

I'll try some experiments with this a bit later, wanted to suggest that you try that if it helps shorten the time to understanding this better!

[wez]

If you have a few moments to try the latest nightly this weekend I'd appreciate it; I have a couple of other OpenGL init fixes that are worthy of cutting a new release and it would be great to put this issue to bed as part of that if we can!

[vifino]

Hey!
Sorry, I had a busy couple of days.
The latest build does not complain any longer, but it's output is messed up: https://0x0.st/itpn.png
Just in case, here's the log with RUST_LOG=info: http://0x0.st/itpR.log
To me, it looks like it's using the wrong pixel mask, but I barely deal with graphics.

[wez]

Thanks and no worries; life is busy!
I've pushed another commit that I'm hopeful will have better color representation on that display.

[vifino]

Hey! It looks like it's working perfectly now.
I haven't set up wezterm yet (for obvious reasons) but I'll do that now that it seems fine.