Just tested with 89.0.4387.0 and it works well.

Does your system have necessary protocols supported? Can you upgrade to the newest version?

hi msisov
Do you test on 86.0.4240.198 before?
And Do you commit 89.0.4387.0 already?
I just see 87

hi msisov
Do you test on 86.0.4240.198 before?

yes, it was. Can you run chromium with WAYLAND_DEBUG=1 chrome --your_args and paste the output here?

And Do you commit 89.0.4387.0 already?
I just see 87

M89 is an unstable branch. I only push stable releases of Chromium here.

chromium 80 log link
--args
--use-gl=egl --kiosk --no-first-run --disable-infobars --noerrdialogs --enable-wayland-ime --enable features=OverlayScrollbar --disable-restore-session-state --high-dpi-support=1 --force-device-scale-factor=1 --force-dark-mode --ozone-platform=wayland --user-agent="Mozilla/5.0 (X11; CrOS armv7l 13421.99.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.198 Safari/537.36" --no-sandbox --app=https://www.netflix.com/login --window-size=1920,1080 --enable-logging=stderr --log-level=0

chromium 86 loglink
--args
the same as chromium80 as above, just add more one --in-process-gpu, without this argument, chromium 86 cannot up execute succesfully...

From the logs, I can see that ZWPTextInputWrapperV1 is created and it does get some calls (like set_cursor_rectangle, etc).
However, the main difference between M80 and M86 in your case is that zwp_text_input_v1_activate and zwp_text_input_v1_show_input_panel are not called.

These calls happen here WaylandInputMethodContext whenever a window gets focus.

Looks like it doesn't happen in your case for some reason and you should investigate InputMethodAuraLinux

Hi msisov
Thanks for reply.
I think i had a problem here GetCurrentKeyboardFocusedWindow

I do not know why cannot set has_keyboard_focus in our codebase.
However, I just return first window as workaround first....

@cchsu23 actually, there can be systems without keyboard at all. So, it seems like a bug then. I think it should get current active window instead or better Chrome passes desired accelerated widget.

As a workaround, I'd suggest to return active window now -

auto windows =
      connection_->wayland_window_manager()->GetAllWindows();
WaylandWindow* target_window = nullptr;
for (auto* window : windows) {
  if (window->IsActive()) {
      target_window = window;
      break;
    }
}

@cchsu23 actually, there can be systems without keyboard at all. So, it seems like a bug then. I think it should get current active window instead or better Chrome passes desired accelerated widget.

As a workaround, I'd suggest to return active window now -

auto windows =
      connection_->wayland_window_manager()->GetAllWindows();
WaylandWindow* target_window = nullptr;
for (auto* window : windows) {
  if (window->IsActive()) {
      target_window = window;
      break;
    }
}

I already tried window->IsActive(), it seems not working...

How can I get main windows?

Actually, I was contacted some time ago about slightly a different issue, but the root cause was the same.

I bet you don't have a keyboard attached. Is that correct? And you use a touch screen, don't you? That's the reason why even IsActive doesn't work for you. There is actually a bug in weston that activates windows only if they have a kbd focus. See https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/568#note_828078 . While it's a bug in weston, I admit Chromium also doesn't behave 100% correct.

I believe the WaylandInputMethodContext::Focus() should probably get a widget of a window that Chromium's ime implementation want to set focus to. I'll make a bug for that in crbug.

Hi Msisov,
yes, I don't have keyboard , I use touch screen.
But, I remember that chromium v80 and v83 does'nt have this problem.... just provide a clue to you.

And, I will try WaylandInputMethodContext::Focus() to see if get the the window.
In fact, I do not know what is widget in chromium.....can you share the info. about this?

But, I remember that chromium v80 and v83 does'nt have this problem.... just provide a clue to you.

That is strange! This part of code below has always been there since WaylandInputMethodContext was written.

void WaylandInputMethodContext::Focus() {
  WaylandWindow* window = connection_->GetCurrentKeyboardFocusedWindow();
  if (!text_input_ || !window)
    return;

  text_input_->Activate(window);
  text_input_->ShowInputPanel();
}

In fact, I do not know what is widget in chromium.....can you share the info. about this?

gfx::AcceleratedWidget is just internal representation of a native window in Chromium. You can think about it as an id of a native window.

which can works with 80.0.3987.132 and 83.0.4103.116

Thanks, That's why I open this ticket. see my first comment on the top...

Hi Msisov
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/568#note_828078
desktop-shell and kiosk-shell seems has workaround

But not for me, I use ivi-shell based...

Hi, I would like to bring this thread up again, adding some info on the topic. I'm working on two systems, one based on x86 and the other one on i.MX8MM cpu.

On the x86 machine, all versions of chrome (from 85 to 91) do work great without any issue on the virtual keyboard.

On the i.MX8MM instead, starting from chromium > 83 the keyboard just doesn't show up (without a usb keyboard connected). Clicking on the URL bar doesn't have any effect at all, just like clicking outside the input text.

With this patch: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/568/diffs#note_828078
I can make the cursor show up when clicking on the URL bar, but the keyboard doesn't show up on the MX8MM board.

On my side, I'm experimenting right now with chromium 88.0.4324.150 on both x86 and imx8mm. The only difference is the yocto branch. On the x86 machine, I'm still on Zeus branch while imx8mm is on development on Gatesgarth branch.

I have also tested weston (instead of weston-imx) and also wayland-protocols (instead of weston-protocols-imx) but the result is the same.

@cchsu23 on what system do you have this keyboard issue? Maybe this is the reason why @msisov was not seeing the issue on his side, it may depend on the CPU we are using.

I tested a small change on the Focus function:

void WaylandInputMethodContext::Focus() {
  WaylandWindow* window = connection_->GetCurrentKeyboardFocusedWindow();
  if (!text_input_ || !window)
    return;

  text_input_->Activate(window);
  text_input_->ShowInputPanel();
}

Instead of using GetCurrentKeyboardFocusedWindow() i tried to use GetCurrentFocusedWindow() which made the keyboard show up when clicking on the URL bar. This result was nice, but I don't know if this is correct or not.

The weird thing is, clicking on other input texts doesn't show up the keyboard, but if I click on the input text, then on the URL bar, and then back to the input text, this time the keyboard show up. This behaviour is reproducible on all input texts, if I jump on the URL bar, and then on the input text, it works.

Does anybody have any idea what is happening?

I am using mt2712 32-bit userland.

This issue is fixed when I use kiosk-shell instead of use ivi-shell.

I also get some weird behavior on --enable-wayland-ime, especially when I plug no keyboard.

• When no keyboard & no pointer device present, chromium crashes on start up
• The chromium window never be activated when no real keyboard presents
  • As a result a user cannot input to Omnibox by weston-keyboard
  • I know that it's mainly caused by weston's problem as mentioned above, but I couldn't be satisfied with that because weston-editor with weston-keyboard can input text on same situation, and chromium also can input text into content area.
• Cannot send Enter or Tab or other keysyms from weston-keyboard when no real keyboard presents
• On Omnibox, preedit text from weston-keyboard isn't decorated while it's decorated on content area by default.
  • Although it can be solved by changing the style at weston-keyboard (right bottom button), the difference of the default behavior confuse users

I applied some monkey patches to fix these issues:
https://github.com/clear-code/meta-browser/blob/2468c6d28781a7fe9f3951b454ec5da376abb7f9/meta-chromium/recipes-browser/chromium/chromium-gn.inc#L24-L29
Because I'm not familiar with Chromium, I don't think they are right patches.
So I don't feed back these patches to upstream yet.
But it might help users who has the same problem as me.

I just found out what the difference was between x86 image (on which the virtual keyboard was working) and the imx8mm on which the virtual keyboard was never activated.
On x86, we had a "Power Button" gpio which was tagged as "Keyboard" by udev, and so it was activating the input text, just like having a USB keyboard attached.

I added an unused gpio on the device tree compatible with "gpio-keys" and also activated on the kernel the gpio keys support. Now the virtual keyboard shows up as expected. I know this is just a work around for this weston/chromium bug, but it is the easiest way I found so far to overcome this issue.