What are the best desktop environments for touchscreens?
Many times, comparisons or analysis of desktop environments from other perspectives, such as whether or not they are light, that is, if they consume few or many resources; also the usability and the intuitiveness of the environment, since it is a factor that is analyzed because it is important that an interface, whether graphic or text-based, should offer facilities and maximize user productivity so that they know well how interact with her without wasting time on other distractions; The power of the environments, their ability to be modified, that is, their flexibility, etc. are also analyzed.
But this time, we are going to see what graphic environments from a different point of view and that is how they behave when they are used with touch screens, instead of when we use keyboard and mouse to interact with them. I have to say that the community of developers of the different projects have done a good job in general and all or almost all have known how to adapt well to these new interfaces, but there are differences between the different philosophies .
Well, here is the list of the best environments for touchscreens:
First of all, make something clear, this is my personal opinion, before there are masses of comments attacking by the order of the environments etc. Each user has their own needs and preferences, so maybe it seems to you that the order is different and you even feel like it or feel more comfortable with another environment that is not even on the list . It’s a matter of taste. The question you should ask is: What environment do I know how to handle best or which one do I feel more comfortable with? And that will be the best option for you .
1-KDE Plasma:
We have already seen that KDE Plasma works well on almost any terrain. It is an environment that works very well, which is very flexible, powerful and, in addition to that, lately the developers have done a tremendous and excellent job to make it much lighter. Before, it sinned to be heavy, despite its benefits, but now consumes very little RAM.
That’s a good thing for touchscreen devices, which, with the exception of desktops that have a touchmonitor, typically have somewhat more limited resources and being able to save some of those resources to use them to move what really matters is very interesting. By the way, remember that for mobile devices you also have the project Plasma Mobile.
2-GNOME 3:
GNOME 3 is very touchscreen friendly, partly because of its simplicity and because of how the space is distributed, because of its large icons, etc., and partly because of the work that has been done on a technical level to adapt it to gestures for this type of touch interface. But against it is its consumption of resources, which as we know is not the environment that consumes the least.
This is not a problem if you have a powerful laptop or desktop PC, but it is in any other case. But as I always say, why destine too many resources for something if it can be avoided. Despite having large resources, it is always better to allocate them to the programs you are running for better performance results.
3-Cinnamon:
The environment Cinnamon presents a very simple, usable and Windows-like interface. That is why it can be a good option for users who come from Microsoft environments. As for touch screens, they have also known how to adapt to them, implementing capabilities to recognize gestures and keystrokes in the latest releases. They still have to improve, since nothing is perfect, but it works well in general. Perhaps another negative detail is that if you have a smaller screen, some elements are very close together and it can lead to errors when pressing and clicking on an element that you did not want .
If you wonder about the best distros for touch screensTo say that Ubuntu, Fedora, Debian, openSUSE, and Linux Deepin could be good options to use without problems with your convertible laptop, 2-in-1, tablet or desktop with a touch screen.
The content of the article adheres to our principles of editorial ethics. To report an error click here.
Full path to article: From Linux » Design » What are the best desktop environments for touchscreens?
Touchscreen
If you ever tried to set up a touchscreen device in linux, you might have noticed that it is either working out of the box (besides some calibration) or is very tedious, especially when it is not supported by the kernel.
Introduction
This article assumes that your touchscreen device is supported by the kernel (e.g. by the usbtouchscreen module). That means there exists a /dev/input/event* node for your device. Check out
to see if your device is listed or try
# cat /dev/input/event? # replace ? with the event numbers
for every of your event nodes while touching the display. If you found the corresponding node, it is likely that you will be able to get the device working.
Available X11 drivers
There are a lot of touchscreen input drivers for X11 out there. The most common ones are in the extra repository:
- xf86-input-evdev (likely the default driver if you plug in your touchscreen and it «just works»)
- xf86-input-libinput ; see also libinput
- xf86-input-elographics
Less common drivers, not contained in the repository, are:
- xf86-input-magictouch
- xf86-input-mutouch
- xf86-input-plpevtch
- xf86-input-palmax
Proprietary drivers exist for some devices (e.g.: xf86-input-egalax AUR ), but it is recommended to try the open source drivers first.
Depending on your touchscreen device choose an appropriate driver. Again, evdev is likely to be the default if your touchscreen «just works.»
Two-fingers scrolling
The two-fingers scrolling has to be implemented on the application side (see this link). For Firefox, see Firefox/Tweaks#Enable touchscreen gestures.
There is a hack to emulates this scrolling behavior for every application in #Touchegg, but the X server still handles it as text selection (at least with Plasma).
evdev drivers
Calibration
Install xinput_calibrator AUR (AUR). Then, run xinput_calibrator and follow the instructions.
Using a touchscreen in a multi-head setup
To use multiple displays (some of which are touchscreens), you need to tell Xorg the mapping between the touch surface and the screen. This can be achieved with xinput as follows.
Take for example the setup of having a wacom tablet and an external monitor; xrandr shows both displays:
Screen 0: minimum 320 x 200, current 2944 x 1080, maximum 8192 x 8192 LVDS1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 1024x768 60.0*+ 800x600 60.3 56.2 640x480 59.9 VGA1 connected 1920x1080+1024+0 (normal left inverted right x axis y axis) 477mm x 268mm 1920x1080 60.0*+ 1600x1200 60.0 1680x1050 60.0 1680x945 60.0
You see we have two displays here. LVDS1 and VGA1. LVDS1 is the display internal to the tablet, and VGA1 is the external monitor. We wish to map our stylus input to LVDS1. So we have to find the ID of the stylus input:
⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ QUANTA OpticalTouchScreen id=9 [slave pointer (2)] ⎜ ↳ TPPS/2 IBM TrackPoint id=11 [slave pointer (2)] ⎜ ↳ Serial Wacom Tablet WACf004 stylus id=13 [slave pointer (2)] ⎜ ↳ Serial Wacom Tablet WACf004 eraser id=14 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Power Button id=6 [slave keyboard (3)] ↳ Video Bus id=7 [slave keyboard (3)] ↳ Sleep Button id=8 [slave keyboard (3)] ↳ AT Translated Set 2 keyboard id=10 [slave keyboard (3)] ↳ ThinkPad Extra Buttons id=12 [slave keyboard (3)]
We see that we have two stylus inputs. We now need to simply map our inputs to our output like so:
$ xinput --map-to-output 'Serial Wacom Tablet WACf004 stylus' LVDS1 $ xinput --map-to-output 'Serial Wacom Tablet WACf004 eraser' LVDS1
You can automate this by putting these commands in your ~/.xinitrc or similar. The mapping will be lost if the touchscreen is disconnected and re-connected, for example, when switching monitors via a KVM. In that case it is better to use a udev rule. The Calibrating Touchscreen page has an example udev rule for the case when a transformation matrix has been calculated manually and needs to be applied automatically.
Using xrandr-watch-git to automate map-to-output
There are xrandr events we can capture from a script. Install xrandr-watch-git AUR , create a script ~/.xrandr-changed with execution permission to perform map-to-output, for example:
#!/bin/sh xinput --map-to-output "Wacom HID 4861 Finger touch" "eDP1"
and start, test and enable the systemd/User service xrandr-watcher.service .
Wayland/Weston
Wayland does not currently have a known method to lock touching to a specific display in any environment other than sway (or wlroots-based supported compositors). There are tools such as weston-touch-calibrator, but Gnome Wayland uses Xwayland leaving the calibrator unable to locate any touchscreen.
Wayland/Xwayland also masks the xinput list and funnels them down to generic xwayland devices such as «xwayland-pointer»,»xwayland-relative-pointer»,»xwayland-touch-pointer», etc. The Wayland method of «Xinput» is «Libinput», but does not have all the same functionality. The current known method to use touchscreens in a multi-head setup is to force Gnome or KDE to use X11. libinput currently assumes the touchscreen(s) covers all available monitors.
Touchegg
Touchegg is a multitouch gesture program, only compatible with X, that runs as a user in the background, recognizes gestures, and translates them to more conventional events such as mouse wheel movements, so that you can for example use two fingers to scroll. But it also interferes with applications or window managers which already do their own gesture recognition. If you have both a touchpad and a touchscreen, and if the touchpad driver (such as synaptics or libinput) has been configured not to recognize gestures itself, but to pass through the multi-touch events, then Touchegg will recognize gestures on both: this cannot be configured. In fact it does a better job of recognizing gestures than either the synaptics or libinput touchpad drivers; but on the touchscreen, it is generally better for applications to respond to touch in their own unique ways. Some Qt and GTK applications do that, but they will not be able to if you have Touchegg «eating» the touch events. So, Touchegg is useful when you are running mainly legacy applications which do not make their own use of touch events.
The two-fingers scrolling has been disabled in the recent rewrite of touchegg 2.0. To enable it, install xdotool and see this closed issue.