Bug 972244 - Synergy client can't trigger GNOME 3.16 pressure barriers
Synergy client can't trigger GNOME 3.16 pressure barriers
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: synergy (Show other bugs)
22
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Christian Krause
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-07 19:46 EDT by Josh Stone
Modified: 2016-07-25 14:12 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-06-22 22:25:23 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch to disable overview barriers (588 bytes, patch)
2014-06-17 18:41 EDT, Eric Work
no flags Details | Diff

  None (edit)
Description Josh Stone 2013-06-07 19:46:06 EDT
Description of problem:
GNOME 3.8 changed the hot corner and edge for Activities and Messages to use "pressure sensitivity" before activating.  I believe this is some sort of mouse overshoot detection.  This works fine on my system with a direct mouse, but I can't get the pressured activation to work as a synergy client.

Version-Release number of selected component (if applicable):
client: synergy-1.4.10-1.fc19.x86_64
server: synergy 1.4.12 on Win7 x64
(nothing in the changelog from 1.4.10-12 looks relevant...)

How reproducible:
100%

Steps to Reproduce:
1. Quickly move the mouse to the top-left corner for Activities.
2. Quickly move the mouse to the bottom edge for the Message Tray.
   (Note, the pressure required is greater on this one.)

Actual results:
Nothing.

Expected results:
1. The Activities Overview is shown.
2. The Message Tray is revealed.
(and both do work with a local mouse)

Additional info:
This client is configured on the left side, server to the right.  I do have "switchCorners = none +top-right +bottom-right" and "switchCornerSize = 50", but removing that makes no difference.

It does work if I set "relativeMouseMoves = true", but only while the cursor is locked in the client.  Normally I leave it free to go between screens, so this setting is not a complete solution for me.

I'm guessing that swapping so GNOME is the server and Win7 the client might also fix it, but that won't fit the way I use my computers.

To see where GNOME is setting this, grep for PRESSURE in /usr/share/gnome-shell/js/ui/layout.js.  I don't see any configuration to disable this new pressure sensitivity (short of editing that file), but if there's a way that would probably be an ok workaround for me.
Comment 1 Josh Stone 2013-06-07 20:15:26 EDT
I just found that there are fallbacks to earlier GNOME behavior if !global.display.supports_extended_barriers() in layout.js and messageTray.js.  But mutter implements this function based on XIQueryVersion() >= 2.3, so I don't see a way to influence that.

Maybe the XI_Barrier* events could be generated by synergy somehow?
Comment 2 Jon Schwenn 2013-07-26 17:02:33 EDT
Having the same issue.  Trying to adjust 'hot corner threshold' with the Activities Configurator extension seems to have zero effect.  I think if there is a way to disable the pressure sensitivity completely it'd work out better.

It's making my workstation that I just upgraded to Fedora 19 harder to use.  I'd have to think that remote connections via VNC could also be affected.
Comment 3 Joshua 2013-12-19 14:21:07 EST
Workaround: Super + M brings up notification area on Gnome 3.8.4. Not sure about other versions. However, I agree that the actual issue needs to be resolved.
Comment 4 Josh Stone 2013-12-30 13:28:40 EST
Right, there's Super+M for messages and Super alone for activities, and both of those still work on GNOME 3.10 too.  Plus you can always click on Activities instead of relying on the hot corner, but these are just workarounds.
Comment 5 Eric Work 2014-01-30 14:03:08 EST
I tried adjusting the PRESSURE_THREHOLDs to 0 and even moving the barriers onto the screen.  With the local mouse this works.  I can active the message tray 5 pixels away from the edge of the screen with my hacks.  Despite doing this it still doesn't work with Synergy.  This leads me to believe that it's not based on mouse position but X server barrier events alone.  I don't know much about the barrier support in X11, but maybe there is a way to disable that so it will fallback to the older method?
Comment 6 Eric Work 2014-01-30 14:15:43 EST
Based on some insight from comment #1 I found a hack/workaround to get the activities hot corner to work.  If you change "!global.display.supports_extended_barriers()" to the constant "true" around line 1124 of /usr/share/gnome-shell/js/ui/layout.js it will bring back the old hot corner behavior which works with Synergy.  A cleaner way to do this would be an extension that would add the top-left and bottom-right hot corners back regardless of the XInput version.
Comment 7 Eric Work 2014-01-30 15:05:47 EST
I made an attempt to enable a hot corner on the message tray for the bottom-right corner but I don't know enough about how mutter works so it hung the shell.  Maybe someone else with more experience has an idea?
Comment 8 Eric Work 2014-01-30 15:23:16 EST
I found a workaround for the message tray as well using an extension called "Hi, Jack" from https://extensions.gnome.org/extension/645/hi-jack.  It basically sets up PointerWatch callbacks that use just the mouse position.  It could probably be adapted to handle the overview without needing the one line hack in layout.js.  Maybe someone with more expertise than myself could create a new "Synergy" extension that will work for both corners without the need to change system files.
Comment 9 Joshua 2014-01-31 08:52:01 EST
https://extensions.gnome.org/extension/637/move-free-message-tray/ returns behavior to pre-3.6. I haven't tried this yet as I'm at work, but I will tonight when I get home.
Comment 10 bugzilla 2014-06-17 18:27:08 EDT
Can you post what you changed?

(In reply to Eric Work from comment #6)
> Based on some insight from comment #1 I found a hack/workaround to get the
> activities hot corner to work.  If you change
> "!global.display.supports_extended_barriers()" to the constant "true" around
> line 1124 of /usr/share/gnome-shell/js/ui/layout.js it will bring back the
> old hot corner behavior which works with Synergy.  A cleaner way to do this
> would be an extension that would add the top-left and bottom-right hot
> corners back regardless of the XInput version.
Comment 11 Eric Work 2014-06-17 18:41:27 EDT
Created attachment 909797 [details]
Patch to disable overview barriers

The attached patch should disable barries and return hotcorner support for the top-left corner which opens the overview.

Based on gnome-shell-3.10.4-5.fc20.x86_64
Comment 12 Eric Work 2014-06-17 18:46:57 EDT
The patch attached in comment #11 and the hi-jack extension mentioned in comment #8 should allow synergy to work as before.  As I mentioned before a new extension based on hi-jack that could also change the overview barrier would be ideal, but I don't have the expertise or time to create such an extension.
Comment 13 bugzilla 2014-06-18 13:04:10 EDT
Thanks Eric!
Comment 14 Fedora End Of Life 2015-05-29 05:06:23 EDT
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 15 Josh Stone 2015-05-29 12:19:09 EDT
FWIW, while barriers still don't work with synergy on F22, it's less of a problem with notifications in the top panel.  There are clickable targets for both activities and messages now.
Comment 16 Eric Work 2015-06-12 17:58:12 EDT
I created an extension to "workaround" this issue.  If you install my GNOME extension from https://extensions.gnome.org/extension/963/disable-barrier-support it will override the check for barrier support and force it to false.  Then it simulates a monitor change to enable the old hot corner at the top left.  Until synergy supports barriers (my guess would be never), then the best thing to do is to just disable them.
Comment 17 Josh Stone 2015-06-15 12:42:52 EDT
Nicely done, Eric, thanks!
Comment 18 Eric Work 2015-06-22 22:25:23 EDT
I don't see us (Fedora users) being able to fix this and upstream from what I can tell doesn't seem to think barrier support is important.  Given that I've created an extension to workaround the problem I think it's time to finally close this bug.
Comment 19 Eric Work 2016-07-25 14:12:15 EDT
This bug is already closed, but I just wanted people following it to know that my extension still works on GNOME 3.20 and I've updated the extension page already with the new version.  I'm using the latest stable version of Synergy and it doesn't work still without this extension.

Note You need to log in before you can comment on or make changes to this bug.