This is really annoying on my laptop - it has a touchscreen & a keyboard but the OSK still pops up.

I can confirm that the bug still exists in the following setup:
GNOME 3.16.0, Arch Linux, ASUS N550JV

The general steps to reproduce it are as follows:
1. Use a touchscreen in any way at all. At this point, the mouse pointer disappears immediately (as expected).
2. Focus a supported* input field, without using the mouse/touchpad.

Result: Regardless of whether you actually have a physical keyboard or whether you had used it just a few seconds before, an on-screen keyboard automatically pops up, obstructing a substantial portion of the visible screen area.

* The reason "supported" is emphasized is because the issue can't be reproduced in some input fields, such as in LibreOffice or Chromium, because of a different bug. (see #744551)

Also, #739293 is probably a related bug. (possibly a duplicate)

As it stands, the related bugs haven't gotten enough attention and no proposals have been submitted for them in the entire 3.15 release-cycle. I think it would be best to disable the feature by default at this point, at least until a clear, universal and well-tested design is decided upon.

This has been killing me for awhile.  If I shake a real mouse or use my touchpad, the on-screen keyboard will go away.  Basically, instead of the on-screen keyboard's visibility being dependent on the use of a physical keyboard, it's dependent on the use of the mouse.

This almost seems logical since the touchscreen takes the place of the mouse, but in practice, the on-screen keyboard substitutes for the physical keyboard, which I can't remove from my system.  It should either recognize that the keyboard is plugged in and not show up at all, or should be optional such that pressing a physical key makes it go away.

I'm on 3.22.1 and nothing has happened.  Imagine if I had a touchscreen and no physical mouse at all, but a real keyboard.  Such a configuration should be completely usable, but on this case, you'd never get the stupid on-screen keyboard out of the way so I can see what I'm typing.  Further, unlike Android that will move the input field you are typing into further up the screen so you can see what you are typing, Gnome has no such feature.   You have to try and see through a keyboard that won't go away.   This is totally unacceptable! 

I realize that Gnome wants to be "user friendly" these days, but lets make turning off broken behavior a bit easier!

Just am FYI.  I went into Accessibility Settings and the pop-up keyboard was completely turned off.   It still pops up.  I turned it on, left the control panel, then turned it back off again.  This seemed to work for a minute, but the stupid thing is on my screen right now as a type this on a physical keyboard.  I also tried setting the keyboard to use to 'none','','disabled' in dconf-settings and that won't turn it off either.

How do we get rid of it?  Or am I supposed to tap the little "keyboard go-away" button every time it pops up?

(In reply to Evan Langlois from comment #4)
> How do we get rid of it?  Or am I supposed to tap the little "keyboard
> go-away" button every time it pops up?

You can see the logic that enables the on-screen-keyboard here: <https://github.com/GNOME/gnome-shell/blob/ddfdfaed785e9ef4291a2bd921009a79191ff760/js/ui/keyboard.js#L257>. Maybe an extension can modify it? In the mean-time I'm using this patch:

--- gnome-shell-3.22.2.orig/js/ui/keyboard.js
+++ gnome-shell-3.22.2/js/ui/keyboard.js
@@ -254,8 +254,7 @@ const Keyboard = new Lang.Class({
     },
 
     _sync: function () {
-        this._enableKeyboard = this._a11yApplicationsSettings.get_boolean(SHOW_KEYBOARD) ||
-                               this._lastDeviceIsTouchscreen();
+        this._enableKeyboard = this._a11yApplicationsSettings.get_boolean(SHOW_KEYBOARD);
         if (!this._enableKeyboard && !this._keyboard)
             return;
         if (this._enableKeyboard && this._keyboard &&

Thanks for the patch.  That is definitely the logic being used.  It should be detecting if a physical keyboard is attached, something like || !this._hasPhysicalKeyboard() if there is something like that available.  Is the API documented somewhere?

I'm surprised it's javascript.  That seems really pointless if you have to recompile gnome-shell to change it.  Nice dynamic javascript, but all benefits lost since its embedded into the binary.  Grr ... We just get the benefit of the memory usage and speed of javascript.

Created attachment 347667 [details] [review]
disable on screen keyboard when a real keyboard is present

Review of attachment 347667 [details] [review]:

::: js/ui/keyboard.js
@@ +253,3 @@
+        if (manager.list_devices().some(d => d.get_device_type() == Clutter.InputDeviceType.KEYBOARD_DEVICE)) {
+            return false;
+        }

This looks wrong. This function checks if the last device was a touch screen. With this change, this is no longer the case.

It'll also break things on Wayland where things like power button or volume buttons might show up as keyboards. The issue rather seems related to the 'last device' tracking.

(In reply to Jonas Ådahl from comment #8)
> This looks wrong. This function checks if the last device was a touch
> screen. With this change, this is no longer the case.

Note that I also renamed the function in order to indicate its new purpose.

> It'll also break things on Wayland where things like power button or volume
> buttons might show up as keyboards. The issue rather seems related to the
> 'last device' tracking.

This can be worked around by only looking for a real keyboard if not running under Wayland.

According to https://blog.martin-graesslin.com/blog/2016/05/virtual-keyboard-support-in-kwinwayland-5-7/ libinput can be used to figure out if a keyboard is a 'real' keyboard but it doesn't go into specifics.

Created attachment 347708 [details] [review]
disable on screen keyboard when a real keyboard is present

This additional test may not be necessary afterall. I gather from https://blogs.s-osg.org/when-is-a-keyboard-not-a-keyboard/ that the power buttons you're talking about are the ones such as my ACPI power switch, which already seems to be ignored.

$ cat mutter-test.js 
const Clutter = imports.gi.Clutter;
Clutter.init(null, 0);

const device_manager = Clutter.DeviceManager.get_default();
device_manager.list_devices().forEach(d => {
	print('Name:', d.get_device_name());
	print('Type', d.get_device_type());
	print();
});

$ gjs mutter-test.js
Name: Wayland Touch
Type 6

Name: Wayland Keyboard
Type 1

Name: Wayland Pointer
Type 0

Name: Wayland Touch Master Pointer
Type 0

Name: Core Keyboard
Type 1

Name: Core Pointer
Type 0

Review of attachment 347708 [details] [review]:

Just some observations on the patch, I'll leave the discussion about the viability (and desirability) of this approach to others.

But from comment #0:

> 1. Touch the touchscreen.
> 2. Press Super on the physical keyboard to bring up the overview.
> 3. Type any letter on the physical keyboard to focus the search box (a text entry field) and begin search.
>    Observe that the on-screen keyboard pops up, despite the physical keyboard clearly being usable, as it was just used to start the search.

I'd say that the issue is less that the OSK isn't disabled when a keyboard is present, but that _lastDeviceIsTouchscreen() doesn't quite work as advertised - in the quote, the last used device is a keyboard, and yet the OSK pops up.

::: js/ui/keyboard.js
@@ +253,3 @@
+        // Don't perform this test under Wayland, where power or volume
+        // controls are a type of keyboard.
+        if (!Meta.is_wayland_compositor()) {

Unless the issue doesn't happen on wayland, we shouldn't cop out like this (I'll add that we use a private clutter fork nowadays, so there are no API stability / backward compatibility issues if a fix requires changes in Clutter)

@@ +256,3 @@
+            if (manager.list_devices().some(d => d.get_device_type() == Clutter.InputDeviceType.KEYBOARD_DEVICE)) {
+                return false;
+            }

Style nit: No braces

@@ +264,3 @@
     _sync: function () {
         this._enableKeyboard = this._a11yApplicationsSettings.get_boolean(SHOW_KEYBOARD) ||
+                               this._lastDeviceIsTouchscreenAndNoKeyboardPresent();

This is stylistically awkward - it would read much cleaner to do something like:

  enableKeyboard = settings.get_boolean(SHOW_KEYBOARD) ||
                   (this._lastDeviceIsTouchscreen() && !this._hasPhysicalKeyboard());

I can confirm this annoying behavior on my Lenovo G400S Touch laptop.
The virtual kayboard appears on my screen when I drag Gnome terminal window using my touchscreen.
I'm running Gnome 3.24 on Arch.

*** Bug 780941 has been marked as a duplicate of this bug. ***

> I'd say that the issue is less that the OSK isn't disabled when a keyboard
> is present, but that _lastDeviceIsTouchscreen() doesn't quite work as
> advertised - in the quote, the last used device is a keyboard, and yet the
> OSK pops up.

But what is the use case where a physical keyboard IS present, and yet the user would like the OSK to appear due to the touchscreen being used, until a key on the physical keyboard is pressed (i.e. the last used device becomes a keyboard)?

I cannot personally see a use case for that, and would much rather have the OSK never appear at all when my device has a hardware keyboard attached or connected via USB or Bluetooth.

(In reply to Lorenzo J. Lucchini from comment #15)
> I cannot personally see a use case for that, and would much rather have the
> OSK never appear at all when my device has a hardware keyboard attached

See comment #8 - "hardware keyboard" unfortunately isn't necessarily what you'd expect, as on the driver-level it tends to mean "thing with at least one button". Plugging in a webcam with a physical record/pause button usually doesn't mean that the user wants to input text via morse ...

> See comment #8 - "hardware keyboard" unfortunately isn't necessarily what
> you'd expect, as on the driver-level it tends to mean "thing with at least
> one button". Plugging in a webcam with a physical record/pause button
> usually doesn't mean that the user wants to input text via morse ...

I did notice a whole lot of stuff in my convertible laptop is recognized as a "keyboard" (yes, including the webcam, despite it having no actual buttons). But surely there could be a way to tell those apart from a real keyboard as laymen mean it?

When I say "surely", I mean "maybe not". But a (too?) naive way could be to check for presence of the word "keyboard" in the device's name. This is the list of my devices from xinput:

    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ Power Button                            	id=6	[slave  keyboard (3)]
    ↳ Asus Wireless Radio Control             	id=7	[slave  keyboard (3)]
    ↳ Video Bus                               	id=8	[slave  keyboard (3)]
    ↳ Sleep Button                            	id=9	[slave  keyboard (3)]
    ↳ USB2.0 HD UVC WebCam                    	id=13	[slave  keyboard (3)]
    ↳ SYNAPTICS Synaptics Digitizer V04 Pen	id=15	[slave  keyboard (3)]
    ↳ Asus WMI hotkeys                        	id=16	[slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard            	id=17	[slave  keyboard (3)]
    ↳ ASUS Tech Inc. ASUS HID Device          	id=10	[slave  keyboard (3)]
    ↳ ASUS Tech Inc. ASUS HID Device          	id=12	[slave  keyboard (3)]

I bet it's not too hard to guess which one is the actual keyboard. It would be quite heuristic as a method, but it could always fall back to your concept ("wait until a key is pressed") if no device is found with a name containing the word "keyboard".

Actually I lied, the real keyboard device is id 10, which doesn't actually contain the word "keyboard". Whoops.

(In reply to Lorenzo J. Lucchini from comment #15)
> But what is the use case where a physical keyboard IS present, and yet the
> user would like the OSK to appear due to the touchscreen being used, until a
> key on the physical keyboard is pressed (i.e. the last used device becomes a
> keyboard)?

Android has a setting where you can always show the on-screen keyboard even when a physical keyboard present.  I think GNOME has this in Accessibility?

> OSK never appear at all when my device has a hardware keyboard attached or
> connected via USB or Bluetooth.

We could use a system where we "tag" devices that have been used as a keyboard (when a non-special key is pressed).  Thus, if we get a valid key press from a device, we tag that device and hide the on-screen keyboard (if always-on is not checked).  The code to display the keyboard now would just see if the always-on is checked or if any tagged devices are still plugged in.

The worst side effect would be that unplugging a keyboard and plugging it back in would display the on-screen keyboard until you press a key.  Cameras and such that can't type "normal" letters and numbers never get tagged ... and even if they can, if you don't use them, they still pull up the virtual keyboard

> Android has a setting where you can always show the on-screen keyboard
> even when a physical keyboard present.  I think GNOME has this in
> Accessibility?

Well, sure, some people may want to have the on-screen keyboard ALWAYS on, but that's a different situation, and as you say, it's already covered by the accessibility settings. This is more about the current method used for deciding when to bring the OSK up for people who DON'T want it all the time being suboptimal.

> We could use a system where we "tag" devices that have been used as a keyboard
> (when a non-special key is pressed).  Thus, if we get a valid key press from
> a device, we tag that device and hide the on-screen keyboard (if always-on
> is not checked).

Assuming things that pass for keyboards but aren't really keyboards only send special keys, that would probably work. I wanted to mention something like that in the message where I got my own computer's input devices' behavior wrong, but it seemed a bit of an overengineered solution, too much for too little gain perhaps.

I think maybe if there isn't a simple way to ask a device "are you a full keyboard?" and get a reliable answer, then Florian Müllner's concept of withdrawing the OSK on keypresses is the most viable solution in the short term.

any progress with annoying and old problem?

Maybe it makes more sense to use chassis type defined by systemd-hostnamed as source of information if onscreen keyboard is necessary or not? For example if we deal with laptop most likely user doesn't want onscreen keyboard. But if it's tablet or convertible - then enabling keyboard by default indeed make sense. However, ability to disable it even in this case is still necessary - bug 772778.

Obviously, such move would require systemd-hostnamed to better detect if system is running or tablet or not (for now seems like all tablets is detected as laptops) or maybe Gnome could provide user some way to select chassis type from Gnome Settings, or in Gnome initial setup?

Selfish thought maybe, but this approach would make it just as inconvenient for me to use my convertible laptop with its touchscreen as it is currently, and has been for a long time now despite all these open bugs... which is VERY inconvenient.

I can't have an on-screen keyboard pop up all the time I use my touchscreen despite the fact that I my normal keyboard is connected, as that is a complete hindrance to everyday use. Right now this means I just don't use the touchscreen (together with the continued lack of a way to right click because A says it should be implemented in B and vice versa, but that's another story).

This IS a laptop for most intents and purposes, and the fact that you can sometimes detach the keyboard to use it as a tablet doesn't change its main use... and I think people working on this need to realize that this type of machine is common in the user world, even if maybe not in the developer world: after the Microsoft Surface, every OEM has started manufacturing several successful models of this type.

Have a look at Onboard, which I would just use instead of Caribou if I could convince Caribou to stop trying to interfere: it has several methods to automatically decide whether or not it should pop up, and while they require much user configuration which is not in GNOME's style, I suspect some of them could be picked up and made more automatic.

Even the imperfect "pop up Caribou first, but then hide it again if the user presses a hardware key" method which is currently implemented could work, IF there were a minimum of memory state kept, namely whether any input device was disconnected since last time Caribou was hidden: this would mean that as long as I don't detach *something*, Caribou would not pop up again.
Instead, the way it is now, it just means it hides when I press a hardware key, but then pops up again as soon as another text box (or something resembling one) is in focus, which makes it perhape even more confusing.

For anybody else reading this that doesn't want the caribou screen keyboard to show up at all, I applied a hack similar to Sam Moris (above). I've got a Dell XPS 15 with touch screen, so I'll always have a keyboard, I never want caribou to open _automatically_.

1. git clone the gnome-shell repository somewhere (I put mine in /usr/local/share)
2. git clone gnome-shell-sass repository into the data/theme/ directory within the gnome-shell repository
3. edit the file js/ui/keyboard
4. around line 307, in the _syncEnabled function, insert after the 'this._enableKeyboard' statement the line 'this._enableKeyboard = false;'

Looks like this:

    _syncEnabled: function () {
        this._enableKeyboard = this._a11yApplicationsSettings.get_boolean(SHOW_KEYBOARD) ||
                               this._lastDeviceIsTouchscreen();
        this._enableKeyboard = false;
        if (!this._enableKeyboard && !this._keyboard)
            return;

...

5. go back to the gnome-shell directory
6. './configure'
7. './make'
8. './make install'

I know this is a quick and dirty hack, but if you're getting frustrated like I was, this helps solve the issue. Again, this will always prevent the keyboard from showing up, unless you open caribou manually / separately when you need it.

Since this has been a known issue for > 2.5 years, and reliably automatically detecting a physical keyboard seems to be more than a quick fix, can someone please add a dconf key to unconditionally disable the on-screen keyboard (i.e. irrespective of touchscreen presence)?

That way users can work around this in the meantime without having to patch and rebuild GNOME Shell, which for instance breaks distro-provided updates.

Another option might be a skeleton implementation of "disable OSK if physical keyboard present" with initially dummy logic for "is physical keyboard present" (i.e. that always return false), and a dconf key for "whitelisted keyboard IDs" that can be manually populated by the user with an ID of their own keyboard.

The latter option wouldn't break anything, but give the user a mechanism for getting correct behaviour via a one-time manual whitelist of their own keyboard.

*** Bug 766451 has been marked as a duplicate of this bug. ***

Is this a duplicate of bug 788188?

No, it's not.

This bug concerns the onscreen keyboard appearing *even when a hardware keyboard is connected*, and the behavior it describes has been around for a long time.

Bug 788188 concerns the onscreen keyboard appearing after a touch event *even when a text input box isn't in focus*, which, if true, is a much newer issue, as I can personally confirm this used not to happen.

Please read beyond the bug title when answering a question.

As mentioned previously, "disable the osk when a hardware keyboard is present" is possibly not a bug at all, as having consistent behavior when activating a text entry by touch is hardly unreasonable.

However having the keyboard pop up even when *not* using touch (for example when using a physical keyboard *cough*) clearly *is* a bug.

I use a laptop with touch screen.
I exclusively use my touch screen like a mouse, not like a keyboard.
To type words I exclusively use the physical laptop keyboard.
Therefore I think that an option to completely disable OSK (useless for me) must be available (this option is already available but is not working) when there is a physical keyboard.

Currently OSK appears when I touch any window, even when no text field is available/focused. This stupid problem (impossible to completely disable this crap OSK) becomes the use of my device almost impossible. It's extremely annoying.

(In reply to Strangiato from comment #30)
> I use a laptop with touch screen.
> I exclusively use my touch screen like a mouse, not like a keyboard.
> To type words I exclusively use the physical laptop keyboard.
> Therefore I think that an option to completely disable OSK (useless for me)
> must be available (this option is already available but is not working) when
> there is a physical keyboard.
> 
> Currently OSK appears when I touch any window, even when no text field is
> available/focused. This stupid problem (impossible to completely disable
> this crap OSK) becomes the use of my device almost impossible. It's
> extremely annoying.

It's not impossible to disable the OSK. See comment #24 above if you're desperate and never want the OSK to display. I had the same problem, and rebuilding gnome-shell worked for me (albeit I need to remember to update it manually now and then). 

Nevertheless, the issue still exists and needs to be fixed. I would do so (add a conf key), but I don't have the experience.

I meant It's impossible to disable OSK via gnome settings.
Rebuild GS is not a solution.
Fix this problem should be a priority for Gnome 3.28.

(In reply to Florian Müllner from comment #29) 
> As mentioned previously, "disable the osk when a hardware keyboard is
> present" is possibly not a bug at all, as having consistent behavior when
> activating a text entry by touch is hardly unreasonable.
> 
> However having the keyboard pop up even when *not* using touch (for example
> when using a physical keyboard *cough*) clearly *is* a bug.

There is a broad swathe of devices with touchscreens and permanently attached keyboards.

Especially for the class of device without 180 degree hinges (i.e. the keyboard is never inaccessible), showing the OSK is basically *never* useful behaviour, and "consistent behaviour when activating a text entry" is actually not reasonable for that device.

Please see my previous comment - I appreciate the difficulty of reliably determining *real* physical keyboard presence; even then, for instance 180-degree laptop hinges present further problems (since the KB may be physically connected, but effectively unavailable).

For this reason, *until* there is reliable auto-detection and automatic behaviour, there *needs* to be at the least a dconf switch for this.

Additionally, since this is not niche hardware (cheap laptop with standard hinges and touchscreens are incredibly common in big box retailers in many markets), it is strongly arguable that it should be exposed in a UI, either Settings, or at the least Tweaks.

(In reply to Florian Müllner from comment #29)

> Please read beyond the bug title when answering a question.

I definitely have (given also that I have been following this bug for longer than a year, as I have been a heavy user of touchscreen devices with GNOME since 2014, and this bug has severely affected my ability to use their touchscreens productively).

> As mentioned previously, "disable the osk when a hardware keyboard is
> present" is possibly not a bug at all, as having consistent behavior when
> activating a text entry by touch is hardly unreasonable.

Please help me understand. My impression was that "duplicate", in bug report terminology, referred one bug report describing the same behavior as another.
Bug 788188 describes a markedly different behavior from the present bug 742246, despite both of them concerning touchscreen/keyboard interaction in some way.

I am also under the impression that when a reported behavior is deemed to be desired behavior, that's typically handled by closing the bug with terminology like NOTABUG or WONTFIX, without marking it as a duplicate of something else.

> However having the keyboard pop up even when *not* using touch (for example
> when using a physical keyboard *cough*) clearly *is* a bug.

Indeed, if the other one *is* admittedly a bug, then marking the one that "isn't" as a duplicate (even without considering that it was filed years earlier, back when the behavior described in the newer report *wasn't occurring at all*) would imply that either both are actually bugs, or neither is a bug. That would be somewhat inconsistent and illogical.


Anyway, to entertain the merits of whether this one (743246) is or is not a bug, let me point out that in bug 788188, you warn:

> Big disclaimer: I don't have any touch hardware to test, so those patches are pretty much just guesswork.

Thank you for the patches, and, well, I do have touch hardware to test, and I will try them on it; for now, I can confirm that *this* bug is definitely a huge issue for users of touchscreen devices equipped with keyboards.
I have an Asus T100TA and an Asus T302CA, which I have been using as my primary computers starting in January 2014.
They are both convertible "laplets", meaning they are intended to act as laptops unless/until you detach the keyboard part, except of course that their touchscreen is meant to be useful either way.

And it *would* be usable and useful, if it hadn't been crippled in GNOME by this issue (743246) which, as other touchscreen users have mentioned, has rendered using touchscreens in this sort of scenario effectively unfeasible for more than two years.

Very few people who are using a laptop-style machine are going to control it via the touchscreen, if that means a software keyboard keeps popping up and taking up half the screen, and then when you instruct it to go away, it comes back every time a text input box enters focus again. I have extensive experience with using such hardware, and to be clear, this mechanism is UNUSABLE.

Currently, there is no way to disable the onscreen keyboard (either automatically by means of the hardware one being present, or manually), unless one hacks into files that the user isn't expected to touch -- and even then, other related but not identical bugs (most of which seem to have been played whack-a-duplicate with) used to make even the ugly hacks unable to completely solve the matter.

Note that you when you mention that "having consistent behavior when activating a text entry by touch is hardly unreasonable", that may certainly sound reasonable from a developer's point of view, but I will provide a couple of common use cases under that paradigm to demonstrate user perception:
- A "text entry" is already activated by any means (perhaps due to a text editor or word processor taking up most of the screen, as is often the case when editing text); now, touching anywhere on that causes the OSK to pop up, and when the user wants to select a portion of text using the touchscreen, that is actively hindered by a big OSK popping up right where the text you intend to select is.
- A user is migrating from Windows 10, where even if hardware keyboard detection fails to reliably prevent the OSK from showing from the start, the OSK can be hidden away explicitly by the user and will not come back again unless either explicitly invoked, or unless the hardware keyboard is detached and the machine enters tablet mode; the user, frustrated with the apparent impossibility of keeping the OSK out of the way when using a hardware keyboard in GNOME, gives up and switches back to Windows.


As a personal note, while I appreciate your work, I would really appreciate not being effectively called stupid - which implying that someone has not "read beyond the title" accomplishes - for answering an explicit question in a neutral and factual way (i.e. stating the factual difference in what two reports describe, when asked if they are duplicate), both in general, and in particular when it comes to an issue that I have been following for years as it impacts me directly, together with other issues that are related but distinct.

FWIW, This request is observed on the newer onscreen keyboard design (See "osk activation" at https://wiki.gnome.org/Design/OS/ScreenKeyboard#Tentative_Design), which I am implementing for 3.28 (See https://git.gnome.org/browse/gnome-shell/log/?h=wip/carlosg/osk-cldr). This point is not yet addressed there, but is near the top of the remaining items, so there is an ETA for the fix.

(In reply to Lorenzo J. Lucchini from comment #34)
> As a personal note, while I appreciate your work, I would really appreciate
> not being effectively called stupid - which implying that someone has not
> "read beyond the title" accomplishes -

https://wiki.gnome.org/Foundation/CodeOfConduct

"Assume people mean well:

If something seems outrageous, check that you did not misinterpret it. Ask for clarification, but do not assume the worst."

We get many bugs, some with vague descriptions, or similar symptoms or user-visible effects. And we get people doing "me too" on the wrong bugs all the time, even if we for example chose to use a certain bug# to track a specific change. The way I read Florian's comment is pretty literal, because there's been enough cases of people literally doing that, but gladly it is not the case at hand.

*** Bug 772778 has been marked as a duplicate of this bug. ***

Problem persists in Gnome 3.30, Arch Linux.

*** This bug has been marked as a duplicate of bug 739293 ***

Gnome v3.34.1 in manjaro
I am very happy about that I finally found an gnome-shell-extension to disable osk FOREVER. This is the link: https://extensions.gnome.org/extension/1326/block-caribou/
I unzipped it, modified the metadata.json altering `shell-version` to 3.34.1(is is necessary?) and use `gnome-extensions pack` and `gnome-extensions install`(available since gnome v3.34) to install, and after a reboot and enabling this ext in gnome-tweak I get rid of osk.