If you have a spare machine, and if there is already a corresponding XML/hard-coded instrument available, your best bet is probably "slaving" multiple FlightGear instances together:
http://wiki.flightgear.org/Slaving_for_Dummieshttp://wiki.flightgear.org/Property_Tre ... ol_SlavingIf there is a Canvas based implementation instrument available, you can also stream that over http:
http://wiki.flightgear.org/Read_canvas_image_by_HTTP In that case, another option is:
http://wiki.flightgear.org/FGQCanvasAlso see James' comment here:
https://sourceforge.net/p/flightgear/ma ... /36327950/James Turner wrote:Drop the KLN-89 code, since it's unused and not maintained for a long time: Canvas and the regular GPS code can easily implement a working KLN-89 or similar equipment now
Speaking in general, legacy 2D instruments are in the process of being ported to be processed by the Canvas system, and hard-coded owner-drawn gauges (navdisplay, wxradar, agradaretc - but also the kln89b) are also in the process of being phased out in favor of a Canvas based approach.
This is primarily to modernize the rendering pipeline, so that more modern OpenGL code can be used. Which is why legacy OpenGL code needs to be updated/ported or re-implemented/wrapped by using a Canvas "adapter":
http://wiki.flightgear.org/2022.X_Release_Planhttp://wiki.flightgear.org/Post_FlightG ... onal_itemshttp://wiki.flightgear.org/FlightGear_and_OpenGL_EShttp://wiki.flightgear.org/Unifying_the ... via_canvasAgain, it's worth keeping in mind that thanks to the Canvas system, FlightGear is now capable of emulating fairly complex avionics like the Garmin-based FG1000:
In comparison, the KLN90B is rather simple and straightforward actually: