kanato's picture

OpenTK on non-debian based distros

Has anyone else run OpenTK on non-debian based distros? It seems a lot of people here use Ubuntu. I ask because I've been trying different distros to see what I like and I've been having issues with OpenTK in OpenSUSE 10.3 and 11.0, and Fedora 10. I have Debian Lenny, OpenSUSE 11.0 and Fedora 10 installed on separate partitions on my laptop, so in all my tests the hardware is the same (although the kernel versions and hence drivers are not). All of these tests are done without having compiz enabled or anything like that. Also, for all tests direct rendering is enabled. It uses the Intel GMA965 driver.

Everything seems to work fine in Debian Lenny for both OpenGL and OpenAL (although I notice that openal is libopenal.so.1 instead of the libopenal.so.0 that is in the OpenTK.config.dll).

OpenSUSE 11 64-bit
In OpenSUSE I see the worst behavior. Most of the time when creating a GameWindow I get a situation where the system seems to ignore any mouse clicks or keyboard input except for CTRL-ALT-(F keys or backspace) and the only way to terminate the program and restore normal input is by switching to a virtual terminal and killing mono through top. This is best seen by running the immediate mode example; the program obviously is running because the cube is spinning but I can't close the window. Sometimes this doesn't happen, but if I close an example that works and reopen it I get this sort of lockup. Also, it doesn't seem to be playing well with mono-winforms because when a GameWindow is openned, the example launcher window stays open but does not update. Sometimes I get a real hard lockup, where I can't even switch to virtual terminals or use ctrl-alt-backspace to kill X.

OTOH, examples which render to a WinForms control (either GLControl or in AgateLib using AgateRenderTarget) seem to work fine.

Occasionally I get an issue where I am moving an OpenTK window around with the mouse I will get a hard lockup and have no choice but to reboot the machine. This may be a kernel driver issue, as I can't seem to get it to happen in Debian or Fedora both of which have newer kernels. (I have been unsuccessful at updating the kernel on my laptop, it seems to not compile in the SATA driver and I haven't figured out yet what option in the config I need to enable.)

Crashes with a long error message. The stacktrace seems to indicate that says "OpenTK.Audio.AL.BufferData" is the culprit.

Fedora 10 32-bit
I see some of the same issues as OpenSuse here. The OpenTK gamewindow does not play nicely with mono's winforms because the example launcher window does not disappear or update. I also get the input ignoring state, but I sometimes have to open up to 7 example windows in the example launcher before it will happen.

If I run the "OpenAL: Playback" example once, it says "Testing WvaeReader... Playing" but no sound is heard. If I run it a second time without killing the example launcher it throws an AudioDeviceException "Audio device 'default' does not exist or is tied up by another application." If I run my own AudioPlayer test that uses AgateLib, it crashes with a segmentation fault and no other information.

Debian Lenny 64-bit
I've tested all of these issues pretty thoroughly on Debian, and I can't reproduce a single one. Everything seems to work as expected, aside from the libopenal.so.0 vs. libopenal.so.1 issue.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
the Fiddler's picture

I've tested OpenTK on a few different distros, OpenSUSE 10.3 & 11, Fedora 4 & 7 and Archlinux with a little more favorable results. This was a little while ago, so it's possible that regressions have crept in since.

It seems that Fedora and OpenSUSE still ship with the old OpenAL SI (libopenal.so.0)? Debian has moved to OpenAL Soft (libopenal.so.1) which is much more stable.

What WMs are you using? I've only tested Gnome and KDE 3.5 here, so it's possible that OpenTK is broken on KDE 4, XFCE etc. Also, most of my tests were on virtual machines, which use Mesa indirect rendering. It's possible that this masks some problems.

Could it be that this is some strange interaction between the GameWindow and the example launcher? Does the same problems occur on standalone applications (e.g. the quickstart sample in the 0.9.1 release)?

kanato's picture

I was using Gnome on all distros. It's a good point about KDE 4, and something that we should maybe test more at some point. I always liked the gnome desktop more than KDE so I didn't bother with it. Also there was some issues with compiz so I turned it off for these tests but I wonder if there are issues that can be resolved on our end, or if they are compiz issues.

I did not get the same problems with the quickstart sample, except for the hard-lockups when dragging the window around in OpenSuSE that I think are just Intel driver problems. So I think it is likely that this is a strange interaction between GameWindow's message pump and mono's winforms message pump. Perhaps it should be a general recommendation to not mix GameWindow and WinForms, but I think that might eliminate the possibility of having a WinForms app with a full-screen mode.

I tried resolving the .so.1 vs. .so.0 by including two lines in the config file, one which points at .so.1 and one that points at .so.0, and that doesn't work. Any ideas how on earth is a developer supposed to resolve this sort of issue?

the Fiddler's picture

The hard lockup could only be caused by faulty drivers. I had my share of these when I had to suffer the awesome intel video drivers.

Compiz issues (like flashing) will be solved by DRI2, whenever that lands (probably next spring). Nvidia cards rip out the X11 internals so they don't suffer from this.

The lockup is probably a message pump problem, as you said. The WinForms examples are launched as dialogs and use the parent message pump, which is why they are not affected. Debian / Ubuntu tend to patch Mono for specific issues, which could explain why this doesn't happen there. Which version of Mono are you using?

This is probably easy to solve, either by launching the GameWindow on a different thread, or by destroying / recreating the launcher window. The Application class has some methods to register / unregister pumps that could help, too. I'll try to find a cure, but I'll have to reproduce it first.

About WinForms + fullscreen, why not just create a borderless maximized form?

I can think of two solutions:

  1. Require libopenal.so.1 and push the other distros to adapt OpenAL Soft. OpenAL SI doesn't work anyway, so that's not too far-fetched.
  2. Detect which version is installed and write a custom dll.config file to "~/.mono/assemblies/opentk" (hope I remember the path correctly).

Btw, does Fedora / OpenSUSE contain a vanilla libenal.so symlink?

Edit: I created a brand-new ArchLinux partition and I can confirm the "launcher-always-visible" problem (Mono 2.0.1). I didn't observe any of the other issues after a quick test. I have a feeling that these issues are linked somehow (the launcher eating up keyboard events), but I'll have to test more thoroughly.

kanato's picture

I've been meaning to get back to this and answer some of your questions:

I've been using Mono 2.0.1 as well.

The downside of a borderless maximized form is it won't cover the desktop toolbars (eg. the taskbar in windows, the panels in gnome, etc.) But if all else fails in making WinForms work with GameWindow it would probably be an acceptable solution.

Fedora and OpenSuse don't contain a vanilla libopenal.so symlink. They have libopenal.so.0 as a symlink to the binary file libopenal.so.0.0.0. I am downloading OpenSuse 11.1 which I will test out next week. I suspect you are right that the two issues are linked, but what is confusing to me is that the whole system is affected when the input stops responding, no mouse clicks in other windows work.

The OpenAL solution #2 wouldn't be too hard to implement, in just a shell script with sed. But, if OpenAL SI doesn't really work anyway, then there is no point in supporting it. Is there a reason the various distros include it? Fedora doesn't have OpenAL soft in its repositories, so maybe OpenAL just isn't used that much by software in the repositories? Another option, what about including binaries for OpenAL Soft with distributions? One could indicate in the config file a binary for x86 and one for x86_64 and just keep them in the same directory.

the Fiddler's picture

[WinForms & GameWindow]
I suspect the issue will be fixed by a simple call to Application.DoEvents() right after the Form is hidden, but I haven't got around to testing this theory yet.

I thought that a borderless, maximized and top-level window would cover the panels, but I'm not so sure now that you mention it.

Not even in the repos? Just perfect.

Several games use OpenAL, most of which work remarkably better with OpenAL Soft, as the Debian gaming team found out. Debian / Ubuntu simply patched the rest and left OpenAL SI in the repositories in case someone wanted to downgrade, but only after a lot of bug reports. I just searched and Fedora / openSUSE don't have *any* bug reports at all, which explains why they still use the old implementation.

OpenAL SI "works" for simple playback, but dies as soon as you try anything fancy: forget about getting a list of devices or using it on x86_64.

I hoped to avoid shipping unmanaged binaries, but it may be the only solution until the distros catch up. The question here is which compiler to use. AFAIK, new GCC versions don't work with old libc runtimes, but does the converse hold? (e.g. if you compile with GCC 4.0 can you run with the 4.3 libc?)

We should also report these issues to the relevant bug trackers (I'll handle openSUSE, do you have a user id for fedora?)

the Fiddler's picture

[Example Launcher]
Indeed, adding a call to Application.DoEvents() ensures that the launcher window gets hidden. Everything now seems to work fine on ArchLinux. I'll check openSUSE next.

kanato's picture

I reformatted my laptop harddisk (where I was doing all the testing under Linux) to put windows vista back on it so I could update the bios. I have yet to put OpenSuse and Fedora back on, but I will do it soon and test this some more.