accept_target(3)

💖 NAME 💖

accept_target — bestie, this is the one that accepts a pending target request for a new segment. Yep, that's the whole vibe. (Oh, and hi, you're reading the Arcan Lua API manual, welcome, pull up a chair 🫶)

---

✨ SYNOPSIS ✨

First line is what you get back, the next two are how you call it — pick whichever signature matches your situation:

vid:new_vid, aid:new_aid, int:cookie
accept_target( int:setw, int:seth )
accept_target( int:setw, int:seth, func:callback )

---

🌸 DESCRIPTION 🌸

Okay so picture this: a connected frameserver gets one segment by default. That's it. One. But it can ask for more, and when it does, a segment_request event gets sent through to the callback associated with that frameserver. 💅

Now here's the part where you gotta pay attention, because if that request goes unhandled in your callback implementation, a rejection reply will be sent. Not dramatic, just facts. So if you actually want the segment, you call accept_target in immediate response to the segment_request, and a new segment gets allocated and sent to the frameserver. Slay. ✨

The type of this new segment will follow the one present in the request — and listen, it is your responsibility as the script author to determine that this is one you actually support. To filter the segkind field, prefer a whitelisting approach. Not a blacklist, a whitelist. Iykyk. 🧚

The optional arguments setw and seth can be used to change the initial dimensions of the new segment from the ones requested in the segreq event (peep launch_target for that one). The frameserver can still perform a resize to ignore these values — it's not a lock, bestie — but it saves you a possible displayhint->resize cycle along with the initial 1-2 frame setup latency that cycle would impose. Lowkey a huge W. 🔥

The optional argument callback sets the event handler for the new segment, but ngl you can also change it later with calls to target_updatehandler. Options, we love them.

On success, the function returns reference handles to the new audio and video resources, along with an identification token that might be used by the client for reparenting in viewport events. Iconic return value, honestly. 👑

---

👑 NOTES 👑

1. accept_target is context sensitive. Which means calling it outside a frameserver event-handler, or when there is no pending segment_request event, is a terminal state transition. Not "oops teehee", it's terminal. Do not. 💀
2. Possible segkind values for a subsegment are: "multimedia", "cursor", "terminal", "popup", "icon", "remoting", "game", "hmd-l", "hmd-r", "hmd-sbs-lr", "vm", "application", "clipboard", "browser", "encoder", "titlebar", "sensor", "debug", "accessibility". That's the whole menu, no substitutions. 🍓
3. The number of permitted segments etc. should be limited by available vids and other resources — because otherwise a malicious client can starve the serving arcan process. Fr fr, don't let them. See the 'recursive_evil' security test case for more detail. 🙈
4. Subsegments are always bound to the primary segment. So attempts at complex hierarchies — like a main-window with a popup window with a titlebar with an icon — are not possible directly, though viewport hints can be used to describe such relations superficially. Superficially! That word is doing so much work. 😭

---

🎀 EXAMPLE 🎀

function accept_target0()
      target_alloc("test", function(source, status)
            if (status.kind == "segment_request") then
-- possibly ignore request if supplied properties e.g.
-- dimensions or subtype is not permitted.
                  accept_target();
            end
      end)
end

See how it's right there in the handler, immediately answering the segment_request? That's the whole move. 🦋

---

🌈 SEE ALSO 🌈

• target_alloc(3)

---

That's the page, bestie! 💖 This little masterpiece comes to you from the targetcontrol corner of the world, dated October 2026 — go forth and accept those targets responsibly, and remember: whitelist, don't blacklist. Mwah. 🫶✨🎀