I think you misunderstood both the commit message and the note in the README, so perhaps more notes should be added. To summarize: * xwayland module sets DISPLAY after pulse init, so at no point is the variable actively unset * nowhere does it say that the module needs to be loaded, only built
The main issue is that pulseaudio forces checks for an X11 environment before anything else--which is backwards--and this ensures deadlocking in the case where a process internally uses pulseaudio and is also running the xserver. Relatedly, there seems to be no way to use API to disable this behavior, it can only be compiled out by disabling X11 support entirely. A lesser issue is that ecore-audio creates its global pulseaudio connection only upon creating the first audio object. In enlightenment, this (currently) only occurs when typing for the first time in an internal window's entry widget since this triggers the delightful key press sounds. Without pre-initialization of ecore-audio's global connection, this deadlocks the server if no previous X11 client has been launched. The least significant issue is that ecore-audio provides no method for determining what features it provides, meaning that I can only guess based on whatever support is enabled by the user during build time. And even this is not guaranteed to be correct. The best possible solution, for me, would be to completely disable ecore-audio in internal windows if the xwayland module loads, at least until pulseaudio fixes its internals to stop deadlocking. This seemed like it would be unpopular for some, however, so I went with the solution which was most likely to work for the majority of users. On Thu, Oct 29, 2015 at 12:25 PM Tom Hacohen <[email protected]> wrote: > On 29/10/15 16:13, Mike Blumenkrantz wrote: > > I am not sure what you mean, but DISPLAY is not set when it is > initialized > > in this commit. > > > > Then I misunderstood your commit message. I thought the problem was that > Pulse checks for "DISPLAY", and if it sees it's set it does all of what > you've described, thus causing the lock. This made me suggest you unset > DISPLAY before initialising pulse, so it thinks it's not in an X11 > environment. > > My points are still valid though, we need to find a better solution, as > the recommendations in the README are very unlikely to reach end users. > Heck, it would possibly even be better to check if the module is loaded > (or going to be?) and then act appropriately (like not initialise pulse > or whatever is needed). I don't know E as well as you do, but telling > users they need to load a module in a README and not forcing it, when if > they fail to follow they get a locked environment doesn't sound like the > best solution possible. > > -- > Tom. > > > On Thu, Oct 29, 2015 at 8:07 AM Tom Hacohen <[email protected]> wrote: > > > >> Wouldn't it just be cleaner to unset and the set back DISPLAY around > >> where you initialize pulse? The "TLDR" in the readme will probably never > >> find its way to the users who will just complain/swear (and rightfully > so). > >> > > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
