X terminal emulator rendering through OpenGL ES Compute Shaders

Zutty - Zero-cost Unicode Teletype

A high-end terminal for low-end systems

Homepage: https://tomscii.sig7.se/zutty
Source: https://github.com/tomszilagyi/zutty

Zutty is a terminal emulator for the X Window System, functionally similar to several other X terminal emulators such as xterm, rxvt and countless others. It is also similar to other, much more modern, GPU-accelerated terminal emulators such as Alacritty and Kitty. What really sets Zutty apart is its radically simple, yet extremely efficient rendering implementation, coupled with a sufficiently complete feature set to make it useful for a wide range of users. Zutty offers high throughput with low latency, and strives to conform to relevant (published or de-facto) standards.

Zutty is written in straightforward C++ and only relies on OpenGL ES 3.1 for rendering, making it trivially portable to windowing systems other than X and operating systems other than Linux. Zutty provides a clean implementation written from scratch, resulting in a minimal, maintainable, modern codebase unencumbered by historical baggage.

Zutty is released under the GNU General Public License (GPL) v3 or (at your option) any later version. Please refer to the file LICENSE for the full text of the license.

Documentation

Core documentation (bundled with the Zutty sources):

More about Zutty:

Current status

Zutty started out as a concept to prove the feasibility of using a GLES Compute Shader to render a fixed-width text grid entirely in graphics hardware. From its modest beginnings as a technological proof of concept, Zutty has evolved considerably and is now perfectly capable of serving as the main terminal emulator for heavy users of the command line. In particular, this author employs Zutty to run a workload of tmux, emacs (-nw), tig, mutt, htop, and a bunch of other applications making extensive use of the terminal (including its mouse support), with some Zutty instances running for months at a time, on a very resource-constrained SBC (ab)used as a desktop. The correctness, performance, and stability of Zutty is excellent, as one would rightly expect from something as fundamental as a terminal emulator.

There is, however, a list of ancillary features that Zutty does not presently implement. Completing the ones in scope is more or less a matter of straightforward implementation work within the already existing architecture of Zutty, and time will be spent on these in proportion to popular user demand.

Notable features

Radically simple, uniquely performant rendering technology

The main idea behind Zutty is the implementation of “raw” character video memory via OpenGL ES 3.1. This video memory is just an array of cells backing all character grid locations, with each cell containing Unicode character codes plus color and other visual attributes. This memory area, allocated on the GPU, is mapped to make it directly writable by the application. This results in a conceptually similar interface as to how one could write to the screen by directly poking at physical video memory starting at 0xB8000 on the IBM PC. Zutty employs an OpenGL Compute Shader running on the GPU to read this video memory and render output pixels. The full name of Zutty (dubbed the Zero-cost Unicode Teletype) stands for the remarkable fact that its image rendering is zero-cost from the host CPU perspective.

Zutty requires OpenGL ES 3.1 because this is precisely the lowest version with support for the Compute Shader, the enabling technology behind Zutty. We have chosen OpenGL ES over OpenGL to widen the range of supported hardware platforms, primarily towards small, low-cost Single Board Computers. These boards are commonly built around an ARM SoC with a graphics core supporting OpenGL ES, but not “desktop” OpenGL. Zutty is the first GPU-accelerated terminal for such low-cost platforms.

Correct (and fairly complete) VT emulation

Zutty substantially emulates the “commonly used” subsets of the protocols of VT52, VT100, VT102, VT220, VT320, VT420 and VT520 terminals (originally manufactured by DEC) as well as some more modern additions defined by the de-facto standard xterm implementation.

We take great care to ensure that Zutty passes the subset of VTTEST screens that we care about (this amounts to the overwhelming majority of tests concerned with actual screen rendering, and is subject to further extension). We have an automated regression testing setup to run VTTEST in Zutty and verify that the output is a pixel-perfect match of the pre-approved video output. You can thus expect the terminal output to be correct – be it driven by tmux, emacs (with org-mode, helm, magit, etc.) or whatever else. Zutty handles corner cases (escape sequences) which, sadly enough, several popular terminal emulators do not correctly support. Zutty also boasts mouse support (modeled after the capabilities of xterm) to make the user experience of many terminal applications more interactive.

In a perfect world, this should not have to be listed as such a prominent feature, but unfortunately, it is rather the exception than the norm among widely used terminal emulators (including more modern ones).

Font handling

Zutty supports both fixed size (bitmap) and scaled (TTF, OTF) fonts. Up to four variants of a font are supported (Regular, Bold, Italic / Oblique, plus BoldItalic) with automatic, sensible fallbacks in case any of them (apart from Regular) is missing. Zutty tries to locate the font files itself under a configured font search path, and loads them on its own, without any support from the windowing system.

True color support

Each grid cell in the virtual video memory emulated via OpenGL has three bytes reserved for the foreground color as well as the background color. As such, Zutty naturally supports true color (24 bits / 16 million colors) on each cell’s foreground and background, completely independent of each other and all other cells.

Traditional X-clipboard / primary selection / copy-paste support

Zutty supports the traditional method of “copy-paste” based on the X Selection API, and is accessible via the same GUI mechanisms that long-time xterm users are familiar with.

Zutty faithfully replicates what xterm has provided for a very long time: starting selections with the left button, adjusting them with the right button, and cycling between snap-to-char/word/line with double clicks. Compared with xterm, one notable difference is a built-in, simpler rule for word boundaries (as opposed to user-adjustable definitions of character classes).

It is possible to adjust the selection while navigating scrollback. Thus, the complete content of the screen buffer (page history plus on-screen lines), or any part of it, can be copied as a single selection. No need to switch back and forth between source and destination programs when copying large amounts of terminal output!

Selecting a region with the mouse will set the primary selection, and pressing Control+Shift+C will copy that to the clipboard. This mechanism is useful because it allows holding two separate pieces of selection data at once. Zutty can also be configured to automatically copy the primary to the clipboard each time a selection is done.

Paste the primary selection into the terminal via middle click or Shift+Insert, like in xterm. Paste the clipboard via Control+Shift+V.

Just as with xterm, terminal programs might enable one of the supported “mouse protocols” to provide mouse interaction on their user interfaces; in such cases, press and hold the Shift key while performing the clicks and drags of the selection that you want to perform (both while copying and pasting). Holding Shift will cut through to the Zutty mouse handler instead of sending those mouse events to the terminal program via the mouse protocol. So, regardless of the program running in the terminal, you can always access the built-in copy-paste support in Zutty; but you can also use whatever mouse support your program has.

In addition, Zutty adds a unique feature for real power users of the terminal: rectangular selection. This is extremely useful if working with a vertically split terminal (think emacs or tmux). Simply toggle between “regular” and “rectangular” selection mode with the Space key while a selection adjustment is in progress (left or right mouse button is held down). For your convenience, this setting persists over individual selections made, throughout the lifetime of a running Zutty terminal.

Small, clean codebase

The radical simplicity of our rendering technology allows for a straightforward virtual terminal implementation that happens to be extremely performant despite the lack of any fancy optimizations on the source code level. This also allows the codebase of Zutty to be very small (under ten thousand lines, including comments and empty lines) and highly readable. Therefore, Zutty lends itself towards educational use and as a vehicle for hacking on terminals. If you’ve always wanted to learn how a terminal emulator works from the inside out, consider studying the Zutty codebase (and associated developer documentation)!

Omissions and limitations

There are things that Zutty does not implement compared to other, more established X terminal emulators (xterm being the gold standard of completeness here). The below list gives an overview of what might be considered missing. Some of them are clearly out of scope for Zutty, but some will possibly be implemented in the future.

  • Zutty is opinionated about the primacy of UTF-8, which means that non-UTF-8 interaction is generally not supported, not even via bridges such as luit. DEC builtin character sets (such as the DEC Special Graphics, DEC Technical Characters, etc.) and the escape sequences to enable them are well implemented though, so users of any modern Linux environment should never run into trouble.
  • Zutty is Unicode-based, but it is a terminal emulator, not an all-purpose Unicode program. Therefore it does not aim to implement the whole breadth and depth of glyph and language support that Unicode defines. Currently not supported:
    • Characters with a code point above 0xFFFF (that is, outside of the Basic Multilingual Pane);
    • Bidirectional (right-to-left) text;
    • Composing characters (things that can only be represented as a base glyph plus one or more composing glyphs superimposed, even in Unicode NFC representation). Do not confuse this with using the compose key to input accented or special characters missing from your keyboard; that works fine!
    • Possibly more esoteric features.
  • Double-width characters (necessary for e.g., drawing CJK glyphs) are not supported. Double-height lines are likewise not supported.
  • Rectangular area operations (introduced by the DEC VT400 series) are not supported. However, this set of features is optional and the terminal’s self-identification response clearly states the absence of this support, so conforming client applications should not run into any trouble. No fundamental technical reasons here other than the lack of pressing need.
  • The mouse protocol implementation aims to be complete with the exception of highlight tracking mode that is not implemented. Mouse highlight tracking is a mode that requires cooperation from the client application; it is not clear if any software actively used in 2020 needs this feature. Also, all events for mouse buttons above the conventional five (three buttons plus scroll wheel up/down) are discarded.
  • Blinking in general (blinking text driven by the SGR attribute 5, and blinking cursor mode turned on/off by DEC-private set/reset escape sequences) are not (yet) supported. Certain more esoteric text attributes, such as the “concealed” bit, are also not implemented. This is purely due to lack of bandwidth, and will most likely be added in the future.
Comments
  • support application keypad

    support application keypad

    The application keypad mode (\e=) doesn't work yet. Without it, a whole 20% of a full-sized keyboard is redundant (vs either digits or arrows). Not many programs make use of this mode, but I for one have a need for it.

  • Unclear Runtime Error

    Unclear Runtime Error

    Hello! I am really excited to give zutty more of a try!

    I put together a debug build, and gave it a run specifying a custom font (because I don't have 9x18 installed). Below is the verbose output:

    $ zutty -font liberationmono -verbose                                                                                                                                                                                                                                                                                                                        o_O
    Zutty 0.6-8-gc792cf1
    Copyright (C) 2020 Tom Szilagyi
    
    This program comes with ABSOLUTELY NO WARRANTY.
    Zutty is free software, and you are welcome to redistribute it
    under the terms and conditions of the GNU GPL v3 (or later).
    
    T [main.cc:320] Shell subprocess started, pid: 21022
    T [fontpack.cc:181] Fontpack: fontpath=/usr/share/fonts; fontname=liberationmono
    T [fontpack.cc: 42] Italic: /usr/share/fonts/liberation/LiberationMono-Italic.ttf
    T [fontpack.cc: 42] Regular: /usr/share/fonts/liberation/LiberationMono-Regular.ttf
    T [fontpack.cc: 42] Bold: /usr/share/fonts/liberation/LiberationMono-Bold.ttf
    T [fontpack.cc: 42] BoldItalic: /usr/share/fonts/liberation/LiberationMono-BoldItalic.ttf
    I [font.cc: 54] Loading /usr/share/fonts/liberation/LiberationMono-Regular.ttf as primary
    T [font.cc: 60] Family: Liberation Mono; Style: Regular; Faces: 1; Glyphs: 2407
    I [font.cc:213] Pixel size 16
    I [font.cc:224] Glyph size 10x17
    T [font.cc: 95] Atlas texture geometry: 64x38 glyphs of 10x17 each, yielding pixel size 640x646.
    T [font.cc: 99] Atlas holds space for 2432 glyphs, 2408 will be used, empty: 24 (0.986842%)
    T [font.cc:106] Allocating 413440 bytes for atlas buffer
    terminate called after throwing an instance of 'std::runtime_error'
      what():  FreeType: Failed to render glyph for char 32
    zsh: abort (core dumped)  zutty -font liberationmono -verbose
    

    And, here is a stack trace recovered from journalctl:

    Jan 15 21:55:49 Atlas systemd-coredump[20975]: Process 20966 (zutty) of user 1000 dumped core.
    
                                                   Stack trace of thread 20966:
                                                   #0  0x00007fc6e8c36615 raise (libc.so.6 + 0x3d615)
                                                   #1  0x00007fc6e8c1f862 abort (libc.so.6 + 0x26862)
                                                   #2  0x00007fc6e8fb886a _ZN9__gnu_cxx27__verbose_terminate_handlerEv (libstdc++.so.6 + 0x9686a)
                                                   #3  0x00007fc6e8fc4d9a _ZN10__cxxabiv111__terminateEPFvvE (libstdc++.so.6 + 0xa2d9a)
                                                   #4  0x00007fc6e8fc4e07 _ZSt9terminatev (libstdc++.so.6 + 0xa2e07)
                                                   #5  0x00007fc6e8fc50ae __cxa_throw (libstdc++.so.6 + 0xa30ae)
                                                   #6  0x00005593152fb179 n/a (zutty + 0xc179)
                                                   #7  0x000055931530343e n/a (zutty + 0x1443e)
                                                   #8  0x0000559315303726 n/a (zutty + 0x14726)
                                                   #9  0x00005593153043a2 n/a (zutty + 0x153a2)
                                                   #10 0x0000559315305eac n/a (zutty + 0x16eac)
                                                   #11 0x00005593152fdc3b n/a (zutty + 0xec3b)
                                                   #12 0x00007fc6e8c21152 __libc_start_main (libc.so.6 + 0x28152)
                                                   #13 0x00005593152ffebe n/a (zutty + 0x10ebe)
    
                                                   Stack trace of thread 20971:
                                                   #0  0x00007fc6e92d76a2 [email protected]@GLIBC_2.3.2 (libpthread.so.0 + 0xf6a2)
                                                   #1  0x00007fc6e574b63c n/a (i965_dri.so + 0x55763c)
                                                   #2  0x00007fc6e574aeb8 n/a (i965_dri.so + 0x556eb8)
                                                   #3  0x00007fc6e92d13e9 start_thread (libpthread.so.0 + 0x93e9)
                                                   #4  0x00007fc6e8cf9293 __clone (libc.so.6 + 0x100293)
    
                                                   Stack trace of thread 20970:
                                                   #0  0x00007fc6e92d76a2 [email protected]@GLIBC_2.3.2 (libpthread.so.0 + 0xf6a2)
                                                   #1  0x00007fc6e574b63c n/a (i965_dri.so + 0x55763c)
                                                   #2  0x00007fc6e574aeb8 n/a (i965_dri.so + 0x556eb8)
                                                   #3  0x00007fc6e92d13e9 start_thread (libpthread.so.0 + 0x93e9)
                                                   #4  0x00007fc6e8cf9293 __clone (libc.so.6 + 0x100293)
    
                                                   Stack trace of thread 20973:
                                                   #0  0x00007fc6e92d76a2 [email protected]@GLIBC_2.3.2 (libpthread.so.0 + 0xf6a2)
                                                   #1  0x00007fc6e574b63c n/a (i965_dri.so + 0x55763c)
                                                   #2  0x00007fc6e574aeb8 n/a (i965_dri.so + 0x556eb8)
                                                   #3  0x00007fc6e92d13e9 start_thread (libpthread.so.0 + 0x93e9)
                                                   #4  0x00007fc6e8cf9293 __clone (libc.so.6 + 0x100293)
    
                                                   Stack trace of thread 20972:
                                                   #0  0x00007fc6e92d76a2 [email protected]@GLIBC_2.3.2 (libpthread.so.0 + 0xf6a2)
                                                   #1  0x00007fc6e574b63c n/a (i965_dri.so + 0x55763c)
                                                   #2  0x00007fc6e574aeb8 n/a (i965_dri.so + 0x556eb8)
                                                   #3  0x00007fc6e92d13e9 start_thread (libpthread.so.0 + 0x93e9)
                                                   #4  0x00007fc6e8cf9293 __clone (libc.so.6 + 0x100293)
    

    If there are any other files or information that would be helpful in determining what may be going wrong, please let me know, I'll be happy to gather it.

    Thank you for your work!

  • Building on FreeBSD (DO NOT MERGE)

    Building on FreeBSD (DO NOT MERGE)

    Hi! I heard about zutty today and wanted to try it. I use FreeBSD. (and inherently use Clang)

    $ uname -a
    FreeBSD nyann.tanasinn.mochi 12.2-RELEASE-p1 FreeBSD 12.2-RELEASE-p1 GENERIC  amd64
    $ freebsd-version -kru
    12.2-RELEASE-p1
    12.2-RELEASE-p1
    12.2-RELEASE-p2
    

    I found zutty doesn't compile on FreeBSD. But with a few changes, it does.

    You won't want to accept this pull request, as it's merely to show what steps I needed to take to get zutty to compile. You may, however, want to take the diff for src/gl.cc. I added an #include <string> because otherwise C++'s to_string wouldn't work. Please read all three commit descriptions. I also think -Wpedantic could be added to the list of compiler flags.

    Also, even with this pull request, when run, zutty only shows on screen for a brief moment before dumping core.

    $ ./zutty -verbose -fontpath /usr/local/share/fonts 
    Zutty 0.7
    Copyright (C) 2020 Tom Szilagyi
    
    This program comes with ABSOLUTELY NO WARRANTY.
    Zutty is free software, and you are welcome to redistribute it
    under the terms and conditions of the GNU GPL v3 (or later).
    
    T [main.cc:354] Shell subprocess started, pid: 3838
    T [fontpack.cc:181] Fontpack: fontpath=/usr/local/share/fonts; fontname=9x18
    T [fontpack.cc: 42] Bold: /usr/local/share/fonts/misc/9x18B.pcf.gz
    T [fontpack.cc: 42] Regular: /usr/local/share/fonts/misc/9x18.pcf.gz
    I [font.cc: 54] Loading /usr/local/share/fonts/misc/9x18.pcf.gz as primary
    T [font.cc: 60] Family: Misc Fixed; Style: Regular; Faces: 1; Glyphs: 4767
    T [font.cc:162] Available sizes: 9x18
    T [font.cc:165] Configured size: 16; Best matching fixed size: 9x18
    I [font.cc:198] Glyph size 9x18
    T [font.cc: 95] Atlas texture geometry: 98x49 glyphs of 9x18 each, yielding pixel size 882x882.
    T [font.cc: 99] Atlas holds space for 4802 glyphs, 4768 will be used, empty: 34 (0.708038%)
    T [font.cc:106] Allocating 777924 bytes for atlas buffer
    I [font.cc: 54] Loading /usr/local/share/fonts/misc/9x18B.pcf.gz as overlay
    T [font.cc: 60] Family: Misc Fixed; Style: Bold; Faces: 1; Glyphs: 763
    T [font.cc:162] Available sizes: 9x18
    T [font.cc:165] Configured size: 16; Best matching fixed size: 9x18
    I [font.cc:198] Glyph size 9x18
    I [main.cc:123] Window ID: 50331650 / 0x3000002
    T [selmgr.cc: 32] SelectionManager: chunkSize=1048575
    T [vterm.icc:1597] csi_SGR [0]  p(0,0)  d(24,80)  mgn[0,24)  hmgn:0 [0,80)  cur=0  head=0
    T [main.cc:897] x11_fd = 3
    T [main.cc:898] pty_fd = 4
    T [selmgr.cc: 69] onPropertyNotify on '_NET_WM_PID' (NewValue)
    T [selmgr.cc: 69] onPropertyNotify on 'WM_CLIENT_MACHINE' (NewValue)
    T [selmgr.cc: 69] onPropertyNotify on 'WM_NORMAL_HINTS' (NewValue)
    T [selmgr.cc: 69] onPropertyNotify on 'WM_NAME' (NewValue)
    T [selmgr.cc: 69] onPropertyNotify on 'WM_ICON_NAME' (NewValue)
    T [selmgr.cc: 69] onPropertyNotify on 'WM_NORMAL_HINTS' (NewValue)
    T [selmgr.cc: 69] onPropertyNotify on 'WM_PROTOCOLS' (NewValue)
    T [selmgr.cc: 69] onPropertyNotify on '_FLUXBOX_GROUP_LEFT' (NewValue)
    T [main.cc:829] ReparentNotify
    T [main.cc:836] MapNotify
    T [selmgr.cc: 69] onPropertyNotify on '_NET_WM_DESKTOP' (NewValue)
    T [selmgr.cc: 69] onPropertyNotify on '_NET_FRAME_EXTENTS' (NewValue)
    T [selmgr.cc: 69] onPropertyNotify on '_NET_WM_ALLOWED_ACTIONS' (NewValue)
    T [selmgr.cc: 69] onPropertyNotify on 'WM_STATE' (NewValue)
    T [selmgr.cc: 69] onPropertyNotify on '_NET_WM_DESKTOP' (NewValue)
    T [selmgr.cc: 69] onPropertyNotify on '_NET_FRAME_EXTENTS' (NewValue)
    T [vterm.icc:681] showCursor [0]        p(0,0)  d(24,80)  mgn[0,24)  hmgn:0 [0,80)  cur=0  head=0
    T [charvdev.cc:541] compute program: uniform glyphPixels=6 sizeChars=11 cursorColor=2 cursorPos=3 cursorStyle=4 selectRect=9 selectRectMode=10 selectDamage=8 deltaFrame=5
    T [charvdev.cc:563] draw program: attrib pos=0 vertexTexCoord=1 uniform viewPixels=1
    I [charvdev.cc:389] Resize to 724 x 436 pixels, 80 x 24 chars
    $ 
    

    After you read this PR, please close it.

    For context: I'm a C programmer, not a C++ programmer (and not yet a Python programmer, though I should become one) (also, I apologise for the state of my github profile: I usually don't have one, and having this one is temporary)

  • custom key [re]mappings ?

    custom key [re]mappings ?

    Hi, Thank you for this project! I am excited to explore it. I have looked but so far cannot find out of there is any way to re-map some key sequences ? Either through X resources or a custom configuration ? For example, with urxvt: keysym.C-BackSpace: string:\0 .... with alacritty I can do similar with its yml config. thx again, -m

  • No suitable files for '9x18' found!

    No suitable files for '9x18' found!

    I compiled the latest release and the latest git commit without problems on ArchLinux¹. However, both of them aborts with this error message:

    $ zutty
    terminate called after throwing an instance of 'std::runtime_error'
      what():  No suitable files for '9x18' found!
    Job 1, 'zutty' terminated by signal SIGABRT (Abort)
    

    I assume it is a font issue. I'm not aware how to solve the problem, though. Installing a 9×18 font didn't seem to work.

    Any suggestions?


    1. https://aur.archlinux.org/packages/zutty/ & https://aur.archlinux.org/packages/zutty-git/
  • Build fails on NixOS

    Build fails on NixOS

    This doesn't look Nix specific, but rather due to the specific GCC version used.

    nx and ny are uint16_t which gets upgraded to a signed-integer before arithmetic happens on any target where int is larger than 16 bits.

    There are multiple ways to fix this; a cast of either nx or ny to unsigned int is sufficient. Simply adding something to suppress the warning is reasonable in this specific case as well.

    ../src/font.cc: In member function 'void zutty::Font::load()':
    ../src/font.cc:88:25: error: comparison of integer expressions of different signedness: 'int' and 'unsigned int' [-Werror=sign-compare]
       88 |          while (nx * ny < n_glyphs)
          |                 ~~~~~~~~^~~~~~~~~~
    
  • Your performance comparison is incorrect

    Your performance comparison is incorrect

    I'm just pointing out here that you turned off scrollback for every terminal (apparently because yours doesnt implement it), except kitty. The relevant setting is scrollback_lines which defaults to 2000, not scrollback_pager_history_size which you set to zero for some reason, though it defaults to zero anyway.

    And I'll just point out that how fast a terminal sinks data is a totally meaningless test. It can be trivially gamed in any terminal that uses threaded rendering. You just read data arbitrarily fast on a separate thread, buffer it in memory and process it next year. And claim the prize in any vttest/cat large file benchmark.

  • keypad in non-app mode assumes NumLock

    keypad in non-app mode assumes NumLock

    While commit 15100bb5da8b26cb29c0137db2c0d946763535b9 fixed keypad in the app mode (thanks!), it regressed the arrow mode. It now assumes that NumLock is always on, despite its true state, shift, and so on.

  • Setup icons for _NET_WM_ICON

    Setup icons for _NET_WM_ICON

    Provide icons for (most) window managers that don't match an applications WM_CLASS property against their .desktop icon entry.

    Generated src/icons.h with 16x16 and 32x32 icons only; convert-png-to-argb-c.sh zutty_16x16.png zutty_32x32.png > ../src/icons.h

    Closes #36 where I know you want to avoid including an image blob but, at least with 16x16 and 32x32 icons only, this is lower code size than having to find, load and process icons before passing XChangeProperty and finally freeing them.

  • segfault when closing window with (x) button

    segfault when closing window with (x) button

    Hi,

    when closing Zutty window using the (x) "Close" button, a segfault occurs. As the X connection is broken, processing events fails. Please see stack trace below.

    Starting program: /home/chybz/dev/upstream/zutty/build/src/zutty 
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
    VAL=3
    X connection to :1 broken (explicit kill or server shutdown).
    
    Thread 1 "zutty" received signal SIGSEGV, Segmentation fault.
    0x00007ffff570f243 in ?? () from /usr/lib/x86_64-linux-gnu/libnvidia-eglcore.so.460.27.04
    gdb> bt
    #0  0x00007ffff570f243 in ?? () from /usr/lib/x86_64-linux-gnu/libnvidia-eglcore.so.460.27.04
    #1  0x00007ffff56f0ae8 in ?? () from /usr/lib/x86_64-linux-gnu/libnvidia-eglcore.so.460.27.04
    #2  0x00007ffff56f117a in ?? () from /usr/lib/x86_64-linux-gnu/libnvidia-eglcore.so.460.27.04
    #3  0x00007ffff570f74b in ?? () from /usr/lib/x86_64-linux-gnu/libnvidia-eglcore.so.460.27.04
    #4  0x00007ffff69fd5df in ?? () from /usr/lib/x86_64-linux-gnu/libEGL_nvidia.so.0
    #5  0x00007ffff69fd6a7 in ?? () from /usr/lib/x86_64-linux-gnu/libEGL_nvidia.so.0
    #6  0x00007ffff6a68e85 in ?? () from /usr/lib/x86_64-linux-gnu/libEGL_nvidia.so.0
    #7  0x00007ffff6a68efd in ?? () from /usr/lib/x86_64-linux-gnu/libEGL_nvidia.so.0
    #8  0x00007ffff69fc9e9 in ?? () from /usr/lib/x86_64-linux-gnu/libEGL_nvidia.so.0
    #9  0x00007ffff6a69130 in ?? () from /usr/lib/x86_64-linux-gnu/libEGL_nvidia.so.0
    #10 0x00007ffff78754d7 in __run_exit_handlers (status=1, listp=0x7ffff79f5718 <__exit_funcs>, 
        run_list_atexit=run_list_atex[email protected]=true, [email protected]=true) at exit.c:108
    #11 0x00007ffff787567a in __GI_exit (status=<optimized out>) at exit.c:139
    #12 0x00007ffff7d6f18f in _XDefaultIOError () from /usr/lib/x86_64-linux-gnu/libX11.so.6
    #13 0x00007ffff7d6f42e in _XIOError () from /usr/lib/x86_64-linux-gnu/libX11.so.6
    #14 0x00007ffff7d6cba5 in _XEventsQueued () from /usr/lib/x86_64-linux-gnu/libX11.so.6
    #15 0x00007ffff7d5e711 in XPending () from /usr/lib/x86_64-linux-gnu/libX11.so.6
    #16 0x0000555555562df8 in eventLoop (win=<optimized out>, pty_fd=4, [email protected]: 0x55555575be10, 
        dpy=<optimized out>) at ../src/main.cc:875
    #17 main (argc=<optimized out>, argv=<optimized out>) at ../src/main.cc:1163
    

    Hope this helps

  • Zutty adding '-' to beginning of file in vim

    Zutty adding '-' to beginning of file in vim

    Every file I open in vim somehow ends up with a '-' prepended to it. This is not just a display artefact, it is really there in the buffer, but vim remains in normal mode. Log:

    E [vterm.icc: 94] Error: Unhandled input char 'm' (109) in state 13. Escape sequence so far: '\e[>4;2m' (7 bytes)
    W [vterm.icc:1491] (Unimplemented) Start blinking cursor
    W [vterm.icc:1540] (Unimplemented) Stop blinking cursor
    W [vterm.icc:1713] (Unimplemented) attribute: 29
    W [vterm.icc:1821] (Unimplemented) DCS: 'zz'
    E [vterm.icc: 94] Error: Unhandled input char '%' (37) in state 7. Escape sequence so far: '\e[0%' (4 bytes)
    W [main.cc:897] (Unimplemented) unhandled OSC: '10;?'
    W [main.cc:897] (Unimplemented) unhandled OSC: '11;?'
    W [main.cc:897] (Unimplemented) unhandled OSC: '12;%p1%s'
    W [main.cc:897] (Unimplemented) unhandled OSC: '12;%p1%s'`
    
  • zutty keeps inherited file descriptors open but probably shouldn't

    zutty keeps inherited file descriptors open but probably shouldn't

    When starting a zutty instance from another terminal instance (xterm/zutty/etc.), the process in the subordinate zutty has a pty too much left open. (I'm hunting down a hang in zutty elsewhere and found this.)

    3

    xterm-from-xterm does not exhibit this behavior.

    2

  • Custom cursor style support

    Custom cursor style support

    First of all, thanks a lot for this nice terminal emulator (I'm switching terminals and glad to find this excellent candidate).

    Even though blinking is not on the roadmap, maybe implementing just different cursor style option could be a good start? Similarly to styles in this st patch: just block, bar and underline would be great.

  • Fix Chinese IME support.

    Fix Chinese IME support.

  • Support ANSI SGR crossedout and conceal

    Support ANSI SGR crossedout and conceal

    Vim was causing lots of (Unimplemented) attribute: 29 to be logged at start up and every PGUP/PGDOWN key press so here's a fix by supporting crossed-out and also conceal since it was easy.

    Tested with 7x13 fixed font to pixel match what xterm uses with y - ((3 * FontAscent(screen)) / 8) versus (srcGlyphPixels.y - 1) * 5 / 8). I presume your preferred 9x18 fixed font should be close but didn't test. Not sure if there is an equivalent to FontAscent in zutty.

    (Also locally patched to disable logging for (Unimplemented) Stop blinking cursor too.)

    The conceal part could be used for the unimplemented blinking too but not sure where to put a timer, codewise and classwise, that updates a blink_active variable to match xterm 600ms on and 300ms off approximately.

    if (conceal == 1u || (blinking == 1u && blink_active)) { fgColor = bgColor; } }

  • Disable scroll on output

    Disable scroll on output

    Is it possible to disable the automatic scroll on output?

    I frequently run benchmarks and each benchmark generates a line per measured time unit. And while the test is running, I want to look at what happened earlier. The problem is when there is some new output, focus is lost and I move back to the newest content.

    So when I'm 'attached' to the last line, there should an automatic scroll.

    But when I'm detached, I want do not want to follow the latest output.

    qterminal has this feature if you want to see it in action.

Related tags
Spitfire is a basic terminal language that can exicute code via the terminal.

Spitfire is a basic terminal language that can exicute code via the terminal. It is easy to learn and runs fast, considering that its just a 300 line c++ file.

Nov 18, 2021
Contour - A modern C++ Terminal Emulator
 Contour - A modern C++ Terminal Emulator

contour is a modern terminal emulator, for everyday use. It is aiming for power users with a modern feature mindset.

Nov 24, 2022
Make your terminal emulator colorful!
Make your terminal emulator colorful!

libvterm Make your terminal emulator colorful! LibVTerm is an embeddable ANSI C89 (C90) library for parsing ANSI escape sequences. It is constructed i

Jun 4, 2022
nicegraf-shaderc is a command-line tool that transforms HLSL code into shaders for various graphics APIs.
nicegraf-shaderc is a command-line tool that transforms HLSL code into shaders for various graphics APIs.

User Manual Table of Contents Introduction Project Status Obtaining the Source Code and Building Running Defining Techniques Generated Header File Pip

Oct 24, 2022
Pipe Viewer - monitor the progress of data through a pipe

Introduction ************ This is the README for `pv' ("Pipe Viewer"), a terminal-based tool for monitoring the progress of data through a pipeline.

Nov 19, 2022
Small header only C++ library for writing multiplatform terminal applications

Terminal Terminal is small header only library for writing terminal applications. It works on Linux, macOS and Windows (in the native cmd.exe console)

Dec 1, 2022
:computer: C++ Functional Terminal User Interface. :heart:
:computer: C++ Functional Terminal User Interface. :heart:

FTXUI Functional Terminal (X) User interface A simple C++ library for terminal based user interface. Demo: Feature Functional style. Inspired by [1] a

Nov 30, 2022
A little UNIX-inspired terminal application for the Numworks Calculator (not using escher).
A little UNIX-inspired terminal application for the Numworks Calculator (not using escher).

L.E. Terminal (let for short) is a little UNIX-inspired terminal for the Numworks Calculator.

Aug 31, 2022
Draw sequence diagram in text from terminal.

sequence-diagram-cli Draw seqence diagram from terminal.

Nov 26, 2022
Terminal calculator made for programmers working with multiple number representations, sizes, and overall close to the bits
Terminal calculator made for programmers working with multiple number representations, sizes, and overall close to the bits

Programmer calculator The programmer calculator is a simple terminal tool designed to give maximum efficiency and flexibility to the programmer workin

Nov 22, 2022
The new Windows Terminal and the original Windows console host, all in the same place!

The new Windows Terminal and the original Windows console host, all in the same place!

Nov 28, 2022
n³ The unorthodox terminal file manager
n³ The unorthodox terminal file manager

n³ The unorthodox terminal file manager

Nov 30, 2022
Graphs the activity of a chia harvester in a linux terminal.
Graphs the activity of a chia harvester in a linux terminal.

Chia Harvest Graph Monitor for Chia Harvesting Introduction The chiaharvestgraph tool will graph Chia Harvesting activity in a linux terminal. Use a 2

Nov 10, 2022
a simple to use linux terminal

a simple to use linux terminal

Feb 17, 2022
Collection of human friendly terminal interface for git.
Collection of human friendly terminal interface for git.

A collection of human friendly terminal user interface for git.

Nov 25, 2022
Simple benchmark for terminal output

TermBench This is a simple timing utility you can use to see how slow your terminal program is at parsing escape-sequence-coded color output. It can b

Oct 19, 2022
tinytetris - 80x23 terminal tetris
tinytetris - 80x23 terminal tetris

tinytetris - 80x23 terminal tetris

Dec 1, 2022
A C, C++ and Rust library to draw graphics with pixels in the terminal
A C, C++ and Rust library to draw graphics with pixels in the terminal

A library to draw graphics with pixels in the terminal Who needs a GUI when you have a terminal ? Building To generate libpluto.a, run: $ make To ins

Nov 7, 2022
📺🗿 Terminal graphics for the 21st century.
📺🗿 Terminal graphics for the 21st century.

???? Chafa is a command-line utility that converts all kinds of images, including animated GIFs, into sixel or ANSI/Unicode character output that can be displayed in a terminal.

Nov 29, 2022