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?