Keyboard presses not registered properly in preset saving menu on REAPER/Ardour VST/VST3/LV2 in Linux

[mortfell]

Describe the bug
Tested in REAPER, RENOISE and Ardour.
When you "store" a preset in Surge in REAPER on VST on Linux.
You get the normal menu, but when text is highlighted, (it's highlighted red below, not sure if that is the normal colour) the keyboard entry does not pass to the plugin. If you kinda click on just the right place in the text box the text will become un-highlighted and you can type or delete or move around with arrow keys.

If you tab to the next entry, or click on another text entry it will be highlighted red again and you have to click around the text box to try and find a sweet spot. So it's very hard to save a preset.

This issue happens in REAPER and Ardour.
but NOT in Carla or Renoise

SYSTEM INFO
The latest nightly of Surge, first version of Surge to include LV2
I'm on the latest lubuntu 19.04 a lightweight Ubuntu distro.
UNAME printout:
5.0.0-13-generic #14-Ubuntu SMP Mon Apr 15 14:59:14 UTC 2019 x86_64 GNU/Linux
Latest stable Ardour, REAPER, RENOISE and Carla

If if can provide any more specific info am happy to do so!

[baconpaul]

There’s a reaper “send keyboard to plugin” option. This may be related to #984

[mortfell]

Ahh yes that issue.
This seems different, but it might be related. Input is not making it to the host at all, it’s just getting eaten up.

the way plugins work with the keyboard/mouse seems really different functionally in Linux than windows and or Mac OS. I should try and find some more Linux vsts to test

[jpcima]

I didn't reproduce the exact error, I had something else possibly related.
At first, the characters did type in all of the boxes without issue; at some undetermined point, typing any character in the boxes has started inputting box characters instead.
Reaper Linux VST3

[mortfell]

interesting....
I'll try testing tonight again with some other VST's and also check the REAPER forum to see whats going on there. No sense spending too much time on bugs if they are just REAPERs fault.

I have a copy of "Redux" the VST sampler made by the Renoise team... that has a linux VST. I know u-he has linux versions of everything. Anything else anybody know about???

[jpcima]

Other: when I switch between different keyboard layouts while the editor is run, I then meet a problem like described, where I can't edit any longer.
Do you think it can related to key layouts, @mortfell?

[mortfell]

Just tested this again. And updated the name of this issue.
This is an odd one.

So I'm using Ardour 5.12 from the repository now (not the demo)...and for some reason it has different behavior.
Surge LV2 and VST now act more or less the same in Ardour as Surge VST on REAPER (with regards to the keyboard entry) if your press in the right place (somewhere between the letters and the top of the text entry box) it will work, otherwise it just stays highlighted red and key presses pass through to the host.

I've tried changing keyboard layouts, and it doesn't seem to effect anything....
Anything else I could try to narrow this issue down to something more specific?

To reiterate this is effecting LV2 VST and VST3 on Ardour and REAPER on my system.
but not Renoise VST2 and not Carla LV2
Could it be something to do with that menu and windows handling?
@jpcima you say you aren't able to reproduce this issue?? hmmm

[mortfell]

oh ok, narrowed this down a bit
Lubuntu uses lxqt a qt lxde thing.

I installed fluxbox and tried to run ardour.
No issues with either vst or LV2 now in fluxbox.

So is the issue an incompatibility with the window manager... or something else. I'll see if I can narrow it down more.

[mortfell]

so yeah, lxqt still uses openbox as window manager just like regular lxde.
tried running just openbox and the issues come back.

Can anyone reproduce these preset saving menu issues using openbox, or a desktop environment like LXDE that relies on openbox?

[baconpaul]

I don't have an environment to do that; sorry. But great debugging!

[jpcima]

I am going to try myself, in any case I found these which may give information.
It can dump X Keyboard config, so it could reveal some differences of keyboard settings between a pair of WM setups.

From the page http://www.vinc17.net/unix/xkb.en.html

• To output the current settings: setxkbmap -print
• To dump the current XKB keyboard description to a file xkb.dump: xkbcomp $DISPLAY xkb.dump

[jpcima]

It's reproducible, and it seems really like a focus issue, possibly specific to this window manager.

Looking at the situation from the OP screenshot of Reaper, this experiment can be made:

1. at the right side of the tick box from Reaper "VSTi: Surge", is an editable text field.
2. click on this to set the focus.
3. next, go in the "store patch" popup from Surge.
4. click on the box to get it red, then type in it.
5. instead, the typed text goes into Reaper's field that we have selected in the step 1.

As noted also previously, it's possible somehow get focus into surge by insisting on the text field.
You have to make a second click into it, while mouse cursor has to be set at an adequate position.

[baconpaul]

This is way beyond my depth at this point. Do you think surge is mis-managing focus or do you think the window manager is?

I wonder if there’s a vstgui ‘gain focus’ api we could call. Honestly I would just have to grep for that.

I also wonder if, in the broken configuration, the +/- keys (to zoom and in zoom) register or not.

[jpcima]

I also wonder if, in the broken configuration, the +/- keys (to zoom and in zoom) register or not.

The - key is handled in both configurations.
It will pop up the dialog saying it can't make zoom any smaller.

Regardless of configuration, the + key does nothing for me.
No dialog popup, no size change. But it's probably more related to the program logic, not the issue at hand.

[jpcima]

I investigated the problem that when clicking the text field, the mouse is not set in correct position;
it has an offset to the good position.

When you click a point, the actual location which is taken by the cursor text edit is offset to the right, by approximately the half widget width.

The code following is found under vstgui as this location.

		parent->translateToLocal (where);
		//this->translateToLocal (where);

When I take the relative point of click from this instead of parent, as written in the comment, it seems to resolve the cursor offset issue.

About this, it's an instance of the generic text edit, aka STBTextEditView, which is set into CTextEdit during the editing. (at other times, CTextEdit acts only as simple CTextLabel)

About parent, it's a view whose typeid is VSTGUI::CViewContainer.
It's maybe the problem that the STBTextEditView's parent is this container, instead of being the CTextEdit ? maybe, it can explain why the relative coordinate gets an incorrect offset ?

What do you think about it, @baconpaul?

[jpcima]

It was still offset when I forced the text edit to left aligned though.... argh
EDIT no it's not offset, it just doesn't pass the hitTest condition. 🤔

[jpcima]

This patch appears to make text cursor follow the mouse click correctly. (LV2, at least)
I don't know how correct it is. I'll restart to openbox WM and check if this changes anything.
https://gist.github.com/jpcima/d0cf7ae1d8f203e6b3e2e1e1ac3906df

[jpcima]

It's not perfect on Openbox however it is MUCH better.

1. click on text field, it goes red colored
2. • if it's openbox, text field is not on focus, the keys go through to REAPER
   • if not openbox, typing text enters in the field, replacing red-colored selection
3. click on text field a second time. it turns to a vertical bar cursor into the text.
4. now, it's focused and I can type in the text. (wouldn't work in Openbox before)

[baconpaul]

Oh I wonder if this is another example of translate to local being backwards. A lot of the fixes I had to apply to VSTGUI were about transformations being done the wrong way.

It would make sense though that this would happen in reaper where the parent isn't positioned at (0,0) (unlike every other DAW).

I need to think about this diff some though - and also think about the risk of adding it this late in the 1.6.2 process. I have a busy couple of non-surge days so I won't get a great chance to test it or look until the weekend, I'm sorry!

[baconpaul]

Oh the good news about this patch, though, is just like the generic menu, this code path is linux only so our testing aperture goes way down (just from looking more this morning).

[baconpaul]

@jpcima I also tested your diff and agree with it. Merging it this evening and will then close this issue. Thanks for the fix.