>1 Programs on QtWayland causes QtVirtualKeyboard to not work

Cannot upload a tarball due to some kind of token problem, so created a git repo. Links to the git repo is in the text below.

Setup Description:

QtWayland Compositor running the ivi-compositor example.

Patch applied to get Virtualkeyboard support. Patch is here: https://github.com/cbs101/qtvirtualkeyboard_problem/blob/master/qtwayland_ivi_compositor_example.patch

Virtualkeyboard is used in application mode in the QtWayland Compositor, i.e. when starting the compositor: export QT_IM_MODULE=qtvirtualkeyboard.

2 small demo applications are created. 

app_digits:

https://github.com/cbs101/qtvirtualkeyboard_problem/tree/master/app_digits

app_upper:

https://github.com/cbs101/qtvirtualkeyboard_problem/tree/master/app_upper

Both demo application are really just a single textfield in a QML file.

app_digits and app_upper does NOT have any ties to virtualkeyboard in their source code. The is displayed using Wayland, and then the virtualkeyboard in wayland is given to these applications.

In app_digits, the textfield is limited by:

inputMethodHints: Qt.ImhSensitiveData | Qt.ImhDigitsOnly

In app_upper, the textfield is limited by:

inputMethodHints: Qt.ImhUppercaseOnly

Problem is seen on a iMX6 board where the QtWayland is running ontop of EGLFS, and i'm using the vivante drivers.

Expected Result:

The QtWayland ivi compositor is (vertical) split screen with 2 applications.

The compositor is started. Just after the compositor is running app_digits and app_upper is started shortly after each other. One of them with "export QT_IVI_SURFACE_ID=1337" to ensure one of them gets the leftArea in the ivi-compositor.

I expect when pressing the textfield in app_digits that a virtual keyboard pops up and shows only numeric digits.

I expect when pressing the textfield in app_upper that a virtual keyboard pops up and shows only upper case letters.

Seen Result:

Multiple cases happen. It seems fairly random what happens. But always one of the 5 cases below. Good case happen in ~10 % of attemps. Hence it becomes wrong almost every time.

Case 1 (the good case):

It does happen as expected.

Case 2 (bad):

When pressing the textfield app_digits, the virtual keyboard is shown with digits (expected). Then when pressing the textfield in app_upper, the virtual keyboard is shown with digits (NOT expected).

Case 3 (bad):

When pressing the textfield in app_upper, the virtual keyboard is shown with upper case letters (expected).

Then when pressing the textfield app_digits, the virtual keyboard is shown with upper case letters (NOT expected).

Case 4 (bad):

When pressing the textfield in app_upper, the virtual keyboard is shown with upper case letters (expected).

Then when pressing the textfield app_digits, the virtual keyboard is not shown (NOT expected)

Case 5 (bad):

When pressing the textfield app_digits, the virtual keyboard is shown with digits (expected).

Then when pressing the textfield app_upper, the virtual keyboard is not shown (NOT expected)

Note: If I insert a delay in between starting the 2 applications, the case case seem to go upwards of 95 %. Parallelism ? Are there limitations to starting more than 1 application at the same time when the applications themselves do not got the virtualkeyboard but they instead get it from QtWayland which has virtualkeyboard in application mode ?

Steps needed to Replicate the Problem:

Start the patched ivi compositor

Wait untill the Wayland compositor is running

Start the 2 applications: app_digits and app_upper.