Using Linux on a 2-in-1 PC

2-in-1 laptops are amazing. The capabilities of a touchscreen with a stylus paired with the versatility of a normal PC is phenomenal. One second you are drawing or taking handwritten notes, the next you are browsing the web or writing code; all on one device and one OS. Especially for digital artists, students or even teachers, 2-in-1 devices are amazing tools because of these reasons.

Arguably, the primary OS for 2-in-1 devices is Windows. This makes sense, given the obvious market share of Windows and the fact that 2-in-1 devices are especially appealing to the average customer who is not particularly tech-savvy. Furthermore, a lot of software required for 2-in-1 devices is Windows only. This software is not just drawing programs with touch support, but also all the utility software that manages the stylus, touchscreen and the mode switching of the device: Needless to say, the entire 2-in-1 ecosystem is heavily dominated by Windows, and it makes sense.

But this begs the question: Can we have a fully functional 2-in-1 experience on Linux?
The answer to this question is a big Yes but with some asterisks and typical Linux tinkering involved.

This guide will explain how you can set up a 2-in-1 device on Linux, provide some software recommendations and even dive into how you can rice your 2-in-1 setup to get an experience that may be even better than on Windows.

The great trouble: Hardware support

Before we can start properly diving into the guide, we have to address one troublesome subject: hardware support for 2-in-1 devices on Linux.

This subject is troublesome since hardware implementation for 2-in-1 devices can be vastly different across the board and whether a particular kernel version supports it is hard to say. Generally speaking, a 2-in-1 device consists out of input peripheries (devices) in the form of:

• A touchscreen
• A stylus with various modes (draw, erase), buttons and certain extra functionality (Bluetooth, pressure sensitivity)
• A sensor to determine whether the device is in tablet mode or laptop mode
• A gyroscope to determine the screen’s desired orientation
• …and potentially some other stuff

If you are unlucky, you will find that Linux does not support all your devices, rendering the goal of a “fully functional 2-in-1 experience” unachievable.

Recommending hardware is not my strength, and it is always a very risky endeavor if the bought hardware ends up not working the way you want to. Therefore, I can only give a few loose recommendations:

1. Research on the internet which 2-in-1 devices work for people on Linux.
   2-in-1 on Linux is not an obscure subject. Other people have working setups and using their hardware recommendations can make it easy to find a device that will work for you.

2. Do not get the newest, bleeding-edge 2-in-1 hardware.
   This is rather obvious. The newer the hardware is, the more likely it is that no compatible kernel versions exist for it.

3. If your device is not working, test on the latest kernel and look up your input devices. It is possible the hardware you want to use is already supported on some newer kernel versions (not LTS), or even actively developed. Looking up the devices that are not working with libinput list-devices can maybe lead you to some resources that can help you troubleshoot.

4. Use Wayland for testing.
   This will be elaborated upon shortly, but Wayland is the way to go when it comes to any advanced input devices. Before you conclude that your device is not working properly, test it on Wayland first.

With all that said, I have been using the “Dell Inspiron 13 7000” for this guide. It did not work for me perfectly at the start, but at some point a kernel update allowed it to be fully functional. That said I would not outright recommend it, due to some of its features being uniquely tied to Windows and not being super “Linux-friendly”.

Getting started: Basic software

Desktop Environment + Wayland

The first thing you will want for your 2-in-1 laptop is a desktop environment or even just a window manager. Regardless of your choice, the important part is that it uses Wayland as its backend.

There is a lot of debate around Wayland and often times there are good reasons to not use it and prefer Xorg instead. However, when it comes to any advanced input devices like a stylus or touchscreen, this is not the case!
Wayland easily supports many of these devices out of the box, whereas with Xorg you will have to install extra software to get basic functionality. A great example is the stylus: Wayland will recognize it as one and utilize its features such as pressure sensitivity¹ right away. Xorg, however, will see your stylus as just another mouse device. Furthermore, a lot of actively developed software for 2-in-1 devices is Wayland-only. No matter what grudges you have against Wayland, you should heavily consider switching to it for your 2-in-1 device.

Your primary candidates for Wayland DEs are GNOME and KDE. If you want to use these, go for it. However, I heavily recommend to use a (tiling) window manager instead. Your primary options here are Sway and Hyprland.

The reason for preferring WMs is that they are more customizable which is very important to get the most out of your 2-in-1 devices. We will be using software later that can arbitrarily run any shell command in response to certain touch inputs. If we want those commands to modify aspects of our desktop, then WMs are the way to go.
I went with Sway for this guide due to its shared polyglot config with i3.

You may be opposed to the concept of tiling window managers, but the workflow they encourage is great for laptops where using the touchpad a lot is quite a nuisance. You will also find that their tiling capabilities work great for simulating the feel you would have on a pure tablet device.

Tablet/laptop mode switching with “linux_detect_tablet_mode”

We want to start by being able to control what programs run depending on whether our device is in tablet mode or laptop mode. For example, we only want an on-screen virtual keyboard if we are in tablet mode, but not in laptop mode.

To do this we will use a small Ruby program: linux_detect_tablet_mode. This allows us to call any shell scripts whenever the device mode switches. The switch is detected by monitoring the appropriate input device. The device path is specified in the program’s config file: watch_tablet.yaml.

Here is my config. Note that many of the programs toggled in the config will be explored shortly.

# Use /dev/input/by-path/ to locate tablet_switch device. Or rely on external script to enter append value automatically
# input_device: /dev/input/by-path/

modes:
    laptop:
        - killall "rot8"
        - rot8 -O && (sleep 3 && rot8 -O) &
        - killall "squeekboard"
        - killall "lisgd"
        - rmdir "/tmp/system_cmd.lock.d/"
        - dunstify -u low "Entered laptop mode!"
    tablet:
        - rot8 --invert-y &
        - squeekboard &
        - sleep 3 && tablet_util.sh lisgd &
        - gsettings set org.gnome.desktop.a11y.applications screen-keyboard-enabled true
        - mkdir "/tmp/system_cmd.lock.d/"
        - dunstify -u low "Entered tablet mode!"

I’m actually using an external script to set up the input_device because I found by-path to not work for me consistently. If you are curious about my solution, you can find the external script in my dotfiles.

The following video shows the mode switching. Notice how an on-screen keyboard is spawned as the tablet mode is entered. The switching of the mode is visualized with a desktop notification

Rotating the screen with “rot8”

We want to rotate our screen around and have its orientation adjust accordingly. To do this we will use rot8 - a daemon that monitors the gyroscope of our device and changes the screen orientation accordingly.

The setup of rot8 is pretty straight-forward. Once you verify it works, you might need to tune its settings to rotate in the way you expect it to (i.e. inverting certain axes). Note that when using Sway, you might need to map your inputs to the appropriate output like so (example):

input "type:tablet_tool" map_to_output eDP-1
input "type:touch" map_to_output eDP-1

Another tip is to add a considerable sleep delay in your watch_tablet config when switching back into laptop mode.

- rot8 -O && (sleep 3 && rot8 -O) &

Sometimes the daemon is a bit eager to rotate your screen, making you end up with a wrong orientation when you go back into laptop mode. This delay fixes this.

On-screen virtual keyboard with “squeekboard”

In order to be able to write anything while in tablet mode, we need an on-screen keyboard. In particular, we want an on-screen keyboard that runs native on Wayland and does not utilize Xwayland. This is important because Xwayland keyboards may not work properly or even crash.

My personal recommendation is squeekboard for this due to its lightweight nature (few dependencies) and ability to load custom keyboard layouts.

It is important to note that virtual keyboards on Linux aren’t perfect. Sometimes input fields are not recognized, and the virtual keyboard does not spawn automatically. Therefore, you should implement some way that allows spawning the virtual keyboard manually. For squeekboard, this can be done with the commands:

gsettings set org.gnome.desktop.a11y.applications screen-keyboard-enabled true
gsettings set org.gnome.desktop.a11y.applications screen-keyboard-enabled false

This leaves the question of how we are supposed to execute these commands in tablet mode without a virtual keyboard present. For this you can either use gestures, toolbar buttons or some creative solution of your own.

Swipe gestures with “lisgd”

One very powerful method of executing any command while in tablet mode is to have swiping gestures. The small C program lisgd allows us to define our own gestures and what commands we want to run. All we need to do is configure it and provide it the input device that maps to our touchscreen.

The possible swiping gestures are determined by the amount of fingers used and in which direction was swiped; all cardinal and diagonal directions are possible. The configuration can be done “suckless-style” by compiling lisgd ourselves and modifying config.h, or we can simply provide command line flags. I recommend to not use any gesture involving just one finger, since it is easy to trigger these accidentally if you are using your finger to tap around.

Stuff you might want to trigger by gestures are:

• Toggling your virtual keyboard manually
• Switching workspaces in your tiling window manager
• Moving windows in your tiling window manager
• Quick-start some important program
• …or anything else!

Controlling your WM with swiping gestures gives you an experience that is unlike anything you would have with a conventional desktop environment (or even with Windows). It really sells you the idea that your laptop is in a tablet mode right now.

Here is an example of my lisgd config in the form of command-line flags:

event="$(sed -n '2p' /tmp/watch_tablet.yml 2>/dev/null)"
lisgd -d "${event:2}" -g "2,RL,*,*,R,swaymsg workspace next" -g "2,LR,*,*,R,swaymsg workspace prev" -g "3,RL,*,*,R,move_window.sh -1" -g "3,LR,*,*,R,move_window.sh 1" -g "3,UD,*,*,R,swaymsg bar mode toggle touch-bar" -g "3,DU,*,*,R,tablet_util.sh toggle_keyboard" &

Note that I am again using a custom solution for finding the touchscreen device that must be provided to lisgd. You can check my Dotfiles to explore the rest of my tablet setup.

The following video shows lisgd’s swipe gestures in action. We open the program Krita, move it to the next workspace and then keep switching between the current and next workspaces. All that just with finger gestures.

Taking it further: Advanced software

The software shown in the previous section gave a basis for recreating the bulk of features available on Windows. This section will now show some advanced software / concepts you might want to employ or look into.

Never leave tablet mode with a “touch toolbar”

One annoying thing about tablet mode is that it is hard to do anything except using your stylus. Even with a virtual keyboard, it is quite difficult to interact with your system, especially when using a tiling window manager that is entirely reliant on keyboard inputs. The aforementioned gestures can help a bit, but we are limited to only a few gestures, and they can be a bit clunky to use.

The solution is a custom touch toolbar. That is, a toolbar that has buttons which can trigger whatever we want to:

• Open an app launcher like Rofi
• Open a file manager
• Toggle the virtual keyboard
• Adjust the brightness of the screen
• Adjust the volume
• Take a screenshot
• …the possibilities are, again, endless.

There are many different ways to implement a custom toolbar. My personal recommendation is to utilize one of the many “<insert-name>-bar” programs. I use i3blocks as such a bar.

The idea is to set up a second bar with your tiling WM that you can toggle on and off, so it does not take up space in laptop mode. For Sway I utilize this command which toggles a second bar called touch-bar.

swaymsg bar mode toggle touch-bar

The setup for touch-bar looks like this:

# Extra bar for touchscreen functionality
bar {
	id touch-bar
	position top
	status_command i3blocks -c ~/.config/i3blocks/touch_bar
	workspace_buttons no
	mode dock
	modifier none
	tray_output none
}

What I do is that I toggle the touch-bar with a swipe gesture. Once it is toggled, I can then use my stylus to click the buttons I have configured within i3blocks to achieve whatever functionality I want. Here is a snippet of my i3blocks touchbar configuration:

[previous]
full_text=[  ]
command=swaymsg workspace prev >/dev/null

[move-prev]
full_text=[ 󰳝 ]
command=move_window.sh -1 >/dev/null

[move-next]
full_text=[ 󰳟 ]
command=move_window.sh 1 >/dev/null

[next]
full_text=[  ]
command=swaymsg workspace next >/dev/null

[workspaces]
full_text=[  ]
command=swaymsg exec "tablet_util.sh toggle_workspaces" >/dev/null

[separator]

[screenshot]
full_text=[ screen 󰋩 ]
command=screenshot.sh >/dev/null

[files]
full_text=[ files 󰝰 ]
command=swaymsg exec "tablet_util.sh toggle_files" >/dev/null

The full config file can be found in my dotfiles. If certain characters above are not rendered, it is because they are Nerd Font Icons.

The following video showcases the configured toolbar. It shows taking a screenshot, interacting with Rofi and finally toggling the on-screen keyboard.

Running commands by drawing with “mouse-actions”

The logical advancement to swiping gestures are drawing gestures. That is, using your stylus (or mouse) to draw a shape and having certain commands executed in response.

The program mouse-actions allows doing exactly that, albeit it is still in an Alpha version. I have only tested it superficially, but was able to conclude that it can work for a 2-in-1 setup if desired.

I am not using mouse-actions personally, but I will mention its potential use here.

Finalizing the setup: Additional software

This section gives some opinionated software recommendations that go well with a 2-in-1 setup. They are not related to achieving any touch-specific functionality, but more so personal endorsements.

Touch-friendly app launcher and file manager with Rofi

Utilizing an app launcher is already common practice with tiling window managers. However, by configuring Rofi (or any other app launcher), you can make it particularly touch friendly by utilizing big icons and having a layout similar to that of the GNOME launcher.

The real treat, however, is that Rofi comes shipped with a minimal file browser! Utilizing the same touch-friendly layout for the Rofi file browser is hitting two birds with one stone. Not only do you have a file browser that is easy to use on a touchscreen, you also got one included for free by utilizing Rofi.

I prefer Rofi’s file browser since it is very lightweight and it allows to easily open files. No need to install an additional file browser that you may not use, especially if your normal file browser is terminal-based which is practically unusable with a touchscreen.

Free and open-source drawing with Krita

This is just a small overview on using Krita with a 2-in-1 device. Using Krita is definitely not every artist’s cup of tea, but I will note its usage here because of its open-source nature and excellent Linux support.

Using the touch setup described here, Krita should work out of the box by supporting pinch-zooming and pressure sensitivity. However, if additional adjustments are needed, the tablet settings can be found under:

Settings -> Configure Krita -> Tablet Settings

Uniquely, the setting to enable / disable touch painting can be found under:

Settings -> Configure Krita -> General -> Tools -> Enable Touch Painting

Finally, a very useful feature are touch gestures inside Krita. For example, tapping with two fingers to undo and redo. You can customize these under:

Settings -> Configure Krita -> Input Settings -> Touch Gestures

Free and open-source handwritten notes with Xournal++

The best open-source competitor to Microsoft’s OneNote is probably Xournal++. Specifically when it comes to taking handwritten notes in school or university.

Xournal++ works very well with a 2-in-1 touchscreen. You have all functionality supported out-of-the-box like pressure sensitivity and pinch-zooming. It readily offers different kind of paper templates (lined, chequered) and a decent arrangement of basic drawing tools. You can easily embed any image into it and later export it as PDF.

The only feature missing is support for an “endless canvas” akin to what OneNote offers. However, I personally find the workflow of utilizing real paper sizes digitally more preferable.

Definitely give Xournal++ a try if you are looking to use your 2-in-1 device for taking notes in class or a similar setting.

Outlook - What is to come?

Utilizing a 2-in-1 device with Linux is very much possible, albeit a lot of setup is needed which makes the experience not really exist out of the box. That said, it is amazing to see the community having crafted all kinds of different tools that, when combined, give an even better experience than on Windows. Perhaps, we will see major Linux distros support 2-in-1 devices officially in the future.

That said, there are some features I hope to see eventually realized on Linux as well:

• The ability to remap stylus buttons.
• Support for converting handwritten text into typed text as an alternative to tapping on a virtual keyboard.
• Greater touchscreen support for some Linux (art) programs.

For now, I hope this overview guide on using 2-in-1 devices on Linux has been helpful to you.