oxff

There's no boot screen and when turned off it stays green. I managed to get a video under the upload size limit. Edit: Looks like the video isn't working for me so please let me know if it's DOA for you as well. It shows in the message preview just not after I post it. 1568853696_SR22TN_AVIDYNE_DFC90-2022-02-0723_11_38.avi

There are and here's what I see in that directory: $ ls 0.png ALT.png CLOCK_7.png FLIGHT_TIME.png PRESSURE_ALT.png 1.png CLOCK_0.png CLOCK_8.png FL.png REPLYin.png 2.png CLOCK_1.png CLOCK_9.png IDENT.png REPLY.png 3.png CLOCK_2.png COLON.png LOAD_BAR.png SBY.png 4.png CLOCK_3.png CONTRAST.png LOAD_BOX.png 5.png CLOCK_4.png COUNT_DOWN.png LOAD_SCREEN.PNG 6.png CLOCK_5.png COUNT_UP.png ON.png 7.png CLOCK_6.png DISPLAY.png PRESSURE_ALT2.png

Sure thing! 3 photos attached. First is initial load cold and dark, second is powered on with datarefs, and third is cold and dark after power on. Hopefully the forum puts them in the right order, if not, they go in timestamp order.

The buttons are working in terms of changing datarefs. It's just the screen that is blank. With the aircraft cold and dark, the screen is still lit up if that gives you any clues. If there are any datarefs that control this, let me know what to look for I'm happy to provide them.

Thank you Coop! Let me know if you need anything from me or want me to test something. I ran thru the majority of the systems and the only issue is the transponder. Datarefs show it's operational, it's just not displaying. Adding my log just in case. Log.txt

I would suggest you reread this thread because I've done no assertion of what you claim I have. You are putting words in my mouth and that is not appreciated. The only one coming into this thread asserting any attitude is you. My questions are completely legitimate regarding a product I purchased that is marked as having Linux support and hasn't worked since release (almost a year). I would like to point out this line in particular. I understand Linux can be and is a pain and I understand business objectives change. I would say I've been extremely patient, so asking if Linux support is still on the horizon is not a far fetched question given it's been a year. This attitude wouldn't fly in any sales market. Imagine the outrage this would generate if this was applied to a non-software product. If you bought a car that advertised left and right turns, but then the steering wheel would not turn left, there would be problems. I work with vendors on a daily basis to get software running on Linux, it's only hard when you come into it with assumptions based on how Windows works. Such as building to a dot release specific version of software (just statically link), hard coding paths, or playing games with capitalization. Being Linux is the #1 server OS, it's obviously not too hard to support otherwise these large legacy IT enterprises would stick with a Unix like Solaris or AIX. I am doing exactly this and have said nothing about Coop so again to assert that I am doing otherwise is putting words in my mouth and conflating my intentions with your assumptions. I'm sad to see I've stirred up your saltiness but I hope you have a better day. Thank you! I placed the file and loaded the plane (before coping over OpenGPWS) and XP crashed. I then copied over OpenGPWS from the TBM900 and tested again. This time the aircraft loaded and is thus far functional. I will run it through some testing and report back. I took a look at the OpenGPWS.xpl and it was compiled for System V instead of Linux. This should be an easy argument change depending on how you're building/sourcing the software. Shipped with the SR22: $ readelf -h OpenGPWS.xpl ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: DYN (Shared object file) Machine: Advanced Micro Devices X86-64 Version: 0x1 Entry point address: 0x59800 Start of program headers: 64 (bytes into file) Start of section headers: 19413912 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 56 (bytes) Number of program headers: 8 Size of section headers: 64 (bytes) Number of section headers: 36 Section header string table index: 35 TBM900: $ readelf -h OpenGPWS.xpl ELF Header: Magic: 7f 45 4c 46 02 01 01 03 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - GNU ABI Version: 0 Type: DYN (Shared object file) Machine: Advanced Micro Devices X86-64 Version: 0x1 Entry point address: 0x6b000 Start of program headers: 64 (bytes into file) Start of section headers: 33307976 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 56 (bytes) Number of program headers: 8 Size of section headers: 64 (bytes) Number of section headers: 38 Section header string table index: 37 ps. Please don't take Cameron's representation of me as who I really am. I will help you debug until I'm blue in the face and I understand that issues occur and business objectives change. I'm not concerned with any of that as I understand how things go. I've been a Unix engineer in large enterprises for the past decade so I've seen my share of this.

Thanks Coop for coming back and luckily I'm familiar with the log. Looking thru it, it's the same errors reported in my first post in this thread but since you asked, here is the log. I'm curious where we go from here? The fix for these errors were supposed to be in 1.0.2, then in 1.0.2b, and now we're at 1.0.3 with the same issue. sr22Log20220206.txt

Figured since I started this thread almost a year ago now I should post an update. A few minutes ago I installed 1.0.3. Tho there was no Linux installer, the Windows one worked just fine in Wine (minus some small graphical issues) so no problem. It would appear the issue I reported is still happening and the aircraft is still not flyable. Click anything and you get a generic "ohooooooh" sound. So here's my question. Is there a working (or will be a working) Linux build? I'm really trying to not come in here with negativity but it's hard when I spent $60 on aircraft marketed as having Linux compatibility but then not being able to use it due to bugs and a year later seeing the same issue. If Linux support is still being fixed then no problem. But if this has fallen off the table and won't really be worked on, I would ask that the Linux support be removed from the item listing and I'll submit for a refund. Hopefully if I have to go down the refund route I won't have issues like the previous poster did, I would hate for this to turn into false advertising. BUT like I said previously. I'm trying to not be negative and still have hope this will work.

What can I do to assist you with the troubleshooting and fix?

Just installed the SR22 Entegra Series today. Installed just like the TBM which was nice. When I started XP and loaded into the aircraft, nothing worked and I'm getting a thunking sound backed up with either a mooing or a "oh ohhhh" sound. It's a little hard to tell. I went thru my Log and found quite a few errors. A snip of is below. dlerror:/home/tim/X-Plane11/Aircraft/X-Aviation/SR22 Series Entegra/TorqueSim SR22TN Entegra/plugins/OpenGPWS/lin_x64/OpenGPWS.xpl: undefined symbol: sio_getpar dlerror:/home/tim/X-Plane11/Aircraft/X-Aviation/SR22 Series Entegra/TorqueSim SR22TN Entegra/plugins/sr_systavi/lin_x64/sr_systavi.xpl: undefined symbol: ASN1_ANY_it 0:01:25.319 E/SOUN: The sound event event:/cb/cbPush has an invalid command trigger afm/sr/cmd/cb/r3c08 0:01:25.319 E/SOUN: snd error in file: Aircraft/X-Aviation/SR22 Series Entegra/TorqueSim SR22TN Entegra/fmod/SR22TN_AVIDYNE_DFC90.snd line 2482 0:01:25.319 E/SOUN: The sound event event:/cb/cbPush has an invalid command trigger afm/sr/cmd/cb/r3c09 0:01:25.319 E/SOUN: snd error in file: Aircraft/X-Aviation/SR22 Series Entegra/TorqueSim SR22TN Entegra/fmod/SR22TN_AVIDYNE_DFC90.snd line 2488 0:01:25.319 E/SOUN: The sound event event:/cb/cbPush has an invalid command trigger afm/sr/cmd/cb/r3c10 0:01:25.319 E/SOUN: snd error in file: Aircraft/X-Aviation/SR22 Series Entegra/TorqueSim SR22TN Entegra/fmod/SR22TN_AVIDYNE_DFC90.snd line 2494 This brought me to the forums here and after reading the "Switches don't work" thread, and realizing what I'm seeing looks like a failed activation. I went looking for Gizmo. And I did indeed find a Gizmo error. dlerror:/home/tim/X-Plane11/Resources/plugins/Gizmo64.plugin/lin_x64/Gizmo64.plugin.xpl: invalid ELF header It's modified date under plugins, including the directories under Gizmo64.plugin are from today, however the big notable difference is when I look at the XPLs for Windows and Mac. They're dated 3/15/2021 whereas the Linux plugin is dated 2/25/2018. Gizmo's website says there is no Linux version and there's a bug report that's been open since 2017 on Github. I'm curious how this is supposed to work on Linux or if the Linux support indicator on X-Aviation was a mistake?