stuck in a loop

Help
galtgendo
2013-05-09
2015-08-04
  • galtgendo

    galtgendo - 2013-05-09

    With uHexen2 v1.5.6, every now and then the game, upon entering menu/console, goes into sort of a loop, where it seems as if the key used to enter menu/console got stuck on autorepeat and the game was repeatedly entering/exiting the menu/console fast enough it never gets exited for long enough to be redrawn. At the same time the menu entering sound it constantly and rapidly restarted.
    The only way I found to stop it, once it gets stuck that way, was 'killall -9 glhexen2'.

    It seems to happen randomly after running for awhile.

    I'm not sure whether the problem lies in Thyrion or elsewhere.

    Did anyone else had experienced something similar ?

     
  • Ozkan Sezer

    Ozkan Sezer - 2013-05-10

    This feels like the game is somehow crashing (possibly a segmentation fault??) and the reason for the repeated sound is possibly the result of it because it isn't being updated at all. We will try to reproduce this by ourselves, but it would be really helpful if you can capture a backtrace of this. Thanks.

     
  • galtgendo

    galtgendo - 2013-05-11

    I don't think so.
    I've been running uHexen from a terminal - the only extra message printed was "Killed" upon 'killall -9' (note that simply 'killall' isn't enough). On that note - those beautifiers tend to look ugly in an vte-based terminal, but that's just the aesthetics.

    The thing that may or may not matter is that somewhen around the hang in the system log there's following message:
    usb 2-1.1: unlink qh8-0e01/ffff8801438a4880 start 4 [1/2 us]
    ehci-pci 0000:00:1d.0: reused qh ffff8801438a4880 schedule
    usb 2-1.1: link qh8-0e01/ffff8801438a4880 start 4 [1/2 us]

    It's an usb keyboard.
    It might play a role, that I often go "save/reload till succeed" route.

    Attaching gdb to such "hung" process doesn't show anything special either, just screen update and sound thread.

     
  • Ozkan Sezer

    Ozkan Sezer - 2013-05-11

    The thing that may or may not matter is that somewhen around the hang
    in the system log there's following message:
    usb 2-1.1: unlink qh8-0e01/ffff8801438a4880 start 4 [1/2 us]
    ehci-pci 0000:00:1d.0: reused qh ffff8801438a4880 schedule
    usb 2-1.1: link qh8-0e01/ffff8801438a4880 start 4 [1/2 us]

    It's an usb keyboard.

    Hmm, may it be that SDL is getting stuck somewhere while updating kbd,
    because we rely purely on SDL for that? Other than that, I am out of
    ideas.

     
    • Levent Yavas

      Levent Yavas - 2013-05-11

      keyboard seems faulty, I think...

      On Sat, May 11, 2013 at 9:34 AM, Ozkan Sezer sezero@users.sf.net wrote:

      The thing that may or may not matter is that somewhen around the hang
      in the system log there's following message:
      usb 2-1.1: unlink qh8-0e01/ffff8801438a4880 start 4 [1/2 us]
      ehci-pci 0000:00:1d.0: reused qh ffff8801438a4880 schedule
      usb 2-1.1: link qh8-0e01/ffff8801438a4880 start 4 [1/2 us]

      It's an usb keyboard.

      Hmm, may it be that SDL is getting stuck somewhere while updating kbd,
      because we rely purely on SDL for that? Other than that, I am out of
      ideas.


      stuck in a loophttps://sourceforge.net/p/uhexen2/discussion/425207/thread/6f168cfb/?limit=25#145e

      Sent from sourceforge.net because you indicated interest in
      https://sourceforge.net/p/uhexen2/discussion/425207/

      To unsubscribe from further messages, please visit
      https://sourceforge.net/auth/subscriptions/

      --
      Levent Yavaş
      KULE Tech. Ltd.
      www.kule.biz
      +90 505 5770478

       
  • Ozkan Sezer

    Ozkan Sezer - 2013-05-11

    keyboard seems faulty, I think...

    Very much possible.

     
    • galtgendo

      galtgendo - 2013-05-11

      Quite unlikely - I haven't seen this happen outside Thyrion.

      Note interesting point of gdb: once I attach it, the process obviously stops first, once I continue, it's back into the loop, if I send Ctrl-C to debugger, it gets correctly interrupted, but it's back in the loop, once it's resumed.

      Though there's that little thing: if "Enter" gets assigned to "Use inventory", often upon load the selected inventory item gets activated.
      Could it be that Thyrion probes the keyboard too fast (before key pressed status gets cleared ?) ?

       
  • galtgendo

    galtgendo - 2013-05-13

    Playing with the source, I got an odd result:
    once I've changed in in_sdl.c the lines with SDL_EnableKeyRepeat from SDL_DEFAULT_REPEAT_INTERVAL2 to SDL_DEFAULT_REPEAT_INTERVAL200, the game still gets stuck in menu, but the sound of entering it has time to be played to the end.

    So, here's a different idea: is it possible, that upon loading the game not everything gets reinitialized regarding the keyboard and parts of the code see the key as pressed, even though it's been already released ?

    Cause I've been able to trigger the problem by simply repeating a few times to press F3 to open load menu, then Enter to load. It might be that while entering the menu triggers the bug, it's already set up to fail once it's loaded.

     
    • Ozkan Sezer

      Ozkan Sezer - 2013-05-13

      On Mon, May 13, 2013 at 10:39 PM, galtgendo galt_gendo@users.sf.net wrote:

      Playing with the source, I got an odd result:
      once I've changed in in_sdl.c the lines with SDL_EnableKeyRepeat
      from SDL_DEFAULT_REPEAT_INTERVAL2 to SDL_DEFAULT_REPEAT_INTERVAL200,
      the game still gets stuck in menu, but the sound of entering it has
      time to be played to the end.

      So, here's a different idea: is it possible, that upon loading the
      game not everything gets reinitialized regarding the keyboard and
      parts of the code see the key as pressed, even though it's been
      already released ?

      Cause I've been able to trigger the problem by simply repeating a
      few times to press F3 to open load menu, then Enter to load. It
      might be that while entering the menu triggers the bug, it's already
      set up to fail once it's loaded.

      Do you mean that Key_SetDest() isn't called from some place where it
      actually should be and/or Key_SetDest() isn't doing its job properly?

       
  • Ozkan Sezer

    Ozkan Sezer - 2013-05-13

    Playing with the source, I got an odd result:
    once I've changed in in_sdl.c the lines with SDL_EnableKeyRepeat
    from SDL_DEFAULT_REPEAT_INTERVAL2 to SDL_DEFAULT_REPEAT_INTERVAL200,
    the game still gets stuck in menu, but the sound of entering it has
    time to be played to the end.

    So, here's a different idea: is it possible, that upon loading the
    game not everything gets reinitialized regarding the keyboard and
    parts of the code see the key as pressed, even though it's been
    already released ?

    Cause I've been able to trigger the problem by simply repeating a
    few times to press F3 to open load menu, then Enter to load. It
    might be that while entering the menu triggers the bug, it's already
    set up to fail once it's loaded.

    Do you mean that Key_SetDest() isn't called from some place where it
    actually should be and/or Key_SetDest() isn't doing its job properly?

     
    • galtgendo

      galtgendo - 2013-05-14

      What I want to say, is that it seems as if the problem was not "stuck keys" (cause they definitely aren't), but some software component (the game itself ? SDL ?) assuming they are stuck. Perhaps there's a rare race condition somewhere ?

      Just for the kicks, I've uncommented "printf("You pressed...)" line in IN_SendKeyEvents and simply did F3/Enter until it looped.

      The first repeats looked like this:
      Loading game...
      You pressed return
      You pressed F3
      You pressed F3
      You pressed return
      Client player removed

      The loop looked like this:
      Loading game...
      You pressed return (x8)
      You pressed F3 (repeated till killed)

      Given the keys were not held down long enough to be repeated (after all, I simply press them), it would seem the repeats are software generated.

       
  • Steven

    Steven - 2013-05-13

    I dont think linux USB keyboard support is terribly stable.
    Years ago, SDL stopped me from adopting a USB keyboard.

    If you have a PS2 port, try a PS2 keyboard and see if you can reproduce bug,
    or try a fairly different kernel/distro.

     
  • svdijk

    svdijk - 2013-05-14

    Playing with the source, I got an odd result:
    once I've changed in in_sdl.c the lines with SDL_EnableKeyRepeat from SDL_DEFAULT_REPEAT_INTERVAL2 to SDL_DEFAULT_REPEAT_INTERVAL200, the game still gets stuck in menu, but the sound of entering it has time to be played to the end.

    If changing the SDL repeat interval has any influence, this strongly suggest that it is SDL that believes that the key is still down rather than Hammer of Thyrion itself. What version of SDL are you using?

     
  • galtgendo

    galtgendo - 2013-05-14

    It has influence, but very little - only on frequency of restarts of the sound of opening the menu. SDL is 1.2.15.

    If it's not a stuck state in the game itself, perhaps the game misses SDL_KEYUP under some circumstances - I might be a bit too focused on engine restart on loading a save, but this seems to be the most likely branch of code, given how I trigger the bug.

    Another option might be buried in keys.c Key_Event comment - "Should NOT be called during an interrupt!".

    A method to test this still flees me.

     
    • Levent Yavas

      Levent Yavas - 2013-05-14

      sources could be modified to automatically fire a SDL_KEYUP after 5 seconds
      and write a debug log.

      I don't think SDL on linux ever sees an interrupt function

      On Tue, May 14, 2013 at 10:49 PM, galtgendo galt_gendo@users.sf.net wrote:

      It has influence, but very little - only on frequency of restarts of the
      sound of opening the menu. SDL is 1.2.15.

      If it's not a stuck state in the game itself, perhaps the game misses
      SDL_KEYUP under some circumstances - I might be a bit too focused on engine
      restart on loading a save, but this seems to be the most likely branch of
      code, given how I trigger the bug.

      Another option might be buried in keys.c Key_Event comment - "Should NOT
      be called during an interrupt!".

      A method to test this still flees me.

      stuck in a loophttps://sourceforge.net/p/uhexen2/discussion/425207/thread/6f168cfb/?limit=50#dc4a

      Sent from sourceforge.net because you indicated interest in
      https://sourceforge.net/p/uhexen2/discussion/425207/

      To unsubscribe from further messages, please visit
      https://sourceforge.net/auth/subscriptions/

      --
      Levent Yavaş
      KULE Tech. Ltd.
      www.kule.biz
      +90 505 5770478

       
  • galtgendo

    galtgendo - 2013-05-14

    Well, having a piece of code (and the place to put it), that would compare SDL state (probably based on SDL_GetKeyState ?) with game's state would certainly help with finding the place where things go wrong.

     
  • svdijk

    svdijk - 2013-05-15

    It has influence, but very little - only on frequency of restarts of the sound of opening the menu. SDL is 1.2.15.

    Sure, but it indicates that the key repeating that SDL does plays a role; since it has any effect at all, it seems likely that it is SDL that is sending repeat events for your keys. (If it didn't, changing the repeat rate shouldn't have had any effect.)

    If it's not a stuck state in the game itself, perhaps the game misses SDL_KEYUP under some circumstances - I might be a bit too focused on engine restart on loading a save, but this seems to be the most likely branch of code, given how I trigger the bug.

    Exactly. You could test this by changing the

    printf("You pressed %s (%d) (%c)\n", SDL_GetKeyName(sym), sym, sym);
    

    that you uncommented to

    printf("You %s %s (%d) (%c)\n", (event.type == SDL_KEYUP ? "released" : "pressed"), SDL_GetKeyName(sym), sym, sym);
    

    And then try to trigger the issue again. My guess is that you won't see (m)any "released" events once you're in the loop.

     
    Last edit: svdijk 2013-05-15
  • galtgendo

    galtgendo - 2013-05-15

    I've modified the line a little bit more and accidentally stumbled on an interesting result.

    printf("You %s %s (%d) (%x)\n", (event.type == SDL_KEYUP ? "released" : "pressed"), SDL_GetKeyName(sym), sym, sym, Key_GetDest());

    (%c doesn't make sense for >255, destination looked useful)

    In one of the earlier edits I've commented SDL_EnableKeyRepeat lines and forgot about it.

    The output was:
    - before loop
    - Loading game...
    You released return...at 0
    You pressed F3...at 0
    You released F3...at 4
    You pressed return..at 4
    Client player removed
    - in the loop
    Loading game...
    You pressed F3...at 0

    once I restored repeats, the loop was Enter at 0, a single F3 at 0, then F3 at 4 till kill - all of it presses.

    So things go wrong once release of Enter gets lost. Looks like a software failure (as, IIRC, if it was a stuck key, releases would be generated too), but hard to tell where.

     
  • svdijk

    svdijk - 2013-05-15

    once I restored repeats, the loop was Enter at 0, a single F3 at 0, then F3 at 4 till kill - all of it presses.

    That's what I expected, and it indicates what I suggested: SDL seems to "think" that F3 is still down, and hence keeps sending repeating events for it.

    So things go wrong once release of Enter gets lost. Looks like a software failure (as, IIRC, if it was a stuck key, releases would be generated too), but hard to tell where.

    Like I said, this looks like a problem at the SDL side. (Btw, I don't understand why you would expect release events for a stuck key; I'd say that as long as SDL believes the key to be down it would make sense for it to not send a release event but keep sending repeating press events, which seems to be happening.)

    I'm thinking that this could possible be related to switching unicode handling in a running program, it might be that SDL gets confused by that (though I've never had any problem with that myself). Can you try to comment out all the

    SDL_EnableUNICODE(!gamekey);
    

    calls is in_sdl.c and see if you can still trigger the problem?

     
  • galtgendo

    galtgendo - 2013-05-15

    I don't understand why you would expect release events for a stuck key

    Cause if it was physically stuck, keyboard repeat would autorepeat would have kicked in, no ?

    Anyway, while due to randomness I can't be 100% sure it fully solves the problem, it's not getting triggered as easily. Actually, it seems that only the call in IN_SendKeyEvents matters (or at least I don't know the conditions needed to trigger it on the other 2 calls).

     
  • svdijk

    svdijk - 2013-05-16

    I don't understand why you would expect release events for a stuck key

    Cause if it was physically stuck, keyboard repeat would autorepeat would have kicked in, no ?

    Yes, and that would give precisely the results that you are getting, e.g. repeated "pressed" events, without any "released" events in between.

    I'm getting the feeling that you think that SDL would would be sending alternating "pressed" and "released" events for a physically stuck key, but you can see for yourself that this isn't the case by simply holding down a random key for a while; you'll see repeated "pressed" events without any "released" events in between, until you actually release the key, at which moment you'll see a single "released" event.

    Anyway, while due to randomness I can't be 100% sure it fully solves the problem, it's not getting triggered as easily. Actually, it seems that only the call in IN_SendKeyEvents matters (or at least I don't know the conditions needed to trigger it on the other 2 calls).

    Can you try these two cases:

    Case 1:

    • Comment out the SDL_EnableUNICODE(!gamekey) call in IN_SendKeyEvents().
    • Change the SDL_EnableUNICODE(!gamekey) calls in IN_Init() and IN_ReInit() to SDL_EnableUNICODE(0).

    Case 2:

    • Comment out the SDL_EnableUNICODE(!gamekey) call in IN_SendKeyEvents().
    • Change the SDL_EnableUNICODE(!gamekey) calls in IN_Init() and IN_ReInit() to SDL_EnableUNICODE(1).

    Is your issue reproducible in any or both of the cases?

     
    Last edit: svdijk 2013-05-16
    • galtgendo

      galtgendo - 2013-05-16

      Neither of those two cases seems to produce the hang.

       
  • Ozkan Sezer

    Ozkan Sezer - 2013-05-17

    Neither of those two cases seems to produce the hang.

    You mean that you can reproduce the issue with even after doing the
    described changes, yes? If that is the case, I tend to agree with
    Sander that the this issue isn't in uhexen2, but is instead triggered
    by some unfortunate combination of factors at the SDL level or below.

    One last thing to test would be running and old enough uhexen2 version
    such as 1.5.1 or 1.5.2 to see whether the issue is reproducible.

     
    • galtgendo

      galtgendo - 2013-05-18

      No, the exact opposite: as long as the IN_SendKeyEvents call is off, hardcoding to either value in Init/Reinit doesn't seem to matter; the freeze seems not reproducible under such conditions.

       
  • Ozkan Sezer

    Ozkan Sezer - 2013-05-22

    I see. So both of the suggested changes eliminate the freeze you've been experiencing. We'll try to work on this and update this thread.

     
  • Ozkan Sezer

    Ozkan Sezer - 2013-05-22

    BTW, do you experience the issue in QuakeSpasm?
    (http://sourceforge.net/projects/quakespasm/)
    I'm asking, because the code is very similar.

     
  • Ozkan Sezer

    Ozkan Sezer - 2013-05-23

    galtgendo: Does the following patch help?
    http://uhexen2.sourceforge.net/tmp/in_sdl.patch

    (We are still interested in your experience with
    quakespasm wrt this keys issue, if you can.)

     
    • galtgendo

      galtgendo - 2013-05-26

      No, for whatever the reason it doesn't.
      Odd, looking at the patch, it indeed looked like something that should have helped.

       
  • Ozkan Sezer

    Ozkan Sezer - 2013-05-27

    OK then. Can you please:
    - Test QuakeSpasm to see whether you have the same issue with it?
    - Give me an almost foolproof way of reproducing the issue by myself?

     
    • galtgendo

      galtgendo - 2013-05-27

      Well, AFAICT, QuakeSpasm isn't affected (or at least triggering isn't as trivial). On a related note, I'd have been nice if in its readme there was a note on how to use it - sending people on wild goose chase for a faq with details like directory structure/lowercase files was a bit annoying.

      As for a way to trigger it, I already said, what the most trivial method is: load a game, then press F3 (Load menu)/Enter (Confirm) alternatively (usually in less than 6 repeats it freezes).

       
  • Ozkan Sezer

    Ozkan Sezer - 2013-05-29

    Well, AFAICT, QuakeSpasm isn't affected (or at least triggering
    isn't as trivial).
    [...]
    As for a way to trigger it, I already said, what the most trivial
    method is: load a game, then press F3 (Load menu)/Enter (Confirm)
    alternatively (usually in less than 6 repeats it freezes).

    OK. I still can't reproduce this myself, nor have any of our other
    developers said so. We'll still go after this, though.

    In the meantime, it may help if you tell us:
    - which distro you are running on including cpu-arch, glibc version
    - which compiler you are using (gcc/clang + binutils -- assuming that
    you are compiling your own binary) along with any source/build system
    changes you are doing (if any.)
    - which SDL version
    - versions of multimedia dependency libraries (libogg, libvorbis, mad)
    as well as what timidity patches you are using, if any. (these need
    not be related at all, but just in case..)

     
    • galtgendo

      galtgendo - 2013-05-29

      Technically, it's gcc 4.5.4, binutils 2.22, glibc 2.15, but it matters little - I can trigger it with amd64 binary from sourceforge too.
      Timidity patches don't matter either: not only I've set USE_MIDI=no in Makefile, but all of the tests (including sourceforge binary) were with '-nomidi' ((nearly) all were also with '-sndspeed 48000 -vsync'). SDL version given above. libogg 1.3.0, libvorbis 1.3.3, libmad 0.15.1b (but -nosound doesn't make a difference either).

       
  • Ozkan Sezer

    Ozkan Sezer - 2013-06-12

    Does the -nomouse command line switch make any difference?
    If it does, Sander may have an idea about fixing this.

     
    • galtgendo

      galtgendo - 2013-06-15

      Well, yes and no.
      Given the random nature of the freeze, I can't be 100% sure, but it seems, that with '-nomouse', the average number of tries needed to freeze is at least 2-3x as big.

       
      • svdijk

        svdijk - 2013-06-15

        Can you try the attached patch and let us know if the issue is still reproducible with it?

         
        Last edit: svdijk 2013-06-15
        • galtgendo

          galtgendo - 2013-06-15

          Again, no guaranties, but it does seem to fix the freeze.

          On a not quite related note:
          - would it be possible to make Eidolon's Lair playable with 'notarget' ?
          now, due to an old fix, Eidolon stays invulnerable till he spots the player
          - thorough the game, there were several spots where pools were much harder to get out of than they should (or sometimes even impossible); am I that bad player or is i.e. something like jump height in water set too low ?

           
          • svdijk

            svdijk - 2013-06-16

            Ok, good to hear this does seem to fix it, I've just pushed this patch to the SVN repo. If you ever experience this freeze again please don't hesitate to let us know.

            Regarding the hard-to-get out of pools: I know there are some, especially the one in the bedroom in "Palace Entrance". They aren't that hard to get out of once you know how to do it: first of all, don't use the "jump / swim up" key; for some reason, pressing it actually makes it harder to get out of (some) pools. Usually it is enough to dive under water, and then "run" upwards under a slight angle towards the edge of the pool. If that doesn't help, try using the "swim up" key (this is a separate key that behaves different than the "jump / swim up" key). Since this is physics related, I doubt there's much that we can do about it without the risk of breaking other things.

            Can you please open a new thread for the Eidolon issue?

             
            • galtgendo

              galtgendo - 2013-06-16

              Looks like you're right about that separate key - pity about the design, though.

              Thanks for the help.

               
            • galtgendo

              galtgendo - 2013-12-17

              Sorry for reviving this, but could you explain what could have been the problem ?
              I seem to have a similar problem in zdoom (well, similar cause input freezes and commenting SDL_EnableUNICODE helps), but upstream can't reproduce it. Even I can't on a different machine, that while significantly different hardwarewise (for a lesser example, keyboard on ther other machine is PS2, not USB), is pretty much alike in terms of installed library versions.
              Looking at SDL sources, SDL_EnableUNICODE should have much of an effect, it just flips SDL_TranslateUNICODE, which seems to be referenced only by src/video/x11/SDL_x11events.c in this case.

               
              • galtgendo

                galtgendo - 2014-03-06

                Well, in the meanwhile, there's been both progress and no progress.

                It seems that the problem is actually a bug in SDL, that's only triggerable if you have an IME running and XMODIFIERS is set to the value proper for that IME.

                Unfortunately, it looks like as this is a bug in SDL1, the upstream is not interested in looking for a fix.

                I wonder a bit how the change in Thyrion managed to workaround that deadlock (or - given the random nature of the freeze - did it made just significantly harder to trigger).

                 
  • Ozkan Sezer

    Ozkan Sezer - 2014-03-06

    Interesting that it is an SDL1 bug regarding IME, and that's possibly
    why we never managed to reproduce the issue by ourselves. Do you have
    a pointer to an SDL bug report and how it is fixed in SDL2?

    The fix we merged changes the way we handle mouse enabling/disabling
    under certain circumstances: some of such circumstances change the
    way we handle certain keyboard keys, e.g. the numpad keys.

    For the record though, the "fix" we merged resulted in a regression:
    Run glhexen2 (I am running windowed), press F3, use up/down arrows to
    select a save, press Enter to load. When it loads, press Enter to use
    an inventory item (scrolling the inventory by the mouse wheel doesn't
    change the result): it doesn't at first hit, but it does upon hitting
    enter the second time. it works fine after that. I am uncertain as to
    how I handle this, possibly revert the "fix"? Don't know.

     
    • galtgendo

      galtgendo - 2014-03-14

      The upstream bug is https://bugzilla.libsdl.org/show_bug.cgi?id=2325 - it's in the process of being ignored.

      The bug has a link to sdl forum thread discussing something that I suspect was a similar problem. I'm not sure if it's really the same, therefore fixed in SDL2, but there are strong hints it is.

       
      • Ozkan Sezer

        Ozkan Sezer - 2014-03-14

        Does a patched SDL acc. to https://bugzilla.libsdl.org/show_bug.cgi?id=2325#c2 fix your issue then?

         
        • galtgendo

          galtgendo - 2014-03-14

          Well, it seems to fix help, but I already said a few times, that I'm at least 85% sure that patch is wrong - it was simply cargo-culted, badly at that.

           
          • Ozkan Sezer

            Ozkan Sezer - 2014-03-14

            I see. (BTW, I only noticed now that you are the originator of the SDL bug report.)

             
  • rodrigorum

    rodrigorum - 2015-08-04

    Hi all, I just installed Hammer of Thyrion in my lubuntu 14.10 and I'm having a blast. However, I'm having this same issue. I'm adding this comment just to make it "two users" having it. :D Anyway, what's the best way to apply the patch? Actually, is there a way I can apply it without downloading the source and compiling the game myself? I'm no linux expert and it's been a while ever since I compiled a game. My sdl version seems to be already 1.2
    libsdl-image1.2:amd64
    libsdl1.2debian:amd64
    1.2.15-10ubuntu1
    1.2.12-5build2

    Regards.

     
    • Ozkan Sezer

      Ozkan Sezer - 2015-08-04

      Unfortunately you need to patch SDL yourself and recompile+reinstall. Or, report the issue to debian and/or ubuntu so that they can provide an updated and fixed SDL package. I myself did that for Fedora (https://bugzilla.redhat.com/show_bug.cgi?id=1126136) and they did deliver a fixed SDL.

       

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks