RTT Linux client possible?
-
Is there a chance we might see that? Could the server->client communication protocol be made open source so that someone knowledgeable in programming (=not me) could do it?
-
Is there a chance we might see that? Could the server->client communication protocol be made open source so that someone knowledgeable in programming (=not me) could do it?
Why doesn’t it work in wine? Is there a winedb bug raised for it?
-
Does wine provide Shared memory as this the method display extraction is based on and shared memory is a Windows OS functionality that BMS just uses
Gesendet von meinem SM-G930F mit Tapatalk
-
Pretty sure it does, yes. Have we tried running the program under wine to see if it works?
-
Display extraction and programs like YAME64 have worked fine under Linux so I don’t see why RTT shouldn’t work as well once DE becomes stable again in 4.35
All the best, Uwe
-
I want to use a Raspberry Pi for each MFD, I guess I have to go Raspbian->QEMU->Wine->RTT client?
-
Why qemu? I think you might not even need WINE. If you have a little bit of python / scripting skills it should be possible to read the textures from komurcu’s MFDE server, but yes, using WINE should also work. I’ve successfully used YAME64 on Linux in the past but that doesn’t seem to be an option for the textures atm because of its DX11 incompatibility (although apparently it still works for some).
All the best,
Uwe
-
-
I am also planning to use a RaspberryPI for my MFDs. But I rather would see a native client for the RPI than having to set up a windows emulation on top of an x386 emulation on a Linux/ARM platform in order to run the win RTT client.
That’s why I would give it a try to implement an ARM client if someone could provide more information about the UDP protocol that is used between the RTT Server and client. -
I am also planning to use a RaspberryPI for my MFDs. But I rather would see a native client for the RPI than having to set up a windows emulation on top of an x386 emulation on a Linux/ARM platform in order to run the win RTT client.
That’s why I would give it a try to implement an ARM client if someone could provide more information about the UDP protocol that is used between the RTT Server and client.Wine is not emulation.
-
Yeah, you are absolutely right, as the name already suggests. - How could I forget that in my first post…
But regardless, my point about the additional effort still holds true. It would be way easier to simply start one executable than having to set up multiple - let’s call it ‘layers of abstraction’ to enable the RPI platform to run a non-native executable. -
Yeah, you are absolutely right, as the name already suggests. - How could I forget that in my first post…
But regardless, my point about the additional effort still holds true. It would be way easier to simply start one executable than having to set up multiple - let’s call it ‘layers of abstraction’ to enable the RPI platform to run a non-native executable.You might have a look onto the MFDE which provides the same or better to say even more functionality as RTT and has a client/server as well and you have at least access to the source code in order to write a native RPI Client
https://github.com/lightningviper/lightningstools/tree/master/src/MFDExtractor -
Thanks for the hint. I already had a look at that repo a lot of times. It is a great source of information on how things work in BMS, not only DE. And I already implemented a small non-networked MFD viewer, that reads the information from shared mem based on the information I found in this repo. But if I would start at that point for this project, I would also have to write the server component myself and I specifically wanted to avoid to implement yet another server for another tool but wanted to extend on the RTT tools shipped with BMS. Since this tool now also supports other shared mem areas I think it could be used as a general server component for all kinds of client implementations so it could be regarded as the “official API” for cockpit extensions.
I like the FakeBMS approach of RTT that mirrors all the shared mem stuff on a remote machine so shared mem clients don’t have to bother whether they are running locally or remote but this is again only working for Windows.
The only/best way to include all those Linux based clients like RPI or embedded stuff like Arduinos is reading directly from the network as there is no (or very little) way to install Windows on these devices.
That’s why I believe it would be great if the RTT server would have a small manual similar to the keyfile-manual for the input that describes the UDP protocol / the output-side of things. -
You might have a look onto the MFDE which provides the same or better to say even more functionality as RTT…
Indeed, but this is what it’s author says about it:
I’ll be very interested in hearing if MFDE still works, because it is what I’m most familiar with… :whistle: .
Define “still works” MFDE is extremely obsolete, and has been for many years now. It dates back to 2007 and is built on antiquated 32-bit technology frameworks from the Windows 7 era like WinForms and non-hardware-accelerated 2D graphics technologies like GDI+. It’s now almost 2021. MFDE was dead a long time ago, but it just somehow keeps refusing to stop breathing. Damned zombie code.
-
What I found useful was not the MFDE itself but the shared memory part of the sourcecode that keeps updated with every BMS version. With it comes a shared mem tester that also includes a raw MFD texture export that works just fine even with this version. I tested it just yesterday.
But again: that doesn’t help with my current “requirement”.
-
Wasn’t komurcu’s mfde server source released a year ago or so as well?
All the best,
Uwe
-
Yes but I won’t go for that as it’s vb spagetti code
-
I spent a couple of minutes trying to find it’s sources yesterday only to dig a little deeper into that topic, without intending to really write my own or use it to connect my client to, but I wasn’t successful.
But even if I would have been, and could have come up with something based on this, it would still be another codebase that would have to be maintained with every update. Hence my approach connecting directly to a server that is shipped with BMS anyway. -
FYI,
I’m planning to add a writeup about the RTTServer network protocol and message formats for you gents and add it as part of the upcoming U1.
-
Thanks dunc, that’s really good news.
I already started with a client using a very simple own server and protocol just to be able to transmit some images to test visualization on the client-side.
Knowing that the docs will be released, I will now just wait for the release and then start to port my protocol to the official one.