This is a very general problem. When rdesktop is running in fullscreen mode, it
grabs the keyboard, just like any other sane fullscreen application.
xscreensaver wants to grab the keyboard to, but fails since another application
has already grabbed. 

So, this is not only a problem with rdesktop, but with many other apps as well.
As I understand it, *all* GTK apps that uses GTK:s built-in fullscreen code has
this problem as well. For example, "GQview" also has problems: I just tried
runnning it in fullscreen mode and locked the screen. In this case, I was unable
to unlock the display, because all keyboard input went to GQview. 

The whole X11/fullscreen story is a mess. There's a real need for a policy
document/HOWTO specifying exactly how fullscreen apps should work. Something for
freedesktop.org, perhaps?

Since I'm the maintainer for the keyboard stuff in rdesktop, I would be glad if
we could find a solution to this problem, but currently I have no idea of how it
should be done. 

hp: Ideas?

I don't know why you say that a "full screen program" must grab the
keyboard: that's completly untrue!  Grab the focus, perhaps, but not
the keyboard.  The only reason to grab  the keyboard is to ensure that
you get keyboard event when you *do not* have the focus!  If you have
focus, you're going to get the events anyway.  And if your window is
covering the screen, then you're going to have focus.

So there's no reason to do this grab, but the side effect is that
xscreensaver is incapable of grabbing when the time comes to lock the
screen.  Since xscreensaver is not receiving keyboard events, it can't
tell that the user is typing their password to unlock the screen.

There is no way to work around this in xscreensaver: rdesktop must be
fixed instead.   Please stop grabbing the keyboard for indefinite
periods.  It breaks everything.

GTK's fullscreen mode doesn't grab the keyboard... check again whether
you are doing it elsewhere.

People have said good things about how totem fullscreen works.

with rdesktop arguably it should take over the session in fullscreen
mode (you're essentially entering "windows mode" and can't escape),
when doing this it would behave just like xscreensaver's screen
locking I suppose. But then you need some way to keep the screensaver
from kicking in (this is needed anyway for e.g. slideshows)

You are correct: GTK's fullscreen mode doesn't grab the keyboard; it's
GQView that does. I wonder why. I also wonder if you know of any other
GTK application with fullscreen support that does not grab the
keyboard. I'm prepared to try removing the grab from rdesktop, but I'd
like to see an application working without the grab first. 

gqview just fixed that bug:

https://sourceforge.net/tracker/?func=detail&atid=104050&aid=910085&group_id=4050

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

rdesktop bugs upstream:

http://sourceforge.net/tracker/index.php?func=detail&aid=1006724&group_id=24366&atid=381347
http://sourceforge.net/tracker/index.php?func=detail&aid=968108&group_id=24366&atid=381347

rdesktop doesn't have to be full screen for this to occur.

I never run rdesktop full screen, and it happens to me frequently.

Could someone try with "rdesktop -K" and see if that helps matters?

I just tested with -K and it no longer captures the screensaver
passwords, however ALT+TAB, CTL+ALT+DELETE and other keystrokes no
longer work on the windows host even when rdesktop has focus, they
operating locally.

(twaugh: cc-ing you, the keyboard grab with fullscreen and the
xscreensaver lock dialog issue applies to vncviewer too)

Okay, so in the case of rdesktop and vncviewer they're grabbing the
keyboard for a fairly legitimate reason - you want key combinations
like Alt-Tab to go to the session on the server machine rather than
getting trapped by the local window manager.

Possibly we could work out some protocol with the window manager to
indicate that all global key grabs should be dropped for certain
fullscreen windows?

However, rdesktop differs from vncviewer in one specific way - it will
grab the keyboard (for the same reason) whenever the window has
*focus* and it grabs focus on EnterNotify.

I think it feels reasonably sensible if we only grab the keyboard when
the window is fullscreen. When you can see the window decorations and
the other windows I think it makes sense for the local window manager
keybindings to work as normal.

Attaching a patch which should make us only grab the keyboard with
fullscreen. I don't have the ability to easily test it - Dax could you
possibly test the patch?

Created attachment 104575 [details]
rdesktop-1.3.1-only-grab-keyboard-in-fullscreen.patch

Ah, issue is already known with vncviewer:

  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=106552

Mark, I don't think bug #106552 applies except when vncviewer is run
in full-screen -- so we're back to: how can you avoid this when in
full-screen mode?

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

Since I'm working both on rdesktop and VNC, I would be glad if we
could resolve these issues once and for all. Some comments:

jwz wrote:

>I don't know why you say that a "full screen program" must grab the
>keyboard: that's completly untrue!  Grab the focus, perhaps, but not
>the keyboard.  

If the application doesn't grab the keyboard, all WM shortcuts like
Alt-Tab, Alt-F4 etc will be active. This is not what users expect.
I've tried the "fixed" GQView (1.5.6), and it behaves exactly like
this. This is wrong, IMHO. 

With applications like vncviewer and rdesktop, the need for catching
WM keys like Alt-Tab etc is even greater. A "solution" which does not
make this possible is not a solution, IMHO. 

>There is no way to work around this in xscreensaver: rdesktop must be
>fixed instead.   

I don't think this is true. After all, "xlock" causes no problems!
Apparently it creates it's window and gives it focus *before* trying
to grab the keyboard. rdesktop releases the grab as soon as it loses
focus. 

Why cannot xscreensaver use this approach?

So, the policy should then be:

* Applications (for example, rdesktop) should be able to grab the
keyboard, as long as they have the focus. This applies to both
fullscreen and non-fullscreen mode. 

* If some application (like xscreensaver) wishes to "take over" the
grab, it should first take over the focus. 

Comments?

I don't know what your comment about xlock means.  First of all, xlock
only locks the screen when the user explicitly activates it, so
presumably in that case, they'd have to have moved the mouse of out
VNC or whatever to go to a unix shell and type "xlock" at it.  

Second, the xlock software is generally broken and ignorant of
security (xlock's brokenness is the reason that xscreensaver exists)
so arguments along the lines of "xlock does it, why don't you"
generally don't hold much weight with me unless accompanied by a
detailed analysis.

Third, and more to the point, a program like xscreensaver cannot
interact with focus, because it uses an override-redirect window.
O-R windows are invisible to the window manager, and cannot be focus
targets at all.  For an O-R window to receive input, it must grab the
keyboard and mouse; there's no other way.


So, VNC has two problems, that it is trying to solve by grabbing the
keyboard on EnterNotify:

   1: the window manager does not give it all keys (Alt-Tab, etc)
   2: the X server does not give it all keys (Alt-F1, C-Alt-BS, etc)

Like markmc said, I think that you should solve #1 with some new
WM-protocol.  This would be useful for many other programs too, for
example, games, and emacs.

I don't think that grabbing the keyboard solves #2 at all, because I
think those magic X server key sequences are not overridable (except
by globally turning on DontZap in the server config.)  I think that
without DontZap, Alt-F1 will always switch consoles and C-Alt-BS will
always kill the server, regardless of grabs.  It would be nice to have
a server extension to turn those on and off, and I've been asking for
one for years, but it doesn't exist yet (e.g., xscreensaver would like
to disable VT switching only while locked.)


Also, a question: why are you grabbing the keyboard in response to
EnterNotify instead of in response to FocusIn?  It seems to me that
this mixes up the "point to type" and "click to type" models, making
VNC always behave as a "point to type" app even when the user has
chosen to use a "click to type" window manager.

>I don't know what your comment about xlock means.  First of all, xlock
>only locks the screen when the user explicitly activates it, so
>presumably in that case, they'd have to have moved the mouse of out
>VNC or whatever to go to a unix shell and type "xlock" at it.

There's a program called "xautolock" that can activate xlock after
some idle time. For testing purposes, a "sleep 5; xlock" is also
sufficient. 

>Third, and more to the point, a program like xscreensaver cannot
>interact with focus, because it uses an override-redirect window.
>O-R windows are invisible to the window manager, and cannot be focus
>targets at all.  For an O-R window to receive input, it must grab the
>keyboard and mouse; there's no other way.

This is news to me. Where can I found information about this? Is it in
 the Xlib documentation? Do you mean that XSetInputFocus() will fail
for an O-R window?

>So, VNC has two problems, that it is trying to solve by grabbing the
>keyboard on EnterNotify:
>
>   1: the window manager does not give it all keys (Alt-Tab, etc)
>   2: the X server does not give it all keys (Alt-F1, C-Alt-BS, etc)

I don't think case 2 is much of a problem. Also, it has little to do
with the fullscreen and keyboard grab issues. So let's concentrate on
case 1. 

>Like markmc said, I think that you should solve #1 with some new
>WM-protocol.  This would be useful for many other programs too, for
>example, games, and emacs.

A new WM protocol would probably work, but this solution has lot's of
drawbacks: We need to define the protocol, all WMs would need to
implement it, and then all applications would need support. It would
take many years before things would start working. 

>Also, a question: why are you grabbing the keyboard in response to
>EnterNotify instead of in response to FocusIn? 

You mean in rdesktop? Don't know, I haven't written that part. 

> This is news to me. Where can I found information about this?

Inter Client Communication Manual section 4.1.10.
http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.10

    [...] the client can set override-redirect on the window.
    In general, this should be done only if the pointer is
    grabbed while the window is mapped. The window manager will
    never interfere with these windows, which should be used
    with caution.

    [...] The user will not be able to move, resize, restack,
    or transfer the input focus to override-redirect windows,
    since the window manager is not managing them.  If it is
    necessary for a client to receive keystrokes on an
    override-redirect window, either the client must grab the
    keyboard, or the client must have another top-level window
    that is not override-redirect and that has selected the
    Locally Active or Globally Active focus model.  The client
    may set the focus to the override-redirect window when the
    other window receives a WM_TAKE_FOCUS message or one of the
    events listed in section 4.1.7 in the description of the
    Globally Active focus model.

This says "you can only set (non-grabbed) focus to an
override-redirect window if there is some other (managed, non-O-R)
window that the window manager has already chosen to give focus to."  

Note that, even for *managed* windows, there's no guarantee that the
WM will obey any given client's XSetInputFocus request.  It's a
request, not an order.  For example, if a window manager has a strict
"point to type" policy, and some app that is not under the mouse asks
for focus, the WM may legitimately choose to ignore that, and leave
focus where the mouse is. 

When you try to set focus on a window, and it's a window that the WM
*does not manage* then it's even less likely to obey the request.  The
WM was never sent MapRequest events for the O-R windows, so it has no
internal record of those windows existing at all.  It is unable to
control when they are mapped, unmapped, and resized; it is unable to
decorate them with a title bar; and so it generally won't bother
trying to direct focus to them either.

See also 4.2.7, http://tronche.com/gui/x/icccm/sec-4.html#s-4.2.7

> A new WM protocol would probably work, but this solution has lot's
> of drawbacks

Yes, but it also has the advantage that it's the only possible
solution that will work, if you insist on receiving those keys.

Personally, I prefer the solution of, "you can't have those keys. 
Deal with it."  (Or the corollary, "if you want any app to have those
keys, then configure your window manager to not grab them in the first
place."  For example, since I'm an emacs user, I don't let my WM steal
Alt-Tab.)

> You mean in rdesktop? Don't know, I haven't written that part. 

Well, I think that behavior is probably wrong.  Perhaps you could get
whoever did make that decision to comment on their reasoning?

My short term suggestions would be:

  1) Don't grab the keyboard on EnterNotify, do it on FocusIn

  2) Only do this in fullscreen mode

Then start thinking about longer term ways to fix this properly.

>This says "you can only set (non-grabbed) focus to an
>override-redirect window if there is some other (managed, non-O-R)
>window that the window manager has already chosen to give focus to."

Well, "can" is relative. It's a well known fact that
override-redirect-type fullscreen violates ICCCM in any case. In
practice, you *can* use XSetInputFocus() on a O-R window. Many
fullscreen apps does this. This includes the TightVNC vncviewer. 

>Note that, even for *managed* windows, there's no guarantee that the
>WM will obey any given client's XSetInputFocus request.  It's a
>request, not an order.  For example, if a window manager has a strict
>"point to type" policy, and some app that is not under the mouse asks
>for focus, the WM may legitimately choose to ignore that, and leave
>focus where the mouse is.

You seem to think that the WM keeps the focus state. This is not true;
input focus is a server thing. The WM might try to "fight back",
though, but as far as I know, doing a XSetInputFocus(O-R-window)
guarantees that the active window recieves at least one FocusOut event. 


>> A new WM protocol would probably work, but this solution has lot's
>> of drawbacks
>
>Yes, but it also has the advantage that it's the only possible
>solution that will work, if you insist on receiving those keys.

Keyboard grabs works. The only piece missing is a policy for how one
fullscreen app should tell another that it should give up the grab.
Releasing the grab on FocusOut actually seems to work. I've written
some test code, and it seems to work great. The approach has several
advantages. For example, a screensaver-like program looks just like
any other fullscreen app. It's possible to start multiple fullscreen
apps: The last app started with get the grab, and when this app is
finished, the first fullscreen app will get the focus again (the
second app does XSetInputFocus to the first app on exit). 

There's only one problem with this approach: It breaks when you are
trying to mix fullscreen and ordinary windows. If an ordinary window
gets active and is then closed, the WM will revert the focus to some
other WM-managed window. Not the fullscreen O-R window. 

One way of handling this is to change the policy slightly: Never give
up the grab to a non-O-R window. This would make it impossible to mix,
but at least the user won't be stuck with a fullscreen app that
doesn't accept keyboard input. 

The problem above is one example of the inherit problems with
override-redirect toplevel windows. Wouldn't it be nice if we could
have fullscreen apps without using override-redirect?, I though. Then
I discovered _NET_WM_STATE_FULLSCREEN. Using it in combination with
grabbing the keyboard (for those who need/want), but only when the app
has focus, should solve our problem. 

Or can anyone find a reason why this would *not* work?

Again, it would be really nice with a Fullscreen HOWTO...

Red Hat apologizes that these issues have not been resolved yet. We do want to
make sure that no important bugs slip through the cracks.

Red Hat Linux 7.3 and Red Hat Linux 9 are no longer supported by Red Hat, Inc.
They are maintained by the Fedora Legacy project (http://www.fedoralegacy.org/)
for security updates only. If this is a security issue, please reassign to the
'Fedora Legacy' product in bugzilla. Please note that Legacy security update
support for these products will stop on December 31st, 2006.

If this is not a security issue, please check if this issue is still present
in a current Fedora Core release. If so, please change the product and version
to match, and check the box indicating that the requested information has been
provided.

If you are currently still running Red Hat Linux 7.3 or 9, please note that
Fedora Legacy security update support for these products will stop on December
31st, 2006. You are strongly advised to upgrade to a current Fedora Core release
or Red Hat Enterprise Linux or comparable. Some information on which option may
be right for you is available at http://www.redhat.com/rhel/migrate/redhatlinux/.

Any bug still open against Red Hat Linux 7.3 or 9 at the end of 2006 will be
closed 'CANTFIX'. Again, if this bug still exists in a current release, or is a
security issue, please change the product as necessary. We thank you for your
help, and apologize again that we haven't handled these issues to this point.

I don't know what NEEDINFO_REPORTER means, but as far as I know, the problem
exists in all later versions of rdesktop, including the 1.5.0 beta, so probably,
this bug should be kept open and moved to FC5/FC6. 

Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.

If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp