Bug 290887

you have to throw your mouse at the corner of the virtual screen. So not at 
y=768 but at y=1200. Just try moving your mouse below the screen.

you can also configure the virtual screen to align on the bottom, ie. have the smaller screen reach from y=432 to y=1200

> you can also configure the virtual screen to align on the
> bottom, ie. have the smaller screen reach from y=432 to y=1200
which would obviously break the top corner...

(In reply to comment #3)
> which would obviously break the top corner...
...not being mentioned to be in use by OP ... ;-P

makes me wonder whether to simply extend the electric corners/borders to all "dead" space would cause other nasty issues...

@Kai-Uwe
you can also configure a virtual resolution of 1366x1200 for the notebook and make the entire space usable (the display will then always show a "fraction" of the screen around the pointer - can be annoying, though)

Concerning the virtual screen thing, that’s what I thought already and tried, but the it does not let the mouse cursor escape the visible screen area, i.e. I cannot reach the bottom left corner of the virtual screen.

On Saturday 07 January 2012 16:21:23 Kai Uwe Broulik wrote:
> Concerning the virtual screen thing, that’s what I thought
> already and tried, but the it does not let the mouse cursor escape the
> visible screen area, i.e. I cannot reach the bottom left corner of the
> virtual screen.
New features in X? Here this works, that means I can move the mouse into the 
"black area"

(In reply to comment #5)
> Concerning the virtual screen thing, that’s what I thought already and tried,
XRandr / TwinView setup or Xinerama?

Don’t know. Just went to System Settings → Display, and configured VGA1 to be 1600x1200 and "Right of LVDS1" and applied :)

changing to wishlist as not really a bug and currently intended behavior (corner is around the outer edge and not the individual screens.

I can confirm this on Kubuntu oneiric (whatever version this is) with KDE 4.8 (from kubuntu backports). 

I am using a Lenovo Laptop with Intel HD 3000  graphics, so no Twinview stuff. I have an LCD display with 1600x900 and an external monitor (VGA) with 1600x1200. I configured VGA1 to 1600x1200+0+0 and LVDS1 to 1600x900+1600+300, i.e. the VGA leftof the monitor, bottom edge aligned.

Bottom edge action works, top edge only works on TFT. I cannot move my mouse outside the visible area (which is a GOOD thing!), increasing the virtual size of the laptop monitor to match the external monitor is not a good solution for me. 

I like to use the bottom edge action, so I cannot simply use 'LeftOf' for the screen layout, due to this problem, since this aligns the top edge. (I reconnect my external monitor very frequently, and since the display configuration does not remember the layout (reconnecting an external monitor has quite a few bugs, thats another story), I have to setup the layout manually quite often).

I would be willing to look into the code and see if I can write a patch for this (I also like to look at the screen corner actions, they are way to fiddly (works every third time at best)), any hints on where to start looking would be appreciated.

it's probably some xrandr --output --panning call which constrains the pointer (and breaks the virtual screen or xrandr can now do ths as well)

A patch that would just move the electric border (which would be required to be done 3 windows per screen) to "some" position in the virtual geometry doesn't fix it either, since that would make it pretty much uncatchable for everyone who's pointer does not stop at this position :-\

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

Not being able to throw the mouse out of the visible screen area is GOOD, and is a result of fixing this bug in Xorg 1.11: https://bugs.freedesktop.org/show_bug.cgi?id=20334
I'm in OpenSuse 12.1 with xorg 1.10, so I can't be sure...

"A patch that would just move the electric border (which would be required to be done 3 windows per screen) to "some" position in the virtual geometry doesn't fix it either, since that would make it pretty much uncatchable for everyone who's pointer does not stop at this position :-\"

This problem is still valid for who doesn't use the new Xorg version, but is the long-term solution, and also appears to be the current behavior of the "snap to edge" feature: not ideal, but I can live with it while waiting for the new Xorg.
Otherwise, would just adding a second "electric border" at the visible corner be too bad?

Some notes:
---------------
- The cursor is constrained with at least 1.11.4
- but ONLY for continuous crtc - ie. if there's a gap between the screens, the cursor is NOT constrained (what is correct behavior, otherwise one could not cross screens)
=> we'll require per-screen electric borders
=> we must catch the discontinuous case
    -> 2 windows for one electric borders seem a bad idea since ppl. will eventually trigger them passing by

I would say that the electric border should be exactly at that border over which the mouse cursor cannot go beyond.
- If your mouse cannot leave the visible screen, the electric border is around the visible screen.
- If your mouse can be between two monitors or be outside a monitor, then the electric border should be outside your visible screen.
- If you use panning, the electric border should be at the border of the virtual desktop, and so on..
This means that the electric border may not just be one simple rectangle, or one rectangle per screen.

However, I noticed quite a few bugs when it comes to changing the number attached displays or changing resolutions, so I get the impression that the actual desktop geometry, the mouse capture border, the electric border, and the KDE desktop geometry are four completely separate things, because I had "consistency" issues between all possible combinations of those depending on the current version of X, kernel and KDE during the last months. So I assume that accessing the current "mouse capture border" geometry correctly and completely is not simple to do in a robust manner.. Is this an X issue?

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

Same issue here: cannot access some hot corners with randr multi-monitor setup.
The ideal solution IMHO is to move the electric border area to the nearest visible corner.

I have a further issue, maybe a different bug (just upgraded to Kubuntu 12.10, happened before too, but then it was with twinview):

Laptop with external monitor, larger resolution, above. Laptop screen is configured so the bottom right corner is also the bottom right corner of the virtual screen.

- with no hot corner action -> nothing happens when the cursor is moved there
- with a hot corner action configured -> the action is not performed, but the cursor instantly jumps to where the corner of the screen would be if it was positioned at (0,0) which is somewhere in the external screen

The same cursor-jumping happens if I drive the external monitor with an identical resolution to the laptop screen and no matter if it's configured to be below or above.

(not opening a new bug, since I expect this to be resolved if this bug is dealt with)

One more datapoint: currently, the screen corner action only seems to work when the screen corner position is identical with the virtual corner position, for example bottom left corner with the external monitor left of the internal screen. In that case, there is still a jump of the cursor (to where the internal screens bottom left corner would be from (0,0)) but the action is actually triggered.

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

(In reply to comment #9)
> changing to wishlist as not really a bug and currently intended behavior
> (corner is around the outer edge and not the individual screens.

I really understand why it was developed the way it is. But I honestly don't think that the behavior is really *intended*. From a developer's point of view it makes sense to implement it the way it is at first sight.
But users recognizes the visible area on the plugged screens as the "workspace". So a hot corner of a workspace is obviously a corner of the visible area for users. Users don't care at all about any virtual bigger screen with dead areas and about rectangles as geometry. These are implementation details that shouldn't be visible for users. As these details are responsible for the current behavior, the feature seems to be broken for users.

After all, as the desktop environment is intended to be used by casual users, this is a bug than an inteded behavior.

For a correct behavior the electric border should match the border(s) of the total visible area of all plugged screens. Eventually this what a user of KDE would expect without any further knowledge.

I see the point that even users with a buggy Xorg version, where the cursor can leave the visible area, should be considered. But assume the electric border fits the border(s) of the total visible area: Shouldn't the action be triggered nevertheless, as soon as the cursor passes this border? So the action should be triggered independently from the fact if the cursor stops at this position or simply passes it?

(In reply to comment #20)
> (In reply to comment #9)
> > changing to wishlist as not really a bug and currently intended behavior
> I really understand why it was developed the way it is.
> [...]

At the time of that comment, the cursor was not restricted to the screen boundaries (ok, just started to become) and implementing it like it was would have had the side effect to prevent moving the mouse around freely to otherwise accessible areas - the behavior was entirely intended. The world changed (thus the state is probably no longer appropriate, but that's Martins take and has no deep impact on the treatment - a strong wish can be more important than a weak bug)

> I see the point that even users with a buggy Xorg version
To make that clear:
that has *not* been matter of a "bug" but the regular behavior for ages.

The screen corners however need a wide range rethought and rewrite (conflicts with other screen border actions like the panel extenders, demand of more/random function assignment)

for the record: rewriting screen edges is on my todo list for 4.11

(Subscribing, configming, cheering for progress.)

Git commit a4a947763e9316536a3dda5e38d2116f802aaaee by Martin Gräßlin.
Committed on 21/01/2013 at 09:04.
Pushed by graesslin into branch 'master'.

Rewrite of KWin's Screen Edge Handling

This rewrite is mostly motivated by the need to handle multi screen
setups correctly. That is have edges per screen and not for the combined
geometry. Also porting from XLib to XCB has been a motivation for the
rewrite.

The design of the new ScreenEdge handling is described in the
documentation of ScreenEdges in screenedge.h.

In addition the following changes have been performed:
* move configuration from Options to ScreenEdge
* add screen edge information to Workspace::supportInformation (obviously
  replaces what had been read from Options)
* have Workspace hold a pointer to ScreenEdges instead of an object
* forward declaration of ScreenEdges in workspaces.h, this explains the
  seemingly unrelated changes of just another include in some files
FIXED-IN: 4.11

M  +3    -0    kwin/effects.cpp
M  +5    -2    kwin/events.cpp
M  +10   -4    kwin/geometry.cpp
M  +4    -1    kwin/layers.cpp
M  +0    -114  kwin/options.cpp
M  +0    -100  kwin/options.h
M  +698  -342  kwin/screenedge.cpp
M  +383  -65   kwin/screenedge.h
M  +3    -0    kwin/scripting/scriptedeffect.cpp
M  +3    -0    kwin/scripting/scriptingutils.h
M  +24   -10   kwin/workspace.cpp
M  +3    -5    kwin/workspace.h

http://commits.kde.org/kde-workspace/a4a947763e9316536a3dda5e38d2116f802aaaee

Only partly working for me in 4.10.80: I assigned present windows to top right corner which works well on a single screen (now with fancy glowing indicator, woohoo). After connecting a larger screen as left screen, moving the mouse pointer to the top right corner of the original now right screen still shows the indicator but the effect is no longer triggered.

please create a new bug for this issue

Submitted issue #321259