Sure, we can add a --ignore-buttons 1,4,5 kind of option which simply defaults to 4+5. Do you want to create a PR?

I could but probably won't have time to anytime soon. Do you mean that the argument would be optional and would default to 4,5? Also, what would be the interaction between --ignore-scrolling and --ignore-buttons? Would --ignore-scrolling --ignore-buttons 1 be the same as --ignore-buttons 1,4,5?

I could but probably won't have time to anytime soon.

I'm not in a rush. :-)

Do you mean that […]

I forgot about --ignore-scrolling. I think --ignore-buttons should default to nothing, and if --ignore-scrolling is set it just adds 4 and 5 to the list (meaning 4 and 5 can be set to be ignored in two different ways, that's fine).

@chelovechishko Thanks! This works for me for buttons 1-5, but it doesn't work for buttons on my trackpad that I've changed to be buttons 50 and 51.

@noctuid Those are some high numbers… :-) Does xdotool click 50 even work? For me this already generates a BadValue error. Also, does it work with a button between 6–10?

It looks like it just ignores my changes (e.g. using xinupt --set-button-map) entirely. I just randomly picked a higher button number since I have some devices with extra buttons. Higher buttons numbers work fine with the hotkey daemon I'm using, and xev detects them correctly. It looks like the actual button number isn't the issue though. unclutter still considers my button as button 1 (even if I pick a different number under 10 for it).

Maybe in this case (trackpad) it's not a XI_RawButtonPress, but a XI_RawTouchUpdate?

They are physical buttons right above the actual trackpad. It's the trackpoint buttons on a thinkpad (labeled as "TPPS/2 IBM TrackPoint"). I have the same issue with the buttons below the trackpad.

(If i understand correctly, of course)
There are only

XI_RawMotion
XI_RawButtonPress
XI_RawTouchUpdate

which can change the state of cursor.
So, if it certainly (i hope) not a XI_RawButtonPress case (which we only check for hiding), there are only two possibilities left.
Or, there are just one another button pressed along.

It could be that the raw event doesn't consider this kind of mapping. Not sure what to do against that — we need to use raw events as button grabbing interferes with applications.

The same thing happens for external mice. It sounds like it's because the raw event is being used.

So first things first, could you please open a new issue for this so we can move the discussion there?

Secondly, would be great if you could check whether a raw event is sent at all and we just "filter it out" or whether there is no such event by adding some printf or something.