Skip to main content
haagch
Up and Coming
September 23, 2015

Linux and remaining bugs in the SDK?

The argument was
- SDK 0.5 has linux support, and will allow you to continue development/utilize content created with that SDK

- Support for Mac and Linux us currently held on SDK 0.5. Versions beyond 0.5 Do not have Linux or Mac support. To continue using Linux, simply use that SDK.

(source: viewtopic.php?f=20&t=25463#p290736)

So viewtopic.php?f=34&t=16664 can be worked around because we have the source code. Unfortunately oculus never officially released a fix, so every developer who still uses that SDK

1) and who doesn't use mesa has to be aware that there is a problem with it
2) needs to work around it locally

That sucks a lot, but we can work with it.

But what about bugs in the ovrd service? It segfaults *a lot*. I have played for a few minutes with osvr-oculus-rift in the last few days and it segfaults almost every day I try to use it at least once:
TIME                            PID   UID   GID SIG PRESENT EXE
Mi 2015-09-16 10:12:00 CEST   31014  1000   100  11   /usr/bin/ovrd
Di 2015-09-22 12:15:38 CEST    8900  1000   100  11 * /usr/bin/ovrd
Mi 2015-09-23 10:40:52 CEST   29997  1000   100  11 * /usr/bin/ovrd


It contains no debug info whatsoever, so
(gdb) bt
#0  0x00000000004073a0 in ?? ()
#1  0x00000000004314a9 in ?? ()
#2  0x00000000004aa825 in ?? ()
#3  0x00000000004a9e40 in ?? ()
#4  0x00000000004a7c84 in ?? ()
#5  0x00000000004a7cd2 in ?? ()
#6  0x00007f0e607384a4 in start_thread () from /usr/lib/libpthread.so.0
#7  0x00007f0e5eff313d in clone () from /usr/lib/libc.so.6

is all we get. No idea why and where it's happening.

DK2 did mentioned Mac Linux and Windows, which it has supported.

Not ony were *the* selling points of the Oculus Rift like Unity and Unreal integration never really supported (what happened to the people "working" on unreal integration support for linux?), the SDK always had bugs that were never fixed like the two I mentioned.

I get that support for linux has been dropped, but as the oculus support said: Linux users can not get a refund and we are supposed to continue using 0.5. Obviously we don't have much use for a deprecated legacy SDK, but fortunately OSVR exists to show oculus how actual support for the DK2 looks like.

If oculus is serious about linux users to "just use 0.5", can we at least get an ovrd binary that works reliably without crashing all the time? Trying to use OSVR while ovrd keeps crashing is getting really annoying.
Keep all your "secrets" in your SDK locked up and as proprietary as you wish (what happened to "If anything, our hardware and software will get even more open, and Facebook is onboard with that."?), but give us a reliable way to get head tracking data... Please?

    5 replies

    creepytennis
    Participant
    September 30, 2015
    Hi,

    Thanks for this really insightful post. I also noticed your username on the Arch package page for osvr-oculus-rift-git so thanks for your contributions there.

    I share exactly your concerns about the "just use SDK 0.5" response. It barely works now, and as other parts of the typical system move forward, it will very quickly cease working at all.

    You build a strong case (stronger than mine!) that Oculus are not a trustworthy company. In my occasional checks back to this forum I take no pleasure seeing that they aren't very good at delivering things they promise on any platform, but Mac and Linux users can probably feel most aggrieved!

    Sadly Oculus seem to have decided they're a games company, and have adopted the same negligent (at times borderline-hostile) attitudes which blight that industry. Specifically: Do and promise what you want, and simply refuse to respond when you fail to deliver. The "cowboy contractor" approach.

    Their argument against refunding is nothing more that the fact that their terms of sale state "no refunds". I have no desire to test that in court - I suspect in many states and countries it would fail because implied warranties necessitate products are fit for purpose. But in any case on an ethical level they've undoubtedly cheated developers who invested time and money in them. For whatever reason (financial necessity?) they've had to sell out to several of the least open, least developer-friendly and least ethical companies in IT, so it seems at this point there is no point in serious people dealing with them any longer.

    The hope is that at some point we can reverse engineer the DK2 sufficiently to be useful. Thanks for helping with that! There's been some really great work in that regard posted on this forum in the past. Are there other places I should be looking in order to keep up with that, or to help where possible?
    haagchAuthor
    Up and Coming
    September 30, 2015
    I haven't actually helped reverse engineering the rift... That was doc ok and jherico alone I think.

    Is it ironic that currently a oculus founder is busy reverse engineering the vive tracking? https://twitter.com/mccauleylabs/status ... 1823428608

    Developer unfriendly? Impossibru!



    I must confess, I have never actually read http://www.ecis.eu/documents/Finalversi ... epaper.pdf. But I think I should...

    And yea, I sometimes play around and try to get things up and running. E.g. compiling OSVR-Unity and building a .unitypackage is actually possible on linux: https://github.com/OSVR/OSVR-Unity/issu ... -144330587. But then it's kinda jittery and not much of a pleasure to use, so I don't put really much time into it...
    shinyquagsire23
    Up and Coming
    December 25, 2015
    I don't usually like bringing up dead threads but I can't seem to find a fix for this. I literally *just* got a new monitor for my computer, upgraded from a 900p monitor to a 1080p one, and suddenly ovrd decides to segfault in this exact fashion. I actually bought the monitor so I could mirror what's on my Rift properly, but now I can't even get ovrd to even cooperate with me. The only thing that might be of significance is that my monitor is a 144Hz monitor vs 60Hz on my old one, perhaps this causes some issues? But even then, if I lower the Hz down to 60 it still fails.
    shinyquagsire23
    Up and Coming
    January 17, 2016
    Meh, did some experimentation with this issue. So ovrd can totally boot if I take out my 1080p 144Hz monitor and put in my 900p one at boot. Strangely, I can also take out my 900p monitor after ovrd starts and put in my 144Hz one and it still works, even if I kill it and start it up again, however my monitor's DPI was out of whack so taking a guess it's probably either a DPI or refresh rate issue.

    But because I could, and because it's not like Linux support will be moving anywhere anytime soon, I decided to throw ovrd into IDA to see what the real issue is. Probably against the EULA but screw it, I've already broken plenty of those doing other RE. Anyhow, laying it down:

    A call to XRRGetOutputProperty is made, returns an output or w/e. Some string from the output (not sure what, I'm more of an ARM person than x86 so I have a lot of guesswork to make) is then compared in some funky while loop to make sure it's completely empty in all 128 characters of it. Then it does some strncmp stuff or whatever to make sure the string is '\0'. The problem is, with my monitor XRRGetOutputProperty will return a null pointer, then the funky while loop will attempt to read from the null pointer, causing a segfault. At the moment I'm trying to find the cleanest way to fix this by just patching the existing executable alone so others with similar issues will at least have *some* sort of remedy in the mean time. Plus there's also the possibility that this hasn't been fixed at all even in the latest internal versions, so might be helpful.

    EDIT: I fixed it for myself, I replaced the weird while loop with

    test rcx, rcx
    jz abort_loc

    where abort_loc is the same location previously used by the weird while loop, plus a few bytes since that exit also has an XFree on the null string, which also would have segfaulted. If any other Linux users are having this issue, edit the bytes

    02 14 01 48 83 C0 01 48 3D 80 00 00 00 75 F1 84 D2 0F 85 56 01 00 00

    at offset 0x73A0 to be

    48 85 C9 0F 84 6C 01 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90

    and the issue will no longer occur, and the SDK and rift service will still function perfectly.
    creepytennis
    Participant
    February 3, 2016
    Thanks shinyquagsire23 you are a scholar and a gentleman.

    This kind of issue is exactly why Oculus saying "Linux users should just use the old ovrd version" is not a solution to their abandonment of the platform.
    Terms & ConditionsAccessibility statement