Regression: rev 3862 causes no scrolling on an unfocused gtk3 window with usb mouse

possibly a result of this bug fixed?
https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1311303

Nah, wasn't commit 3864

Was revision 3862 that breaks here

Geez, why does this have to be so hard to fix this Gtk scrolling, yet, not break every other possible wheel mouse binding someone may do in some Compiz plugin?????

Thanks for the report and narrowing down the commit. I'll take a look.

Hmm, I'm thinking something has changed in Gtk for Utopic that breaks this fix. My reasoning is that the next pending Compiz SRU for 14.04 has this fix in it and unfocused scrolling works.

I'll get a Utopic system up and running and see what happens there.

Well, it works with my laptop and USB mouse on Utopic, so I guess it's not Gtk. Maybe different USB mice use different masks in X????

I'll have to think about this and do some research.

@Doug,

Do you have any other Compiz functions bound to your scroll wheel? I've tried three different USB mice on this machine and they all work, so I'm wondering if it's some functionality tripping this up.

Is there a build up for 14.04 that includes this? (ie. the pending SRU) that I can try?
Asking because I did previously try .9.11+14.10.20140606-0ubuntu1 source in trusty & there was no scrolling in an unfocused gtk3 window with the usb mouse (- touchpad did work if I enabled

Mouse here is logitech as in screen & also see the same with a corded logitech usb mouse (no idea how to produce info on..

(Ot maybe -
Does your usb mouse/laptop see this bug?
https://bugs.launchpad.net/ubuntu/+source/unity-settings-daemon/+bug/1283863

Yes - the typical for desktop-based viewport switching, 5 (next) & 4 (prev
Though if I disable the bindings scrolling still fails on unfocused

Maybe it's 1 corner case (the bug fix) to another (my hardware lenovo Y510P?

@Doug,

The pending Compiz SRU packages can be found in ppa:ci-train-ppa-service/landing-010. 2 of the 3 mice I've tried are Logitechs as well. Not really sure what's going here unless you have some scroll wheel binding that I'm unaware of.

Regarding the touchpad re-activation, it works in the greeter, but then doesn't work after log in. I even moved the cursor around and clicked on things in the greeter.

When I get home tonight I'll try the SRU in a new 14.04 install or live session

If you don't see the re-enabling from 'touchpad -disabled' on reboot then there may be some hardware diffs that can affect usb mice, ect.
The greeter always has touchpad -enabled but on this laptop & my prior lenovo (y580p), the user setting of touchpad -disabled is/was always reset to -enabled on reboot/login
(- well, sorta, - that bug migrated from reset at some point during the course of a day or 2 to the current always reset on fresh boot/login

Ok, then this is probably hardware specific. I had to trial and error to find that the Mod2Mask is the correct keymask bit to set to keep things in check, but it seems there are corner cases like yours.

Honestly, I don't know of an easy way to figure this is than to just recompile Compiz and change that line in the revision you point out changing the keymask bit to one of these:
ShiftMask, LockMask, ControlMask, Mod1Mask, Mod2Mask, Mod3Mask, Mod4Mask, and Mod5Mask or an inclusive OR of those masks

If you have any ideas on which one(s) *may* work I'll rebuild here & test.
Or possibly leave as is & see what shakes out when the SRU releases.
From my singular perspective I can revert or edit the change for myself, maybe there are only a few who will be affected

(- I never really looked at the bug this particular commit was fixing which I guess any new change would have to consider., no sense fixing a if it breaks b, then fixing b & hope to not break a, ect., ect.

I really don't have any idea which masks to try. What this fix is trying to do is allow bindings of the scroll wheel + modifier for users who want to use something like Alt+scroll up/down to raise/lower windows, so I need to keep some modifiers with the scroll wheel grabbed for this.

It's not clear what the ModXMask masks really bind to. This just seems like really fragile code that I'm forced to muck with because Gtk developers wanted to fix another issue and left window managers holding the bag.

I'll keep looking at this. Maybe I can add some of the ModXMasks to the exclusive OR and not break things.

As best I can see -
Using 0.9.11+14.10.20140606-0ubuntu2 with rev 3862 reverted on 14.04 & 14.10
Totally unaffected by what's mentioned in the other bug report, both the current SRU test case & the orig. description.
(with either the wireless mouse or wired one (- Logitech USB-PS/2 Optical Mouse

I can:
lower windows with alt+button6
scroll on Desktop with alt+buttons5/4
scroll unfocused

At the end of the day if a total fix isn't possible & my type hardware is odd man out no big deal, I'll ppa it for users likewise affected..

Plus - Those affected like myself can scroll unfocused with the touchpad Or scroll unfocused with cursor on scrollbar thumb.
(so there are alternatives when using current 0.9.11+14.10.20140606-0ubuntu2

Hi Doug,

I think I figured out the problem. It seems Mod2Mask maps to NumLock. If I have NumLock turned on on my keyboard, then unfocused scrolling doesn't work. Do you have NumLock turned on and if so, could you try turning it off and see if it begins to work? If you don't have it turned on, then well, uh, not sure what's going on with your machine.

Thanks!

That seems to be the issue though on this lenovo seems to be opposite...
So if I hit numlock key - the light on case comes on, then scrolling in unfocused works. If I then hit numlock again - the light goes off, no scrolling

I guess this means numlock on - scroll works, numlock off - no scrolling.

The default here on a fresh install would be light off (numlock off

  Thanks for confirming! Sorry, you're right, I had it backwards. NumLock on, scrolling works.

So now the questions are (not asking you, just putting these thoughts somewhere):

1. Why do Gtk apps care about having NumLock ungrabbed?
2. Why does ungrabbing any other modifier in conjunction with NumLock not allow unfocused scrolling?
3. When NumLock is ungrabbed, why does turning off NumLock not allow unfocused scrolling?
4. Why does ungrabbing buttons with AnyModifier work for scrolling regardless? This should be similar to point 2 above, but it works - it just breaks using a modifier with the vertical scroll wheel.

I'm pretty sure we've identified a proper fix that should make everyone happy. We'll work on getting that into Utopic. I'll have to pull rev. 3862 out of the pending Trusty SRU and work on getting this in the next SRU.

Great - though I guess I should mention, though probably elsewhere..

Concerning this pending 14.04 compiz SRU, - *if* there is a unity SRU the same as the current in 14.10 (7.2.0+14.10.20140607-0ubuntu1, then it will expose this bug in 14.04 which I can reproduce easily, at least with nautilus
(- seems odd that trusty in 14.10 is lower versioned

https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1327624

This bug was fixed in the package compiz - 1:0.9.11+14.10.20140707-0ubuntu1

---------------
compiz (1:0.9.11+14.10.20140707-0ubuntu1) utopic; urgency=low

  [ Chris Townsend ]
  * Release version 0.9.11
  * Bump VERSION to 0.9.12
  * Add more button ungrab keymasks, so unfocused Gtk window scrolling
    will work when NumLock is off and CapsLock is on and any combination
    thereof. (LP: #1330198)
  * Remove the need to check the viewport we are painting the maximized
    window in while in Expo mode and only scale maximized windows that
    are not being dragged. Fixes a regression caused in r3868. (LP:
    #1333277)

  [ Alberts Muktupāvels ]
  * This is some preparation work to port gtk-window-decorator to gtk+-
    3.0. Changed gtk_object_destroy to gtk_widget_destory. Removed
    support for old metacity versions. Removed support for old wnck
    versions. .
 -- Ubuntu daily release <email address hidden> Mon, 07 Jul 2014 11:42:19 +0000