Disable primary selection via middle click (wayland, sway)

archlynovice · 2023-10-22 18:15:48

Hi, I spent all day on this but I can't figure it out (newbie).

I'm running Arch with wayland and swaywm on an old Thinkpad (X201). My Thinkpad model doesn't come with a mouse pad, so I have to use typical track point navigation. There is a standard middle click behavior that you can read about here [1].

Obvious problem: Every time I want to navigate using my track point, random stuff is copied all over the place. Not only is this annoying as heck, it's also a security concern for me.

- Solution 1 of said article [1] isn't graceful at all, since it blocks the shell and even my terminal emulator within the sway session.

- Solution 2 is X specific.

- I tried to solve this with wl-clipboard [2], which was promising but I couldn't actually fix it. The idea was to put "wl-paste -pw command" in my bash profile and find a command that clears the primary selection.

- I also fiddled a bit with bindsym button2 in my sway config. Couldn't solve it ...

Thinkpad and wayland doesn't seem like a unusual combination to me. I can't wrap my head around this, since I don't find a single useful information about resolving this properly. What am I missing? After spending hours on deep-talk with ChatGPT (and lots of searching), I kindly ask you to hint me a direction. I don't want to give up yet, but I'm tired. Thanks for your time

[1] https://wiki.archlinux.org/title/clipboard#Selections
[2] https://man.archlinux.org/man/extra/wl- … board.1.en

Trilby · 2023-10-22 21:25:19

It sounds like you have faulty hardware, though I'm not sure if it is in the thinkpad's button, or in one of your five digits: the primary selection will not be pasted on any use of the middle mouse button for scrolling, but only for a press-and-release of the middle button with no other mouse activity nor substantial delay in between.

If the hardware issue cannot be solved, then I believe your only options are to find some libconfig settings that may prevent this or as a last resort patch and recompile sway (which shouldn't be to hard but would need to be redone with each update).

archlynovice · 2023-10-23 06:57:21

Thanks for your response! The behavior you describe works fine on my device. It's just that I sometimes press the middle button first and only after that realize that I don't have to scroll.

Now that I understand (I didn't before) when the middle click pastes or not, I"ll leave it at that for the time being.

Another idea that pop'd up is to bindsym button2 mimic_mouse_activity in my sway config file, which would actually be a graceful solution for this. But I don't know what command may achieve that. wlroots looks promising, but I didn't dive into it yet.

Trilby · 2023-10-23 12:24:57

archlynovice wrote:

bindsym button2 mimic_mouse_activity in my sway config file, which would actually be a graceful solution for this. But I don't know what command may achieve that.

What is "mimic_mouse_activity"? Is that a placeholder name you just made up or are you referring to someting in particular? If binding button2 worked, then you could just bind it to do nothing, or some effective no-op ("exec head -c 1 /dev/null") if an actual command is needed.

archlynovice wrote:

wlroots looks promising, but I didn't dive into it yet.

Promising in what way, for what? Wlroots is a library used by sway. Unless you intend to create your own compositor to replace sway, wlroots would be of no use to you.

archlynovice · 2023-10-23 13:40:14

I see. Sorry for the quality of my last reply. Here's some clarification:

Yes, the command was meant as a placeholder. The idea is to bind the middle click button (button2) to a command that moves the cursor a little. Thus, there's always mouse activity between press and release of said button and the condition for the paste functionality is never met. Problem solved, no? There might even be a command that 'mimics' mouse activity without changing cursor position at all - like a ping or something.

In short search for that, I stumbled across wlroots and imagined some of the here [1] mentioned variables could achieve that. But you're right, that was just a wild guess.

As for AUR packages, wlrctl [2] seems to have a command for this. A line in the sway config file could maybe look like this (didn't try it):

bindsym button2 exec wlrctl pointer move 0 1

Add-it: Tried it, does not work. Whether this approach was doomed from the beginning or failed on my skills, I cannot say.

[1] https://drewdevault.com/2018/07/17/Inpu … roots.html
[2] https://git.sr.ht/~brocellous/wlrctl

Last edited by archlynovice (2023-10-23 15:46:53)

seth · 2023-10-23 22:53:00

You could perhaps bind it to a diferent button instead?
https://github.com/swaywm/sway/issues/3 … -475904331

Trilby · 2023-10-23 23:38:03

archlynovice wrote:

Thus, there's always mouse activity

Ah, thanks. I understand your thinking and that's a sound proposal. But the way this works behind the scenes is such that this wouldn't really be relevant. Either binding the button press would be sufficient or not; whether or not this trigger other synthetic mouse movements would not matter. Sadly it sounds like binding the button2 press is not sufficient. So this is a dead end.

archlynovice wrote:

I stumbled across wlroots and imagined some of the here [1] mentioned variables could achieve that.

Perhaps, yes. I referred to this indirectly with reference to the input config settings in swaywm. Sway's config file's input section(s) just provide a different interface to the exact same thing the variables in your link do. Though I've tinkered with libinput a fair bit, and while it has *a lot* of settings that can be adjusted in all sorts of ways, I cannot think of any that would acheive the current goal. If you do want to search in this direction, you could broaden your search to any way for libinput to acheive your goal as just about anything that could be acheived with a libinput config function could be done through your sway config. If you're a bit of a masochist, you could read through /usr/include/libinput.h for every function name starting with libinput_device_config_ as a candidate for a fix to this. But as I am a masochist, I've read this file several times, and I'm skeptical such an option exists.

EDIT: Although, Seth's suggestion gave me an idea - something totally different, but triggered by that suggestion. Try binding button2 to exec a command that clears the primary selection (edit2, this would be `wl-copy -pc`). Clearing the primary selection in a never-ending loops is ridiclous for a number of reasons (I can't beleive that's in our wiki) - but if you can clear the primary selection on button2-down events, then you'll be set. You'll still inadvertently paste the primary selection regularly, but there will not be anything there to paste.

EDIT 3: worst case, or as a temporary bandaid, you could do something like "solution 1" from the wiki. Your concerns with this is that they take up a terminal. There is no need for this, just background that "script" - you could even run it at startup from your sway config. But I'd also add a sleep command inside the loop. There's a trade off in the duration of sleep. With no sleep the script will be very efficient at clearing the primary selection, while also being very efficient at eating your CPU and starting a house-fire from the resulting heat. With a long sleep, the loop will have no real effect on CPU use, but could "miss" sometimes if you select something then immediately accidentally hit the middle button. I loathe this kind of trade off in code, as it almost always means the approach is just wrong in the first place. But from a pragmatic approach, a `sleep 1` would almost certainly satisfy your needs without impacting CPU use at all. You may be very happy with such an approach ... I'd feel so itchy and gross that I'd have to just modify the sway code to avoud having such an ugly loop running.

I believe the following would do in your sway config:

exec while :; do wl-copy -pc; sleep 1; done

But if not (I've not used sway in a bit so I'm not an expert in the caveates of the config syntax) the following certainly would work:

exec sh -c 'while :; do wl-copy -pc; sleep 1; done'

Last edited by Trilby (2023-10-23 23:53:22)

archlynovice · 2023-10-25 10:05:59

As someone whos Arch Linux journey has just begun, it's very motivation to get such high quality responses on my (newbie) thoughts. So, once again, very thank you! I don't want to further eat up your time, so I'll come straight to the point and add some loose thoughts afterwards.

As you said, even the improved Wiki script is just a duct tape solution. Personally, I rather adjust my behavior than rely on a faulty system. If I'd be out for a quick solution, this would 95% do the job. For most people that's fine I guess.

Whether Edit 3 works depends on what's happeing under the hood, doesn't it? Does the primary selection (1) gets filled when text is selected or (2) is called only until needed? I'd suspect the primary selection is only fetched on the press of middle click and pasted on release of the middle click. If so, a second might not be sufficient here..

As for Edit 1 and 2, I might try this out and come back to report. I've been in this direction before: wl-clipboard has an watch option and my idea was to make it a condition that everytime the content of the primary selection changes, it is cleared. But that would maybe end in an infinity loop again ...

Regarding diving deep into libinput, I think this is above my weight class. Maybe in the future. Generally I _am_ interested in a proper solution on this. Cheers!

Last edited by archlynovice (2023-10-25 10:06:48)

Trilby · 2023-10-25 12:34:44

archlynovice wrote:

I'd suspect the primary selection is only fetched on the press of middle click and pasted on release of the middle click. If so, a second might not be sufficient here..

No, the "clearing" of the selection would not need to be between the press and release. The primary selection is filled when you select text generally by highlighting with a mouse drag or double-clicking on a word. The exact mechanics actually depend on the client program in question, but these are the most common. This selected content is what is pasted when you middle click.

So long as the primary selection is cleared after the last time you highlighted / selected something and the next time you use the middle mouse button, you'd be fine. In fact, depending on your typical usage, I suspect the "sleep" in that loop could be quite long and still function well (e.g., many seconds to a minute). It feels like a bit of an ugly hack to me, but it could actually get the job done quiet well if needed.

progandy · 2023-10-25 13:29:05

The development version of sway (sway-git) seems to have a configuration option: https://github.com/swaywm/sway/commit/c … 5ff67e92c2

Edit: At least one person claims it does not work and uses wl-paste/wl-copy instead: https://github.com/swaywm/sway/issues/4 … 1379960816

Last edited by progandy (2023-10-25 13:35:16)

archlynovice · 2023-10-25 14:11:22

Trilby, thanks for clarifying

progandy, first off, it's good to know that this is being worked on. Whether it works in the dev version or not, it's a win that it is a concern of the devs. Thanks for the info!

Trilby · 2023-10-25 14:50:38

Cool - I somehow never used / learned about the "--watch" flag. Archlynovice, that would make the "script" approach much better using the command in progany's second link in your sway config (so that wl-copy watches for any changes and immediately clears the selection as an event-driven process rather than a loop).

llamas · 2024-07-28 21:46:15

I made an account just to say this.

I had a similar issue where, instead of middle mouse copying text, middle mouse pasted copied text. This grew to be very annoying.

Sway has something (at least now, when I'm writing this) called 'middle click emulation' that you can turn on with:

input <id> middle_emulation enabled

This replaced the default behavior of my middle click, thus fixing the issue entirely.

Last edited by llamas (2024-07-28 21:47:37)

archlynovice · 2024-07-29 20:22:34

I appreciate the courage! Nevertheless this does not work for me.

I had this thread in the back of my head for a long time. Since opening it, I got used to the timing of the key and thus the problem is less annoying - yet still existing.

I tried to get hold of the identifier via

swaymsg -t get_inputs

and added all of the following (because I don't know which is the right one):

X:X:AT_Translated_Set_2_keyboard
XXXX:XXXXXX:ThinkPad_Extra_Buttons
X:XX:2_IBM_Trackpoint

We're most probably on different models, but maybe you can share what identifier worked for you. Although I have to say that I'm a little out of the loop about this topic, so I might have overseen something crucial.

Last edited by archlynovice (2024-07-29 20:26:13)

Arch Linux

#1 2023-10-22 18:15:48

Disable primary selection via middle click (wayland, sway)

#2 2023-10-22 21:25:19

Re: Disable primary selection via middle click (wayland, sway)

#3 2023-10-23 06:57:21

Re: Disable primary selection via middle click (wayland, sway)

#4 2023-10-23 12:24:57

Re: Disable primary selection via middle click (wayland, sway)

#5 2023-10-23 13:40:14

Re: Disable primary selection via middle click (wayland, sway)

#6 2023-10-23 22:53:00

Re: Disable primary selection via middle click (wayland, sway)

#7 2023-10-23 23:38:03

Re: Disable primary selection via middle click (wayland, sway)

#8 2023-10-25 10:05:59

Re: Disable primary selection via middle click (wayland, sway)

#9 2023-10-25 12:34:44

Re: Disable primary selection via middle click (wayland, sway)

#10 2023-10-25 13:29:05

Re: Disable primary selection via middle click (wayland, sway)

#11 2023-10-25 14:11:22

Re: Disable primary selection via middle click (wayland, sway)

#12 2023-10-25 14:50:38

Re: Disable primary selection via middle click (wayland, sway)

#13 2024-07-28 21:46:15

Re: Disable primary selection via middle click (wayland, sway)

#14 2024-07-29 20:22:34

Re: Disable primary selection via middle click (wayland, sway)

Board footer