View Issue Details

IDProjectCategoryView StatusLast Update
0007163ardourbugspublic2020-09-28 16:08
Reporterventosus Assigned To 
PriorityhighSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version5.5 
Summary0007163: KeyRelease events destined to embedded LV2 X11 plugins are eaten by Ardour (and suil)
DescriptionKeyRelease events destined to embedded LV2 X11 plugins are eaten by Ardour. Toggling the fancy button on the top right makes no difference (apart from letting some additional KeyPress events through, e.g. space).

This makes plugin UIs needing to be notified about KeyRelease of special keys (e.g. Shift, Control, ....) totally unusable. E.g. imagine a rudimentary text editor which enters selection mode after writing a capital letter and can never exit selection mode again :(

There are actually at least two bugs involved here. One I've already found and reported in suil (http://dev.drobilla.net/ticket/1149). My patch for suil fixes the issue in jalv.gtk* (which is having the the very same problem for X11 UIs embedded in GTK).

In Ardour the problem persits, though, it therefore seems to drop KeyRelease events at an earlier point (even before vanilla suil will drop it itself)
Steps To Reproduce* Apply referenced patch to suil

* Listen for KeyPress and KeyRelease events in an embeddable LV2 X11 plugin UI and you'll see that KeyPress will reach the UI but not a single KeyRelease will ever reach the plugin UI.
TagsNo tags attached.

Activities

ventosus

2016-12-19 20:39

reporter  

0001_fix_missing_key_release_x11_lv2_ui.patch (1,257 bytes)   
diff --git a/gtk2_ardour/ardour_ui.cc b/gtk2_ardour/ardour_ui.cc
index 783510977..d5f8cfaf5 100644
--- a/gtk2_ardour/ardour_ui.cc
+++ b/gtk2_ardour/ardour_ui.cc
@@ -5536,15 +5536,14 @@ ARDOUR_UI::key_event_handler (GdkEventKey* ev, Gtk::Window* event_window)
 	Gtkmm2ext::Bindings* bindings = 0;
 	Gtk::Window* window = 0;
 
-	/* until we get ardour bindings working, we are not handling key
-	 * releases yet.
-	 */
-
-	if (ev->type != GDK_KEY_PRESS) {
-		return false;
-	}
-
 	if (event_window == &_main_window) {
+		/* until we get ardour bindings working, we are not handling key
+		 * releases yet.
+		 */
+
+		if (ev->type != GDK_KEY_PRESS) {
+			return false;
+		}
 
 		window = event_window;
 
diff --git a/gtk2_ardour/plugin_ui.cc b/gtk2_ardour/plugin_ui.cc
index 15600772e..d243ea66c 100644
--- a/gtk2_ardour/plugin_ui.cc
+++ b/gtk2_ardour/plugin_ui.cc
@@ -425,17 +425,7 @@ PluginUIWindow::on_key_press_event (GdkEventKey* event)
 bool
 PluginUIWindow::on_key_release_event (GdkEventKey *event)
 {
-	if (_keyboard_focused) {
-		if (_pluginui) {
-			if (_pluginui->non_gtk_gui()) {
-				_pluginui->forward_key_event (event);
-			}
-			return true;
-		}
-		return false;
-	} else {
-		return true;
-	}
+	return on_key_press_event(event);
 }
 
 void

ventosus

2016-12-19 20:43

reporter   ~0019175

I've tried to find the spot where KeyRelease events are gone missing in Ardour. The attached patch fixes the issue for me. It may well break other things as I don't know the code.

At least it should give a potential developer a heads up where to look...

My moony plugin [1] can be used as test case. It embeds a simple code editor which is useless without proper KeyRelease events for e.g. Shift and Control.

Write a single capital letter and the editor will be stuck in selection mode forever (it supports Shift + Arrow keys for keyboard-only selections).

[1] https://dl.open-music-kontrollers.ch/moony.lv2/unstable/

ventosus

2020-09-28 16:08

reporter   ~0025072

seems fixed, sorry, totally forgot about it.

Issue History

Date Modified Username Field Change
2016-12-09 07:54 ventosus New Issue
2016-12-19 20:39 ventosus File Added: 0001_fix_missing_key_release_x11_lv2_ui.patch
2016-12-19 20:43 ventosus Note Added: 0019175
2020-09-28 16:08 ventosus Status new => closed
2020-09-28 16:08 ventosus Resolution open => fixed
2020-09-28 16:08 ventosus Note Added: 0025072