annotate src/video/Xext/README @ 5082:de59e0218aa2

Fixed bug #1011 Daniel Ellis 2010-06-25 15:20:31 PDT SDL based applications sometimes display the wrong application name in the Sound Preferences dialog when using pulseaudio. I can see from the code that the SDL pulse module is initiating a new pulse audio context and passing an application name using the function get_progname(). The get_progname() function returns the name of the current process. However, the process name is often not a suitable name to use. For example, the OpenShot video editor is a python application, and so "python" is displayed in the Sound Preferences window (see Bug #596504), when it should be displaying "OpenShot". PulseAudio allows applications to specify the application name, either at the time the context is created (as SDL does currently), or by special environment variables (see http://www.pulseaudio.org/wiki/ApplicationProperties). If no name is specified, then pulseaudio will determine the name based on the process. If you specify the application name when initiating the pulseaudio context, then that will override any application name specified using an environment variable. As libsdl is a library, I believe the solution is for libsdl to not specify any application name when initiating a pulseaudio context, which will enable applications to specify the application name using environment variables. In the case that the applications do not specify anything, pulseaudio will fall back to using the process name anyway. The attached patch removes the get_progname() function and passes NULL as the application name when creating the pulseaudio context, which fixes the issue.
author Sam Lantinga <slouken@libsdl.org>
date Sun, 23 Jan 2011 21:55:04 -0800
parents b87d8d4c205d
children
rev   line source
292
eadc0746dfaf Added SDL_LockRect() and SDL_UnlockRect()
Sam Lantinga <slouken@libsdl.org>
parents:
diff changeset
1
eadc0746dfaf Added SDL_LockRect() and SDL_UnlockRect()
Sam Lantinga <slouken@libsdl.org>
parents:
diff changeset
2 The reason these libraries are built outside of the standard XFree86
eadc0746dfaf Added SDL_LockRect() and SDL_UnlockRect()
Sam Lantinga <slouken@libsdl.org>
parents:
diff changeset
3 tree is so that they can be linked as shared object code directly into
eadc0746dfaf Added SDL_LockRect() and SDL_UnlockRect()
Sam Lantinga <slouken@libsdl.org>
parents:
diff changeset
4 SDL without causing any symbol collisions with code in the application.
eadc0746dfaf Added SDL_LockRect() and SDL_UnlockRect()
Sam Lantinga <slouken@libsdl.org>
parents:
diff changeset
5
eadc0746dfaf Added SDL_LockRect() and SDL_UnlockRect()
Sam Lantinga <slouken@libsdl.org>
parents:
diff changeset
6 You can't link static library code into shared libraries on non-x86
eadc0746dfaf Added SDL_LockRect() and SDL_UnlockRect()
Sam Lantinga <slouken@libsdl.org>
parents:
diff changeset
7 Linux platforms. Since these libraries haven't become standard yet,
eadc0746dfaf Added SDL_LockRect() and SDL_UnlockRect()
Sam Lantinga <slouken@libsdl.org>
parents:
diff changeset
8 we'll just include them directly.
eadc0746dfaf Added SDL_LockRect() and SDL_UnlockRect()
Sam Lantinga <slouken@libsdl.org>
parents:
diff changeset
9
690
b87d8d4c205d Fixed use of SDL with XInitThreads()
Sam Lantinga <slouken@libsdl.org>
parents: 292
diff changeset
10 These sources are synchronized with XFree86 4.2.1