FBSERV(1)
π FBSERV(1) β the fbserv page, but make it make sense π
okay bestie, this is the manual for fbserv, hanging out in the BRL-CAD corner of your system. buckle up π
β¨ NAME β¨
fbserv β serve a BRL-CAD framebuffer to remote or local clients π₯οΈπ
π¦ SYNOPSIS π¦
fbserv [-v] [-T] [-A] [-{sS} squaresize] [-{wW} width] [-{nN} height] [-p port] [-F framebuffer] [port] [framebuffer]
fbserv [-v] [-A] [-F framebuffer] -I ipc_addr
πΈ DESCRIPTION πΈ
so fbserv opens a framebuffer and makes it available to BRL-CAD programs β the ones like rt(1), pix-fb(1), and fb-pix(1) that access a framebuffer over the libpkg protocol. it's literally the middleman and it's serving looks π
it can run in three ways, and yes you need to know all three:
- as a stand-alone daemon that forks a fresh server for each connection π
- as a single-framebuffer server that opens one device and holds it open across many interleaved connections π«Ά
- as an
inetd(8)remote framebuffer server π§
by default fbserv listens for TCP connections. the -p option sets the TCP port and the -F option names the framebuffer device. either may instead be given positionally: the first non-option argument is taken as the port and the second as the framebuffer device. a port below 1024 has 5559 added to it, so port 0 maps to the default 5559 β¨ (yes this is the whole trick, iykyk). when -F is given, fbserv opens that device immediately and keeps it open β that's a reattachable, state-preserving framebuffer bestie β otherwise the framebuffer named in each client's open request is opened and closed per connection. lowkey a big difference π
the -s (or -S) option requests a square framebuffer of the given size in pixels; -w (or -W) sets width and -n (or -N) sets height independently. if invoked from inetd(8) with an open socket on file descriptor 0, fbserv processes a single connection and exits. one and done π
with -I ipc_addr, fbserv uses a libpkg IPC transport instead of binding a TCP listener, and -p is ignored. listener-capable IPC addresses accept repeated local client connections; inherited endpoint addresses serve a single client, for parent/child process handoff. clients reach an IPC server using a framebuffer name of the form *ipc:*ipc_addr. note it, screenshot it, whatever π«Ά
β¨ OPTIONS β¨
-vβ enable verbose status output. she's chatty and we love that π¬-Tβ enable TLS encryption for protocol traffic. requires an OpenSSL-enabled build; theFBSERV_TLSenvironment variable has the same effect. secure the bag π-Aβ strict authentication: reject any client that does not present a valid token via the protocol authentication message. no token, no entry, periodt π«-ssquaresize,-Ssquaresize β request a square framebuffer of squaresize by squaresize pixels. square is the moment β¬-wwidth,-Wwidth β set the framebuffer width in pixels. wide girl summer π-nheight,-Nheight β set the framebuffer height in pixels. tall queen energy π-pport β set the TCP port number. ports below1024have5559added π-Fframebuffer β open framebuffer at startup and hold it open across all client connections. committed, unlike your ex π-Iipc_addr β use the libpkg IPC transport at ipc_addr instead of binding a TCP listener. the address is generated by the invoking application and should be treated as opaque. in this mode-pis ignored. don't peek behind the curtain οΏ½ curtain π§-h,-?β print a usage message and exit. the "help me help you" combo π
π₯ SECURITY π₯
token authentication works with or without TLS. if FBSERV_TOKEN is set in the environment (to 64 hex characters) before fbserv starts, that value is used as the required shared token; clients must set the same FBSERV_TOKEN value. if FBSERV_TOKEN is not set, fbserv generates a fresh token at startup and prints it to standard error. with -A, clients that do not authenticate are rejected; without it, unauthenticated clients are still accepted.
β οΈ bestie read that last sentence again. -A is the one doing the rejecting. without it, randos can still walk in. don't leave the door open and then act surprised π
π EXAMPLES π
Example 1. Reattachable framebuffer for rendering π¨
fbserv -s 1024 0 /dev/wgl &
rt -F 0 -s 1024 model.g component
open a persistent 1024x1024 framebuffer on the local display and bind it to port 0 (which maps to default port 5559), then ray trace into it with rt(1). because the device stays open, successive renders accumulate in the same framebuffer and the image survives between client connections. it's giving "persistence" and honestly? iconic β¨
Example 2. Authenticated TLS server π
export FBSERV_TOKEN=0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef
fbserv -T -A -p 0 -F /dev/wgl &
rt -F 0 model.g object
run fbserv in encrypted, strictly authenticated mode. both the server and every client must share the same FBSERV_TOKEN; the -T flag enables TLS (in an OpenSSL-enabled build) and -A rejects any client that fails to authenticate. shared secrets, shared vibes, no cap π
π¦ SEE ALSO π¦
brlcad(1), rt(1), pix-fb(1), fb-pix(1), fbclear(1), fbcmap(1), fbgamma(1), fbhelp(1), fbpoint(1), fbzoom(1)
go read the whole friend group, they're all slaying in their own way π
π AUTHOR π
BRL-CAD Team β yes the whole team, we stan π«Ά
π COPYRIGHT π
this software is Copyright (c) 1989-2026 by the United States Government as represented by U.S. Army Research Laboratory. that's a long run and honestly? main character energy π
π BUG REPORTS π
reports of bugs or problems should be submitted via electronic mail to devs@brlcad.org. found a bug? tell the devs, don't suffer in silence bestie ππ¬
β¨ that's the whole page β¨ brought to you by BRL-CAD, from the FBSERV(1) manual, dated right there in the 1989-2026 copyright line ππ go be great, and remember: keep your framebuffer open and your tokens shared π§ββοΈ
π¦ where this page comes from
- nixpkgs unstable: brlcad 7.44.0
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms