Workaround: Author: Otavio Salvador <otavio@ossystems.com.br> Date: Tue Jul 15 17:05:03 2014 -0300 alsa-tools: Disable use of GTK+ when not using X11 The GTK+3 does not provide support for DirectFB backend so we cannot enable GTK+ features of alsa-tools in this case; GTK+2 does not provide support for Wayland. This patch changes GTK+ support to be enabled only when X11 support is enabled. Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> The correct fix is to add support to --enable-gtk2-apps and --enable-gtk3-apps so we can control it in PACKAGECONFIG depending on the DISTRO_FEATURES.
We want wayland to be a first class citizen so I've bumped the priority for this. Respecting the x11 feature to enable/disable GTK+ is a first step.
Hi Otavio, Can you please submit the aforementioned patch? Thanks, Cristian
I did the workaround and suggested a real fix. I didn't cook a patch for it (otherwise I would have sent and closed this).
The workaround of only enabling gtk+2 on x11 is reasonable as the more correct fix is more complicated. gtk+3 for Wayland, gtk+2 for x11 (as of now), but what for x11 and wayland? Poky builds in that combination, and the only way of building there is with gtk+3, which then pulls gtk+3 into a gtk+2 image. So, I propose: 1) packageconfigs for gtk2 and gtk3 tools 2) enable gtk2 on x11 Commit these, and then: 3) wait for sato to migration to gtk3 4) enable gtk3 on x11/wayland.
Alsa-tools has 4 executables that depend on gtk+. Three of them have a hard dependency on gtk2, and one has a hard dependency on gtk3. I'll redo the recipe so that it enables the first three binaries if x11 is available and adds a gtk2 dependency, and also enables the fourth binary if x11 or wayland is available (in this case, also gtk3 dependency would be added). Is that ok? Did I understand the issue correctly?
Actually, this is more complicated. The top-level Makefile unconditionally includes all the gtk-based tools. And we currently apply a patch that removes all of the tools, if x11 is not available. So to have a higher granularity, I would have to introduce two patches instead: 1) if neither x11 nor wayland is available, we remove all the tools 2) if x11 is not available, but wayland is available, we remove the gtk2 tools only. 3) if both x11 and wayland are available, or only x11 is available, we don't need to remove anything. This looks rather convoluted and I think bitbake does not support specifying such conditions. Can it be done? An alternative is to rewrite alsa-tools' build configuration so that you can tell it what to build (gtk2 stuff, gtk3 stuff or both). Which will take more time. Another alternative is to do nothing, and wait until they port all of their tools to gtk3. How important are those tools? They are: echomixer envy24control hdajackretask (this is the gtk3 one) rmedigicontrol
Not important enough to warrant spending much more time on! Let's reschedule this for 2.1 and lean on upstream to migrate the lot to GTK+ 3. Rebasing "[OE-core] [PATCH v2] alsa-tools: Disable use of GTK+ when not using X11" (August 2014) seems like the best solution right now.
But that patch is already in master :) Let's either rewrite alsa-tools build configs later, or maybe they migrate to gtk3 in the meantime. I agree, not worth spending time on this now.
This is probably not medium+ anymore: only building alsatools with X11 is a reasonable workaround.
Between 1.0.29 and 1.1.0 nothing has changed upstream. Is everyone ok with RESOLVED WONTFIX?
I'm ok with wontfix. There was an earlier question that went unanswered: "How important are those tools?" echomixer, envy24control and rmedigicontrol are end-user applications for configuring specific high-end PCI sound cards that are not fully covered by the generic alsa tools. That is, not important at all in the context of a base layer for embedded systems. hdajackretask, to my knowledge (I haven't used it myself) is a tool for reconfiguring the Intel HDA driver to handle analog audio jacks differently. The driver covers a vast range of hardware, and sometimes the driver gets the jack configuration wrong, making the jack state reporting non-functional. hdajackretask can be used to figure out what the exact problem is, and based on that information, the driver can be fixed. So, the tool can at least in theory be useful in embedded context, but it's certainly not widely used.
Wontfix it is then. If anyone cares, file an upstream enhancement request to port the tools to gtk3.
Verified per above comments; won't fix.