Hello,
I am running Endless OS 3.8 on a Lenovo Miix 3-8 tablet (z3735f Atom Bay Trail, 2GB RAM, 32GB, 1024x768 screen). Most components including wifi, bluetooth, multitouch and screen rotation are working correctly.
This device has a 64bit processor yet only supports 32bit UEFI, and despite this, I had no problems booting and installing Endless OS directly from USB thumb drive. This is by far the most polished, ‘touch-friendly’ linux I have tried. Kudos to the Endless OS team!
QUESTION: I sometimes use the existing onscreen keyboard, and it works well in landscape mode. However, when in portrait mode, there are two different versions of the screen keyboard that may appear. One is clearly more usable than the other (see pics). Is there some way to control which version appears?
Hi Byron,
Thanks very much for your response. After re-reading my original post (sorry for the poor quality of pictures), I’d like to clarify a few points:
The problem only occurs when using the tablet in portrait mode.
The screen keyboard version shown on the left (let’s call it v1) is obviously the preferred layout, since the keys are larger, and result in fewer typo errors. Unfortunately, v1 appears far less frequently than v2 (perhaps 1 out of 20 times).
I don’t know of any way to recreate these instances when v1 appears instead of v2. It seems to be at random.
This issue also happened in the same way when using one other GNOME distro (Ubuntu 20.04) which I have previously tried on this device.
This is admittedly a minor UX issue in the grand scheme of things, but it would be nice to resolve nevertheless
After further experimentation, it appears that the preferred keyboard version can indeed be reliably summoned in portrait view by first rotating the screen to landscape view, bringing up the screen keyboard, and then going back to portrait view. After this, the preferred keyboard version reliably appears every time the keyboard is summoned. This is persistent even after the automatic screen idle timeout and password lock engages, or even if user locks the screen via the user menu on the bottom-right corner. However, it is NOT persistent after user log-out, or after poweroff/reboot.
With this workaround, for me the issue is closed. I look forward to the continued development and success of this excellent linux distro on tablet!
Many thanks for your feedback and for following up with the workaround you found!
Especially because you reproduced this on Ubuntu, it sounds like a general issue in GNOME. Maybe you can find an appropriate place to report the bug to the GNOME community in order for this to be improved in future.
We ordinarily target computers with a keyboard and mouse, with a touchscreen only as an optional, secondary input device, so it is interesting to hear from tablet users like yourselves. Beyond this on-screen keyboard oddity, I’d be curious to know how the rest of the experience is. Are there any other significant UI inconveniences?
Well, since you asked I list some of the usability issues experienced below:
I’ve had problems with some device hardware components either not recognised or behaving inconsistently during actual use. Example: Bluetooth works fine for music play to external speaker, but inexplicably fails a simple file transfer from paired desktop (MacOS). I’m not technically adept, so will simply assume that this bluetooth problem, like some other hardware issues, is related to Linux kernel device drivers and isn’t the fault of EndlessOS. Or perhaps it’s a security setting that remains hidden to me.
Occasional UI glitches in the form of: i) mouse pointer appearing onscreen even when using touch-only with no pointing device attached. This can be quite disruptive as touch becomes unresponsive during this time, and takes several seconds to recover. ii) mouse-hover “tooltips” that appear and persist even when using touch-only with no pointing device attached. This is also disruptive visually, and tends to persist rather than fade-away, partially obscuring even overlaid windows.
All the following are likely to be common GNOME-desktop-related issues. Basically, I think 2 GB of RAM may be too little for GNOME+running apps, and this bay-trail processor too weak. Occasionally, during normal use (e.g. web browsing with Chromium or reading docs with Evince) the system can become unresponsive, freezing and then resuming after several seconds. Referring to the system-monitor after these events shows that at least one of the CPU cores had hit 100% before recovering and continuing. I doubt this is a problem with any particular application(s) but rather due to hardware limitation of this device.
Low native screen resolution (1024x768) may be the root cause of the screen keyboard issue already discussed, as well as some other UI issues I have encountered. In portrait mode, 768 horizontal pixels may be too little for several apps tested (including some GNOME apps such as Calendar), resulting in app windows that don’t resize properly, sprawl off-screen, or become truncated and therefore impossible to use effectively. Example: The date/time display (next to system tray) and its combined calendar and notifications window becomes truncated in portrait mode. The notifications portion of that pop-up window seems to be unnecessarily large in any case.
Across a number of applications, the top title bar behaves inconsistently, typically with touch-unresponsive maximise button at top-right (perhaps related to point 4 above), and sometimes with unresponsive back-arrow at top-left (usually if the application window is already maximised). Unresponsive back arrow is never a problem when using a connected mouse.
Feature requests for future EndlessOS releases: In addition to addressing the major UI issues, it would be good to have more user-level customisation. Options to turn off animations or other unrequired features, etc., which could improve usability/performance on older/underpowered devices. Theming options especially for app windows: Currently, grey-and-grey is tiring on the eyes. More visual contrast would be very useful, especially for the title bar and its icons/buttons.
From a tablet user perspective, I would welcome any UI tweaks that improve touch-responsiveness and usability, and help balance the lack of a fine-pointing device with the need to preserve screen real-estate for actual content.
Something that would help us a lot to understand the problem would be this:
Open the application called ‘Terminal’
In this application run the command:
eos-diagnostics
The above command will create a file with the information of your system (example: eos-diagnostic-160614_111731_UTC + 0100.txt); Send us this file so we can analyze and see a possible solution
I have encountered another issue that may be related to low hardware screen resolution, which occurs during installation of EndlessOS (when booting from USB). During the installation process, the screen defaults to portrait mode and apparently cannot be changed to landscape mode until the OS is fully installed and boots from the hard drive. Therefore, any windows are temporarily limited to 768 horizontal pixels during installation. The installation “wizard” window does not resize correctly, and neither is it possible to move the window by clicking and holding on the title bar, even if an external mouse is connected. The “Previous” and “Next” buttons are located on opposite ends of the title bar, and only the “Previous” button is accessible, while the “Next” button is located off-screen. This effectively means that there is no way to click on the “Next” button to proceed with installation except by use of the tab and enter keys and some guesswork.
For me, none of the problems I have listed are “deal-breaking” in and of themselves. Most are temporary and/or can be resolved with workarounds. I don’t expect any fix or resolution in the near term. I have listed and described them only so that you are aware of these issues from a tablet user perspective.
Lastly, the following error messages were displayed in the terminal right after “eos-diagnostics” command was issued, and diagnostics file was successfully created.
(org.gnome.Nautilus:2501): CARIBOU-CRITICAL **: 22:49:59.326: file caribou-gtk-module.c: line 1028: unexpected error: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.Caribou.Keyboard was not provided by any .service files (g-dbus-error-quark, 2)
Gtk-Message: 22:50:01.384: Failed to load module “caribou-gtk-module”
Gtk-Message: 22:50:01.385: Failed to load module “canberra-gtk-module”
Gtk-Message: 22:50:01.386: Failed to load module “caribou-gtk-module”
Gtk-Message: 22:50:01.387: Failed to load module “canberra-gtk-module”
(org.gnome.Nautilus:2501): CARIBOU-CRITICAL **: 22:51:43.628: file caribou-gtk-module.c: line 1028: unexpected error: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.Caribou.Keyboard was not provided by any .service files (g-dbus-error-quark, 2)
(gedit:2678): CARIBOU-CRITICAL **: 22:51:47.810: file caribou-gtk-module.c: line 1028: unexpected error: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.Caribou.Keyboard was not provided by any .service files (g-dbus-error-quark, 2)
