Bug 56255 - Dual-head causes keyboard focus problems
Summary: Dual-head causes keyboard focus problems
Status: RESOLVED WORKSFORME
Alias: None
Product: kde
Classification: I don't know
Component: dualhead (show other bugs)
Version: unspecified
Platform: RedHat Enterprise Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Stephan Kulow
URL:
Keywords: investigated, triaged
: 103338 126777 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-03-22 23:22 UTC by Paul Vincent Craven
Modified: 2018-10-21 05:23 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Vincent Craven 2003-03-22 23:22:09 UTC
Version:            (using KDE KDE 3.1)
Installed from:    RedHat RPMs

I've got a dual-head system using a radeon 8500 and drivers from ATI. (Apologies in advance if this is a driver problem.)

To reproduce,
Work in a window on the left monitor. I used konsole.
Click on a window in the right monitor. Like mozilla.
Note that you have a blinking cursor, saying you are ready to type.
Start typing.
Notice the keystrokes going to the konsole app that does not have focus.

To work around, click the title bar of another window on the right monitor. Then click back to the window that you want to have focus in the right monitor.

My left monitor always gets the focus correctly. Just not the right monitor.
Comment 1 Lubos Lunak 2003-04-10 17:25:56 UTC
Strange. For dualhead, there are simply two instances of KWin running.  
Comment 2 Stephan Kulow 2003-05-19 10:50:35 UTC
so you use click to focus? it works here. I need a windows with focus to type on the 
right monitor, but when I click on a window, I get focus 
Comment 3 nemosoft 2005-06-08 16:32:56 UTC
Just installed SuSe 9.2 here, with KDE 3.3 installed and have similar, very weird problems.

Setup is a dual-head system but no xinerama or anything, just display :0.0 and display :0.1. X server is X.org 6.8.1 + nvidia driver (not 'nv', though that should not matter). 

The problem is that ANY time after a pop-up dialog appears and is dismissed (could be "File Open", "About" box, a warning...), the focus moves "somewhere". "Somewhere" being defined as "some window on that other display, but which does not get a focused look, and which may, or may not be the last window clicked on that display". 

Switching desktops using the keyboard shortcuts (Ctrl+F1, Ctrl+F2, etc) also produces very weird results. E.g. pressing Ctrl+F1 repeatedly will often (but not always) toggle between display :0.0 and :0.1. Sometimes it stays at the same display, sometimes it keeps toggling.

Needless to say, loosing focus after any kind of pop-up window is extremely annoying.
Comment 4 Andreas Kling 2006-08-18 19:56:49 UTC
*** Bug 126777 has been marked as a duplicate of this bug. ***
Comment 5 Andreas Kling 2006-08-19 13:46:06 UTC
*** Bug 103338 has been marked as a duplicate of this bug. ***
Comment 6 S. Tringali 2006-10-20 16:39:52 UTC
I see this, but it's a bit random.  If I dismiss a pop-up dialog on :0.1, then the focus usually reverts to the parent window.  But, about one time in five, it will instead push focus whatever used to be the foreground window on :0.0.

To repro, load up Open Office on the :0.1 display.  Press ^f or ^o and then ESC.  Keep repeating those two.  After a few times, OO will magically lose focus, as :0.0 takes the focus unasked.

It seems to be OK with Qt applications, so it may be a compatability issue.
Comment 7 John Schmitt 2007-01-17 03:04:22 UTC
This is really bad.  I'm using KDE 3.5.5 on Fedora Core 6.

If I use CONTROL+W to close a konqueror tab on :0.1, the focus will be moved to my gaim window on :0.0.  I'm trying to close a few tabs, so I press CONTROL+W again, and instead I end up closing conversations I have going on in gaim.  It's similar if I'm using ALT+F4 to close a window, but (I haven't test this exhaustively) using CONTROL+Q instead will leave the focus on :0.0 where I wanted it.
Comment 8 John Schmitt 2007-01-17 22:14:59 UTC
I just opened my kcontrol pannel from the KDE menu to change my proxy on DISPLAY=:0.1 and press ENTER as a shortcut for the OK button when I was done.  The focus immediately went to :0.0 where my Gaim window is open.  Doing the same thing but using the mouse to click on the OK button did not move the focus, but left it on the KDE Control Module dialog box that was still open.

This should be made higher priority because it is so very annoying and that I can accidentally lose conversations or close windows I don't know about if I press CONTROL+W twice in succession.
Comment 9 Mihail Milushev 2007-02-10 10:30:57 UTC
i have the same problem. i have my main display at :0.0 and my tv-out at :0.1, which i use only for watching movies (thus, usually there are no apps on :0.1 at all). about 1 in 15 times when i switch virtual desktops on :0.0, the focus jumps to :0.1 (no actual window focused, as there are no windows there). also, almost every time (perhaps 9 times out of 10) when i play video in mplayer on :0.0, when mplayer terminates (no matter if the video is over or i quit with 'q'), the focus would jump to :0.1.
Comment 10 John Schmitt 2008-03-28 00:44:28 UTC
This problem seems to have disappeared for me.  Should we close this bug?
Comment 11 S. Tringali 2008-04-24 20:34:32 UTC
No, this still keeps happening on 3.5.8.
Comment 12 FiNeX 2009-08-04 14:01:23 UTC
On a dual monitor setup with nvidia twinview I'm not able to reproduce this bug (KDE 4 trunk). 

Is this bug still reproducible for someone else?
Comment 13 S. Tringali 2009-12-03 16:43:25 UTC
Finex: the problem is old-school dual-head, not xinerama-style.  Isn't twinview a single display spanning two monitors, instead of two separate displays?  See  comment 3.

I've tried it a few times with KDE 4 when it was rolled out, and it did not work either, so I totally gave up and moved to GNOME.
Comment 14 Andrew Crouthamel 2018-09-20 03:04:18 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 15 Andrew Crouthamel 2018-10-21 05:23:38 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!