ExtremeDullard

Can anybody confirm whether the camera works in Waydroid in Ubuntu Touch on the Fairphone 4?

The camera certainly doesn't work in Waydroid on my ARM laptop, and I've read that support hadn't been added for v4l2 yet. But I've seen a YouTube video that seems to suggest otherwise on Ubuntu Touch (that I can't find anymore of course...)

I really want to convert my FP4 to Linux, but not being able to activate my Android banking app in Waydroid with the QR code is a deal breaker for me.

This clever gizmo turns any USB input devices - or combination of input devices - into any other HID device. Different versions also accept individual switches as inputs.

This means if you have trouble using a mouse, you can turn a joystick or a gamepad into a mouse.

Or if you can use a mouse but you can't click, you can remap the button to some other switch, like a foot pedal.

The possibilities seem endless, but it is a bit on the geeky side. If you're not the technical type, you might want to get some help from a computer or electronics engineer to put together your ideal setup with that one.

Check out the manual's section on accessibility:

https://www.remapper.org/manual/#accessibility-applications

So, as expected, Auschwitz-like detention conditions. All Alligator Alcatraz is missing is the forced labor and the gas chambers.

Do we call America a Nazi country yet, or is it too soon?

Americans should hold their head in shame. And if they really want to be useful, bash it real hard against a wall until they can't vote anymore. They made this happen. AGAIN.

If you're trying to use another Sway session inside your own Sway session (either a nested Sway session or a remote Sway session) or you use an application that uses the same shortcuts as Sway, then you'd like Sway to "get out of the way" and let those shortcuts through.

You can do that by defining a passthrough mode in ~/.config/sway/config:

# Passthrough mode
mode "passthru" {
        bindsym $mod+Escape mode "default"
}
bindsym $mod+Escape mode "passthru"

When you hit Mod+Escape, it enters the "passthru" mode, in which the same binding, Mod+Escape, is the only binding that does anything at all - and that is returning to normal mode. All other normal bindings in that mode will be ignored by Sway and will reach either your nested / remote Sway desktop or your application that expects them.

Here's an example of Sway / application conflict:

In my Sway, Ctrl+Shift+e is set to brings up the emoji picker (rofimoji if you're curious). But Ctrl+Shift+e is also the shortcut to bring up the Developer Tools pane in Firefox. So when I infrequently need the latter, I enable the passthrough mode first.

Of course, when you enter the passthrough mode, passthru appears in your (s)waybar. You'd think it makes it obvious that you're in a special mode, but it's actually really easy to enter the passthrough mode and forget about it. Therefore, if no bindings seem to work properly anymore, remember to look down 😃

Also, if you ever need to enter the passthrough mode in a nested / remote Sway session - like for example if you need the Firefox Developer Tools pane in a remote Sway session, then you'll have to define a different binding to switch passthrough on and off, either in the local session or in the remote session, otherwise they're going to clash.

But it happens very rarely for me, so I didn't bother: all my machines use the same passthrough mode binding in i3 and Sway and I've never run into the problem. But it can happen.

If you come from i3, you might be missing Xephyr or Xnest-like functionalities in Sway - that is, the ability to run another desktop session as another user inside your current desktop.

In i3, I log into my test desktops all the time without leaving my main desktop, and that's something I really miss in Sway / Wayland. So I spent some time putting a script together to do that seamlessly in Sway too. You may find it useful.

In fairness, Sway - or more precisely wlroots - can already run nested natively without any modification. You can test that by opening a terminal and typing sway in it: you'll get a second, identical desktop inside your current one.

The problems come when you want to run another user's desktop within yours, for the following reasons:

1. Wayland makes the incredibly restrictive assumption that the Wayland compositor and clients always run as the same user, and therefore puts the Wayland socket in the user's XDG_RUNTIME_DIR (usually /run/user/<userid>/).

   That's a problem if you want a Wayland application running as another user to connect to that Wayland socket, because other users can't access your XDG_RUNTIME_DIR, and you really don't want to open it up to other users just to be able to access the socket because it's full of sensitive files pertaining to your running session.

   Moreover, since XDG_RUNTIME_DIR is usually a mounted tmpfs, you can't symlink the socket outside the directory either because sockets can't be symlinked across filesystems in Linux.

   In other words, again, Wayland makes it extra difficult to do something simple for no good reason.

2. Sway requires a full login environment - and particularly XDG_RUNTIME_DIR - to be set in the environment, which usually implies that it should also be setup and mounted in /run/user.

   Unfortunately, you can't just sudo into the account you want to run your nested Sway desktop as and start Sway because PAM explicitely doesn't set XDG when su'ing or sudo'ing, and doing it manually is a recipe for problems.

To solve 1, we use a clever piece of software called filterway, which conveniently solves two problems:

• It acts as a sort of gateway: it connects to a Wayland socket on one side, creates its own socket on the other side and links the two. This functionality is used to expose the primary Wayland socket securely without compromising XDG_RUNTIME_DIR.

• It replaces the app ID of the top Wayland client that connects to it - which is really its primary party trick. In this use case, that's useful to track the state of the nested Sway session in the primary session's tree.

There is no package for filterway so you have to clone the Github repo, build the binary and install it somewhere in your PATH. Fortunately, it's just a small utility so building it is really simple.

To solve 2, we use systemd-run to setup the target user's environment as if it was a full login, then run Sway with the correct setup to connect to the primary Wayland display's socket.

So I made a script to tie everything together. You can find it here:

https://github.com/Giraut/nest_sway

Because of course it did...

Great news for those of us who would rather keep their shoes on for practical or social reasons.