GNOME Bugzilla – Bug 692771
OSK not enabled automatically when using touch
Last modified: 2014-09-03 07:22:41 UTC
I got a Samsung Slate Series 7 from work. the OSK doesn't pop up automatically when in any text box, and the mouse cursor is shown. Here's output of test-input-helper and lsusb: Supports XInput: yes Supports XInput2: yes (opcode: 131) Has touchpad: no Has touchscreen: yes Disabled devices: no Device 4 is touchpad/touchscreen: no Device 5 is touchpad/touchscreen: no Device 6 is touchpad/touchscreen: no Device 7 is touchpad/touchscreen: no Device 8 is touchpad/touchscreen: no Device 9 is touchpad/touchscreen: no (tool ID: 0x0) Device 10 is touchpad/touchscreen: no Device 11 is touchpad/touchscreen: no Device 12 is touchscreen: yes Device 13 is touchpad/touchscreen: no Device 14 is touchpad/touchscreen: no (tool ID: 0x0) ------------------------- lsusb: Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 056a:00ec Wacom Co., Ltd Bus 001 Device 004: ID 1210:2624 DigiTech Bus 001 Device 005: ID 2232:1021 Bus 002 Device 003: ID 1a40:0101 Terminus Technology Inc. 4-Port HUB Bus 002 Device 004: ID 8086:0189 Intel Corp. Bus 002 Device 005: ID 03eb:211c Atmel Corp. Bus 002 Device 006: ID 058f:6387 Alcor Micro Corp. Flash Drive Bus 002 Device 007: ID 0781:5567 SanDisk Corp. Cruzer Blade -------------------------
By "mouse cursor is shown" I mean that there's a cursor visible at all time, event tho there is no mouse connected.
(In reply to comment #1) > By "mouse cursor is shown" I mean that there's a cursor visible at all time, > event tho there is no mouse connected. That's fixed in 3.8 through bug 687791. The problem is that the OSK feature isn't toggled on when using the touchscreen. We can't toggle it on manually, because that would make the OSK pop up straight away, as opposed to when needed. I've filed 692773 about this.
Created attachment 234712 [details] [review] cursor: Only enable the OSK when touch is used
Attachment 234712 [details] pushed as 2c5e3f8 - cursor: Only enable the OSK when touch is used
"Disabling the OSK if touch is not used" stops a number of disabled users from using Gnome. Many are reliant on the use of (modified) mouse input for keyboard input and either do not have, or could not use, touch devices. If a user selects OSK in the Accessibility Menu, it is for a reason and should be honoured.
(In reply to comment #5) > "Disabling the OSK if touch is not used" stops a number of disabled users from > using Gnome. Many are reliant on the use of (modified) mouse input for keyboard > input and either do not have, or could not use, touch devices. If a user > selects OSK in the Accessibility Menu, it is for a reason and should be > honoured. That's plainly a bug, please file it separately, and we'll fix it before 3.8 is out.
Pushed to bug 694689
Reverted that patch. commit 236edf2b5db641940743fdd53e97242b11993e07 Author: Bastien Nocera <hadess@hadess.net> Date: Fri Mar 1 16:28:24 2013 +0100 Revert "cursor: Only enable the OSK when touch is used" This reverts commit 2c5e3f8ac3803a19de49d09d1c028b75f7b048d2. The code as it is is broken, as we don't differentiate between "no cursor because we haven't used the device yet" and "a touchscreen has been used". It also changes a GSetting which is something we should not be touching (gnome-shell or gnome-settings-daemon should be using the GSetting in addition to this computed state to show the keyboard or not).
*** Bug 695075 has been marked as a duplicate of this bug. ***
Another case for this problem is devices like Lenovo Yoga or Lenovo Thinkpad Twist, which are "convertible": when you twist the device to tablet mode, the keyboard/touchpad will still be available for the software but the user wouldn't be able to use them. Do we need a separate bug to automatically enable OSK in these cases?
(In reply to comment #10) > Another case for this problem is devices like Lenovo Yoga or Lenovo Thinkpad > Twist, which are "convertible": when you twist the device to tablet mode, the > keyboard/touchpad will still be available for the software but the user > wouldn't be able to use them. > > Do we need a separate bug to automatically enable OSK in these cases? Given that we'll need to disable the touchpad (bug 698226), no.
Created attachment 246528 [details] [review] enable the OSK when touch is used (cursor diabled) Activate the Caribou daemon via D-Bus when the mouse cursor is hidden (and therefore a touch device is being used or input). Quit the daemon when it is no longer needed (when showing the cursor again) but only if the user-configurable accessibility GSettings key is disabled. The D-Bus activation of Caribou depends on the patch to Caribou in bug 683712.
Created attachment 246532 [details] [review] enable the OSK when touch is used (cursor disabled) Improve the commit message.
Review of attachment 246532 [details] [review]: ::: plugins/cursor/gsd-cursor-manager.c @@ +169,3 @@ + if (!manager->priv->cursor_shown) { + /* Activate OSK. */ + g_dbus_proxy_call (proxy, Could we directly call a specific Caribou method ("Start"?) rather than this? @@ +229,3 @@ set_cursor_visibility (manager, gdk_device_get_source (device) != GDK_SOURCE_TOUCHSCREEN); + set_keyboard_visibility (manager, you're not really changed whether the keyboard is available (it should only become available if enabled and you have an entry focused), so visibility is the wrong word here. @@ +488,3 @@ + manager->priv->name_id = 0; + + g_dbus_proxy_new_for_bus (G_BUS_TYPE_SESSION, I'd rather use g_bus_watch_name() to watch for caribou being available.
(In reply to comment #14) > Review of attachment 246532 [details] [review]: > Could we directly call a specific Caribou method ("Start"?) rather than [org.freedesktop.DBus.Peer.Ping]? Sure, although Ping() seems to have the right semantics for this case (and is described in the D-Bus specification http://dbus.freedesktop.org/doc/dbus-specification.html). Can you comment on the Caribou patch in bug 683712? > @@ +229,3 @@ > set_cursor_visibility (manager, > gdk_device_get_source (device) != > GDK_SOURCE_TOUCHSCREEN); > + set_keyboard_visibility (manager, > > you're not really changed whether the keyboard is available (it should only > become available if enabled and you have an entry focused), so visibility is > the wrong word here. Indeed, that was a leftover from an earlier patch. How about "enabled"? > @@ +488,3 @@ > + manager->priv->name_id = 0; > + > + g_dbus_proxy_new_for_bus (G_BUS_TYPE_SESSION, > > I'd rather use g_bus_watch_name() to watch for caribou being available. OK. Should I continue to call the methods (Quit and Start) with the proxy, or use g_dbus_connection_call() instead?
Created attachment 247897 [details] [review] use caribou daemon run() method rather than ping
As discussed on IRC, it would be better if gnome-shell controlled caribou, rather than g-s-d controlling the gsettings controlling gnome-session controlling caribou to finally tell gnome-shell the OSK is there. - In gnome-settings-daemon, make the cursor plugin export whether the OnScreenKeyboard should be force-enabled through a D-Bus property. - gnome-shell would use that property to know whether to 1) use the value of the screen-keyboard-enabled GSettings (if force enabled is false), or force the keyboard on (if force enabled is true). That would also allow the a11y icon not to show up if the OSK is forced on, or to not allow the value in the menu to change if the menu is already visible - We would apply the same rules to the a11y panel in gnome-control-center - gnome-shell would start caribou through D-Bus autostart when the OSK is enabled - gnome-shell would stop caribou when it's not needed - we would remove the code to start the OSK from caribou - we'd also remove the autostart desktop file for caribou
Comment on attachment 247897 [details] [review] use caribou daemon run() method rather than ping As per above comment.
Created attachment 249886 [details] [review] add a D-Bus property for whether to show the OSK cursor: Request the OSK when the cursor is disabled Register 'org.gnome.SettingsDaemon.Cursor' on the session bus. Add a D-Bus property 'ShowOSK' to indicate whether the on-screen keyboard should be enabled, which is triggered when a direct touch device is used for input. (In reply to comment #17) This is an attempt at the g-s-d part of requesting the OSK, and the property seems to work as expected here.
Review of attachment 249886 [details] [review]: I also noticed that the rfkill plugin (and probably a few others) didn't check for g_dbus_connection_register_object()'s retval, and didn't use cancellables. Could you please file bugs for the plugins that don't do it right? Thanks. Looks good to commit after the niggles below. ::: plugins/cursor/gsd-cursor-manager.c @@ +174,3 @@ + &error); + + if (error) { Remove the braces for one-line conditions. @@ +395,3 @@ + G_BUS_NAME_OWNER_FLAGS_NONE, + NULL, + on_bus_name_lost, Why is that needed? Given the content of on_bus_name_lost() just remove it. @@ +460,3 @@ G_CALLBACK (device_changed_cb), manager); + manager->priv->start_idle_id = g_idle_add ((GSourceFunc) start_osk_idle_cb, manager); No need for an idle, especially if we might not need to start the dbus service because the X.org version doesn't allow using per-device idletimers.
Comment on attachment 249886 [details] [review] add a D-Bus property for whether to show the OSK Thanks for the review, I pushed an updated patch to master as commit 30584577f142199003c22c51851aec0058998d53.
After these two patches were committed, what do we still need to be able to close this bug?
(In reply to comment #22) The Caribou patch in bug 683712 (which is marked accepted-commit_now) and the gnome-shell patch in bug 702015 (which has not been reviewed), which need to be pushed at the same time.
So no chance to get it in 3.10. Oh well.
*** Bug 677106 has been marked as a duplicate of this bug. ***
I saw this on a fully up to date F21 system running gnome 3.13.+ on an Asus Slate: http://www.asus.com/Tablets_Mobile/Eee_Slate_EP121/specifications/ I used the Fedora live media and went straight to "Install" and then had to quit and restart when I realised that the OSK hadn't come up on its own.
The gnome-shell and caribou patches have now been merged.