XEVI(3)

πŸ‘‘ XEVI(3) β€” X FUNCTIONS πŸ‘‘

okay bestie, pull up a chair, because we're in the X FUNCTIONS manual and today's main character is XEVI β€” the X Extended Visual Information era. πŸ’…βœ¨


πŸŽ€ NAME πŸŽ€

XeviQueryExtension, XeviQueryVersion, XeviGetVisualInfo β€” the X Extended Visual Information functions. say it with me now: extended visual information πŸ¦‹


🌸 SYNOPSIS 🌸

#include <X11/extensions/XEVI.h>

Bool XeviQueryExtension (Display *dpy);

Bool XeviQueryVersion (Display *dpy,
    int *major_version_return,
    int *minor_version_return);

int XeviGetVisualInfo (Display *dpy, VisualID *visual,
    int n_visual, ExtendedVisualInfo ** evi_return,
    int * n_info_return);

✨ DESCRIPTION ✨

so the X11 Extended Visual Information extension (EVI, for short, iykyk) lets a client figure out stuff about core X visuals that goes way beyond what the core protocol hands you. iconic behavior honestly. πŸ”₯

The EVI application programming library is literally just the interfaces described down below. πŸ’– but listen β€” with the one exception of XeviQueryExtension, if you call any of these routines on a display that does not support the extension, the ExtensionErrorHandler gets called (you can set that with XSetExtensionErrorHandler, and it functions the exact same way as XSetErrorHandler), and then the function just... returns. yeah. that's it. πŸ™ˆ

XeviQueryExtension returns True if the Extended Visual Information extension is available on the display you gave it. 🫢 and bestie this is not optional lore: a client must call XeviQueryExtension before calling any other EVI function, because that's how you negotiate a compatible protocol version. skip it and the client gets undefined behavior β€” meaning EVI may or may not work. no cap, that's genuinely undefined, so don't play with it. πŸ’€

XeviQueryVersion returns True if the request succeeded, and the major and minor protocol version that the server supports come back to you in major_version_return and minor_version_return. slay. ✨

XeviGetVisualInfo returns a list of ExtendedVisualInfo structures that describe visual information beyond what the core protocol supports. this includes layer info that matters for systems supporting overlays and/or underlay planes, plus info that lets applications better determine the level of hardware support for multiple colormaps. XeviGetVisualInfo returns Success if it worked, or an X error otherwise. 😭

  • if the visual argument is NULL, then info for all visuals of all screens is returned.
  • otherwise it's a pointer to a list of visuals you specifically want extended visual info for.
  • n_visual is the number of elements in the visual array.
  • evi_return returns a pointer to a list of ExtendedVisualInfo. when you're done, the client should free that list using XFree. don't leave it hanging, bestie 🧚
  • n_info_return returns the number of elements in the evi_return array.

The ExtendedVisualInfo structure has these fields, and yes you need every single one πŸ‘‘:

     VisualID        core_visual_id
     int             screen
     int             level
     unsigned int    transparency_type
     unsigned int    transparency_value
     unsigned int    min_hw_colormaps
     unsigned int    max_hw_colormaps
     unsigned int    num_colormap_conflicts
     VisualID *      colormap_conflicts

the combination of core_visual_id and the screen number uniquely specifies the visual being described. periodt. πŸ’…

level returns the level number for the visual: 0 for normal planes, > 0 for overlays, < 0 for underlays. main character energy at every level fr fr 🌈

transparency_type returns the type of transparency the visual supports:

  • XEVI_TRANSPARENCY_NONE if there are no transparent pixels
  • XEVI_TRANSPARENCY_PIXEL if the visual supports a transparent pixel
  • XEVI_TRANSPARENCY_MASK if the visual supports transparent plane(s)

transparency_value returns the pixel/plane value to set for transparency β€” but only if transparency_type isn't XEVI_TRANSPARENCY_NONE. πŸŽ€

min_hw_colormaps and max_hw_colormaps return the minimum and maximum number of hardware colormaps backing up the visual. πŸ’œ

num_colormap_conflicts returns the number of elements in colormap_conflicts. that array returns a list of visuals that may cause conflicts in the use of the hardware colormap. example time: if a 12-bit hardware colormap is overloaded to support 8-bit colormaps, then the corresponding 8-bit visuals would conflict with the 12-bit visuals. lowkey chaotic but that's the vibe. 😭


πŸ’€ ERRORS πŸ’€

XeviGetVisualInfo will return:

  • BadValue if you passed it an illegal visual ID πŸ™ˆ
  • BadAccess if the X server does not respond
  • BadAlloc if there's a memory allocation failure

and that's the whole page, bestie 🫢 this was X Version 11, libXext 1.3.6 β€” go forth and query your visuals, you absolute icon πŸ’–βœ¨πŸŒΈ

πŸ“¦ where this page comes from