How to prevent passthrough of mouse scroll bind to a client?

My goal is to create a set of binds involving the scroll wheel while preventing the scroll wheel action being passed to the client.

Longer explanation in order to avoid the XY Problem:
My goal is to have a bind accessible from anywhere (awful.mouse.append_global_mousebindings + awful.mouse.append_client_mousebindings) invoked via Mod4 + 4 (read: Super + Scroll Up) that will increase my system volume (invoke a function) while preventing the client under my mouse (if any) from knowing that I have used the scroll wheel.

Here's a list of solutions I've tried so far:
https://gist.github.com/adamnejm/41c43ff5ff16d84c242d93f33bb85d0f
(each file is a separate attempt with comments explaining the fix and describing the outcome)

The only other solution I can think of is to change the actual mouse scroll buttons to something else, whether in the firmware or via X11 configuration and possibly faking the scroll wheel inputs using a different set of binds, I would however really like to keep things simple and retain the default scroll wheel behavior.

If anybody has a solution to my problem or can point me in the right direction, I'd really appreciate that, thanks!

Edit: The solution from a recent post How to "not" pass input to the client? which links to wooparadog's answer regarding mousegrabber doesn't work for me on the default rc.lua on the latest AwesomeWM (commit 9ca7bb4 ~9 days old)

Posted Jul 9, 2022, 11:50 AM UTC · edited

46
ILuvKeyboards•

Not a solution to your passthrough issue, but i am using smart_borders with volume control on scroll wheel. This lets me change the volume on any client border. I just have to move the mouse to edge of the screen and scroll without having to press any other button.

The module also provides hot borders which lets you add custom actions like volume control on the corner of the screen in case you don't want to change your titlebar/border setup.

1
raven2cz•
1
AdamNejmOP•

I've seen the thread just after I posted it, but the solution given is the same one I came up with while trying to solve it for myself.

Unfortunately I don't know why it's not working on my system. It's a pretty minimal install and the only mouse configuration on my system I can think of is in
/etc/X11/xorg.conf.d/50-mouse-acceleration.conf:

Section "InputClass"
	Identifier "My Mouse"
	MatchIsPointer "yes"
	Option "AccelerationProfile" "-1"
	Option "AccelerationScheme" "none"
	Option "AccelSpeed" "-1"
EndSection
1
raven2cz•

So, I'm testing it with AW git version. And it works ok. It doesn't work for electron apps, but qt, gtk, firefox it works according to expectation.

This is my test:


client.connect_signal("request::default_mousebindings", function()
    awful.mouse.append_client_mousebindings({
        awful.button({}, 1, function (c)
            c:activate { context = "mouse_click" }
        end),
        awful.button({ modkey }, 1, function (c)
            c:activate { context = "mouse_click", action = "mouse_move"  }
        end),
        awful.button({ modkey }, 3, function (c)
            c:activate { context = "mouse_click", action = "mouse_resize"}
        end),
        awful.button({ modkey, altkey }, 4, function (c)
            c:emit_signal("request::activate", "mouse_click", {raise = true})
            mousegrabber.run(function (_mouse)
                os.execute(string.format("amixer -q set %s 5%%+", beautiful.volume.channel))
                beautiful.volume.update()
                return false
            end, 'mouse')
        end, nil),
        awful.button({ modkey, altkey }, 5, function (c)
            c:emit_signal("request::activate", "mouse_click", {raise = true})
            mousegrabber.run(function (_mouse)
                os.execute(string.format("amixer -q set %s 5%%-", beautiful.volume.channel))
                beautiful.volume.update()
                return false
            end, 'mouse')
        end, nil)
    })
end)

But I haven't any special configuration like you, just normal mouse.

2
AdamNejmOP•

My testing was inadequate, sorry for that.
I initially only checked VSCodium and Brave, now I tested it on Thunar (GTK) and it sort of works.

The behavior is still not quite right however and results in pretty much the same thing as my move_mouse.lua attempt.
Although hacky as fuck, my solution works for any client, no matter the UI framework.
It has the same problem though, the client may (and often does) still receive an initial scroll input.

Reproducing:

  1. Move mouse over an application that is affected by the solution.
  2. Scroll up or down (normally, not using the bind)
  3. Use the scroll bind
    Result: Client receives a single scroll input on the 3rd step. After that, it no longer receives scroll inputs.

Would you be so kind to perform the test above to see whether it affects your setup?

1
raven2cz•

no, initial scroll input is not sent to clients on my station. Works ok. Brave and VScode (electron apps) consumes events - this is still open topic.

2