It's certainly no "regression" since you and your roommate run the same version.

I suppose this is
http://forum.kde.org/viewtopic.php?f=111&t=102161

If your and your roommates setups are exactly equal (notably including plasma -autohiding- panel positions and configured screen edges) the bad news is that your touchpad is broken. (simple ratio, if the same SW and drivers cause different results on differen HW, it's a HW problem)

If not
a) this will likely fall into the "conflictive electric borders" category
b) please elaborate on the differences between yours and your roommates setups in detail

Hi Thomas, this is the roommate here :)

Whoops, Jared forgot to mention: the reason it was marked as a regression is that the top-left corner activation worked just fine for Jared in Kubuntu 11.10 (KDE 4.7 series), and it wasn't until the upgrade to Kubuntu 12.04 that the problem appeared.  Neither of us have any additional KDE panels--only the one on the bottom, and none of us are using multiple screens.  We both use GLX-Dock and experienced this possibly-related bug: https://bugs.launchpad.net/cairo-dock-core/+bug/993612

I will check out your link with Jared when he gets back later.

I am pasting Thomas Lübking's e-mail message to me here for easier tracking of this bug:
---------------------------------------------
Hi Christian.

bugs.kde.org will have a short downtime

Meanwhile, does the issue remain if glx-dock is on another edge (or simply shut down)?

However, there's been a GSoC re-organization of the electric screen edges¹, so i'll better have a look what might have went wrong.

Regarding the touchpad, i guess it causes an enter event for every move, or sends a dnd client messsage (because the touch area is also used as mouse button, it *should* be possible to turn that behavior off (but frankly i just turn off the touchpad - that things drive me nuts ;)

The link in comment #1 seems to be the same problem I'm experiencing.  I tried the following to no avail:
 . Disabling GLX Dock
 . Switching from open source Radeon driver to fglrx driver
 . Booting a different kernel (3.4.0-4-generic)
 . touchpad tapping disabled

I can get the top-left corner to activate if I swipe at the touchpad like a madman, but it is very difficult to do (much harder than it used to be and much harder than the other corners).

(continued from comment #3) - I forgot to post the rest of Thomas' e-mail message.  Here it is:
--------------------------------------
Am 13.06.2012, 00:50 Uhr, schrieb S. Christian Collins <s_chriscollins@hotmail.com>:
> that the top-left corner activation worked just fine for Jared in Kubuntu 11.10
> (KDE 4.7 series), and it wasn't until the upgrade to Kubuntu 12.04 that the problem appeared.

Ah, ok - but that included updates of X11, the kernel, drivers, glx-dock ... =)
It might nevertheless be the refactoring mentioned above.

Cheers,
Thomas

[1] https://git.reviewboard.kde.org/r/101789/diff

*** Bug 301997 has been marked as a duplicate of this bug. ***

There seems to be an issue with either the generated timestamps or events of this device/driver combo - can any of you apply patches for testing?

I have limited experience, but I have applied patches to application sources before, but never anything to core KDE libs.  How would one go about doing this?  Is there a resource somewhere I could read?

Usually when I've applied patches in the past (for example, to Audacity), I simply remove the audacity package and then compile the source + make install.  I'm not sure how I would do the same with a patched KDE lib, due to the dependencies involved in removing the library package.

You'd actually not even have to remove sth. but install the kdelibs/kde-workspace-dev packages, fetch kde-workspace sources from git or a tarball and compile and install kwin (overriding your actual installation) after applying the patch.

re-installing the distro kde-workspace/kwin package will then simply revert the custom changes (at least for 4.8 there should be no issue but for 4.9 sources you might get dpkg errors later on because the "file is already in filesystem"

Great!  When there is a patch available, I will be happy to test it.

Created attachment 71873 [details]
patch that prints enter events alongside position and time

it's not the kind of "this fixes it" patch, but just a debug out so we can see whether the device produces an enter event and along what time stamp (while i'm really puzzled why it should hit the top/left edge - sounds as if the input device is off by one and stops at pixel 1 instead of 0)

also apply these patches:
https://git.reviewboard.kde.org/r/104420/
https://git.reviewboard.kde.org/r/105254/

(esp. the first one will allow us to check the no-pushback variant)

Does anybody encountering this issue NOT use ubuntu 12.04

See
https://answers.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+question/201072
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/1015183
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/1015183
and Xorg thread
http://lists.x.org/archives/xorg/2012-June/054739.html

Do we have an xev log for this and/or meawhile knowledge about the events on the electric borders (see attached patches)

I do encounter the bug and I am using debian sid/unstable with kde 4.8.3...

Hi Thomas.  Sorry I haven't had time to test the patch yet.  I'll try to get to it this week.

Thomas, I have successfully patched the KDE 4.8.4 sources, but I'm a bit lost trying to follow the build environment instructions.  Since the instructions at http://techbase.kde.org/Development/Tutorials/Building_An_Existing_Application didn't seem to match exactly what I was trying to do, I tried the following instead:
1) Created a "build" directory in ~/kde/src/kde-workspace-4.8.4/kwin/
2) From the build directory, ran the command "cmake -DCMAKE_INSTALL_PREFIX=/usr ..", which generates the following output:
--------------
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
CMake Warning at CMakeLists.txt:12 (if):
  given arguments:

    "STREQUAL" "Desktop"

  Unknown arguments specified


CMake Error at libkdecorations/CMakeLists.txt:10 (kde4_add_library):
  Unknown CMake command "kde4_add_library".


CMake Warning (dev) in CMakeLists.txt:
  No cmake_minimum_required command is present.  A line of code such as

    cmake_minimum_required(VERSION 2.8)

  should be added at the top of the file.  The version specified may be lower
  if you wish to support older CMake versions for this project.  For more
  information run "cmake --help-policy CMP0000".
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Configuring incomplete, errors occurred!
--------------------
I'm not sure what I'm supposed to do :\

Sorry for the delay.

a) stupid question ahead: are plasma autohiding panels affected by this as well?

b) this
CMake Error at libkdecorations/CMakeLists.txt:10 (kde4_add_library):
  Unknown CMake command "kde4_add_library".

is the error and this
> in ~/kde/src/kde-workspace-4.8.4/kwin/
is the reason.

While it's sufficient to only build kwin, it's required to run CMake on the entire kde-workspace (it adds macros such as the one which triggered the error)

So make a build dir in kde-workspace, run "cmake -DCMAKE_INSTALL_PREFIX=/usr .." there and "cd build/kwin; make && sudo make install"

That should do.

Plasma autohiding panels are not affected.  I have no trouble recalling them along the top or left edges.  Once I get this patched kwin installed (still trying to hunt down all of the dependencies), what do I do to get you the information you need from kwin?

Everything seems to build fine, but I need to know how to get you the logging info that you need from this patch.

If you have applied attached patch, just start kwin from konsole ("kwin --replace &", attempt to approach a non working screen edge and watch the output.

If you get no output there's no crossing event, ie. the cursor does not enter the border window (which triggers the actions)

In that case, xrun xwininfo, move the cursor to a screen edge and click to see what window is there beneath the cursor.

Otherwise please run "xev | grep state" and move the cursor into the detection field to watch the cursor state - anything that is NOT 0x10 is a bug  - esp. 0x110 means that the left mouse button is pressed.

After installing the patched kwin, I no longer have any window decorations or compositing, and I am unable to type anything.  I was able to reinstall the following packages from a virtual terminal to get my system working again:
kde-window-manager, kde-window-manager-common, libkwinactiveglesutils1 libkwinactiveglutils1 libkwinglesutils1 libkwinglutils1
Are there any other packages I should reinstall as well?  Unfortunately, I was unable to get any test results for you.

Means kwin didn't start / crashed.
Did you get a backtrace?

Wild guess: decoration.
In case you're using oxygen you'll probably also have to update kde-workspace/libs/oxygen (and with it the oxygen UI style in kde-workspace/kstyles/oxygen

Sorry, didn't think of that :-(

Alternatively you can use another deco for testing (laptop, skulpture, bespin should all be safe - QtCurve is binary incompatible and will not be loaded - falling back to oxygen then ...)

The error when running "kwin --replace &" is:
kwin: error while loading shared libraries: libkworkspace.so.4: cannot open shared object file: No such file or directory

Trying with the "Laptop" theme doesn't make any difference.  I've never tried compiling something this complex before, so I'm sorry if I'm missing something obvious.

That build "failed", no deco will do because library dependencies cannot be resolved (ie. libkworkspace and likely others are not in a known library path)

You can "strace kwin" to see what libs are attempted to be accessed. (but that's gonna generate *masses* of output)

If you want, build "make 2>&1 | tee my_make.log" and attach or mail me the log file (could be huge, better compress it then) because otherwise i can't possibly tell what failed here

Did you somehow compile kwin, then removed kde-workspace and then installed kwin? (that's not gonna work, it will still need the workspace libraries - you just don't have to compile them)

In very doubt, just compile and install entire workspace.

I found the problem.  I just had to create a symlink from /usr/lib/libkworkspace.so.4abi1 to /usr/lib/libkworkspace.so.4 and now I can get the kwin QPoint output.  Now I just need to wait for my roommate to get home from work so I can test it on his laptop (the one with the bug).

I have been able to run the tests on my roommate's laptop, and here is what I have discovered:

1) When an action is assigned to a screen corner, there seems to be an invisible pixel at that corner that triggers a QPoint event when hit by the cursor and then immediately pushes the cursor away from that pixel.  Using the top-left corner as an example, moving the cursor to position 0,0 will trigger a QPoint event, and then the cursor will be immediately forced to 1,1.  Therefore, "pushing" the cursor into the corner will continuously trigger QPoint events as the cursor is constantly moving to 0,0 and being forced back to 1,1.

2) When using the trackpad on Jared's laptop, when the cursor moves to 0,0, a QPoint event is triggered, but the cursor is *not* forced out to 1,1 and instead remains at 0,0.  Therefore, continuing the push the cursor into the corner does nothing.  By jiggling the cursor long enough in the corner, enough QPoint events can be generated to trigger the assigned screen edge event, which is why a "furious swiping" sometimes works.  This problem does not exist in the bottom-right corner.  Using a mouse, the cursor is properly kicked out to 1,1 in the top-left corner.

Here's a video I made showing the bug on Jared's laptop:
http://youtu.be/ctilD4DedkE

(In reply to comment #25)
> 1) When an action is assigned to a screen corner, there seems to be an
> invisible pixel at that corner that triggers a QPoint event when hit by the
> cursor
That is the input window used to trigger screenborder actions.

> and then immediately pushes the cursor away from that pixel.
PushBack* is (afaik and reasonably) used to detect the users will, ie. that s/he *wants* to enter that corner (ie. triggers events until the delay times out)

> 1,1.  Therefore, "pushing" the cursor into the corner will continuously
> trigger QPoint events as the cursor is constantly moving to 0,0 and being
> forced back to 1,1.
yes - until the BorderDelay times out.
 
> 2) When using the trackpad on Jared's laptop, when the cursor moves to 0,0,
> a QPoint event is triggered, but the cursor is *not* forced out to 1,1 and
> instead remains at 0,0.
That either means the pushback is disabled (unlikely) or we can't warp the cursor.

$ kreadconfig --file kwinrc --group Windows --key ElectricBorderPushbackPixels
If it prints nothing, it's default, ie. "1"
Try 
$ kwriteconfig --file kwinrc --group Windows --key ElectricBorderPushbackPixels 0
$ qdbus org.kde.kwin /KWin reconfigure

NOTICE: that this will cause ignorance of the activation delay setting and trigger actions immediately. 
(WARNING to others: It was also *vastly* broken in older versions of KWIn, but 4.8.x should be fine)

> Using a mouse, the cursor is properly kicked out to 1,1 in the top-left corner.
What suggests "driver issue" - it will likely either do some extra smart magic on the screen border or just be broken (about warping from 0,0 to 1,1) - you can also try to
$ kwriteconfig --file kwinrc --group Windows --key ElectricBorderPushbackPixels 3

"3" is a magic number (aka random guess) and if it works that means the touchpad driver for some reason prevent warping /to/ 1,1 - otherwise it means it prevents warping /from/ 0,0

Okay, I will test this when Jared gets back from his weekend trip.

Setting "ElectricBorderPushbackPixels" to 2 as in comment 27 fixed the issue for me:

kwriteconfig --file kwinrc --group Windows --key ElectricBorderPushbackPixels 2
qdbus org.kde.kwin /KWin reconfigure

Which is equivalent to adding the option:
ElectricBorderPushbackPixels=2
In the section [Windows]

Now I can use again the switch to left desktop on edje !!
Thanks to everyone !!

Using ElectricBorderPushbackPixels=2 fixed the issue on Jared's laptop as well.

Previously the top-left corner behavior was this:
    Mouse: cursor kicked out to 1,1
    Trackpad: cursor remains at 0,0

After setting ElectricBorderPushbackPixels to 2, the behavior is now:
    Mouse: cursor kicked out to 2,2
    Trackpad: cursor kicked out to 1,1

This works, but I wonder what could be causing the 1 pixel offset in the trackpad's cursor.  Again, the bottom-right corner responds correctly with either mouse or trackpad.

Created attachment 72836 [details]
Cursor warping test app

Ok, many thanks everyone for investigating so far.

Attached is a simple app that warps the cursor to different locations and checks for success.
Could somebody please check how it behaves with the synaptics touchpad (maybe try moving the pointer around while running it)?

I have the Synaptics touchpad ("SynPS/2 Synaptics TouchPad" according to Xorg.log, on a ThinkPad T520); the output of test test app shows a couple of mismatched lines:
cursor is now at QPoint(200,199) should be QPoint(200,200) 
cursor is now at QPoint(0,0) should be QPoint(0,0) 
cursor is now at QPoint(0,0) should be QPoint(1,1) 
cursor is now at QPoint(0,0) should NOT be QPoint(-1,-1) 
cursor is now at QPoint(0,0) should be QPoint(0,0) 
cursor is now at QPoint(1,1) should be QPoint(2,2) 

This is with ElectricBorderPushbackPixels=0, and without touching the touchpad while the test is running.

Thanks for testing - esp. the 200,199 are "strange"
Nevertheless, could you ensure there's no active screenborder in the upper left corner when running the test?

"kcmshell4 kwinscreenedges", also turn quick tiling and maximiziation off and set desktop switching to NO always enabled (ie. disabled or when dragging a window - doesn't matter)
Don't forget to "apply"

I have a SynPS/2 Synaptics TouchPad (got that from Xorg.log as stuart did).
This is what I get with no active screenborders, ElectricborderPushbackPixels=0, no tiling, no maximization, no desktop switching:

cursor is now at QPoint(199,200) should be QPoint(200,200) 
cursor is now at QPoint(0,0) should be QPoint(0,0) 
cursor is now at QPoint(0,0) should be QPoint(1,1) 
cursor is now at QPoint(0,0) should NOT be QPoint(-1,-1) 
cursor is now at QPoint(0,0) should be QPoint(0,0) 
cursor is now at QPoint(2,2) should be QPoint(2,2)

Oh, great - so (at least the version of) the synaptics driver takes XWarpPointer as "suggestion"....

Please file a bugreport against synaptics or ubuntu (anyone here using another distro?)

I am using arch at the moment, and I used it for the test above. I also experienced the same issue with debian sid. So probably the issue is not distro related.

(In reply to comment #36)
> I am using arch at the moment, and I used it for the test above. I also
> experienced the same issue with debian sid. So probably the issue is not
> distro related.

What version?
Ubuntu ships 1.5.99.902-0ubuntu5 while arch is currently at xf86-input-synaptics 1.6.2

(In reply to comment #35)
> Oh, great - so (at least the version of) the synaptics driver takes
> XWarpPointer as "suggestion"....
> 
> Please file a bugreport against synaptics or ubuntu (anyone here using
> another distro?)

I get the same result having disabled screen edge actions and also with desktop-edge switching disabled.

I'm using Fedora 17, with  xorg-x11-drv-synaptics 1.6.2 (64 bit).

(In reply to comment #37)
> (In reply to comment #36)
> > I am using arch at the moment, and I used it for the test above. I also
> > experienced the same issue with debian sid. So probably the issue is not
> > distro related.
> 
> What version?
> Ubuntu ships 1.5.99.902-0ubuntu5 while arch is currently at
> xf86-input-synaptics 1.6.2

Both arch and sid are x86_64 and they ship version 1.6.2-1 of the synaptics driver. So should we report directly to freedesktop bugzilla? And what can we report?

(In reply to comment #39)
> So should we report directly to freedesktop bugzilla?
Yes, unlikely a broken distro patch or backport in all distros.

> And what can we report?
Driver (xf86-input-synaptics), version (yours), on Hardware (yours) reacts incorrectly on XWarpPointer requests (ie. the pointer warps to a different than the requested position, 1,1 seems to be avoided)

Link this bug and the attached testcase and please make /one/ bugreport and everybody affected just sign it with "me to: hardware/driver version"

Filled a bug on freedesktop, i hope it is decent: https://bugs.freedesktop.org/post_bug.cgi

Wrong link... This is the correct one https://bugs.freedesktop.org/show_bug.cgi?id=53037

*** Bug 311558 has been marked as a duplicate of this bug. ***