changing severity since this bug, although technically an enhancement,
prevents use of screen-lock when assistive technologies are in use.

This bug differs from 99505 only in that it concerns the availability
of the onscreen pixels to a magnifying client, as opposed to the other
issues in 99505.

I do not think that "new techniques and new communication mechanisms"
are required for a fix, though these may of course be considered.  You
can safely ignore the reference to "RAM-based frame buffer" above;
xscreensaver and other clients don't know this (Peter is referring to
the fact that when fullscreen magnification is in use, the XScreen to
which the lock dialog is posted is likely to reside in a "virtual"
frame buffer rather than a framebuffer which is connected to a
physical display).  The problem is the same if two physical
framebuffers are present, and only the 'magnified' framebuffer is
connected to a physical display: the end result is that the user
cannot see the lock dialog since the physical display only shows the
"magnifier window".  The contents of this magnifier window is obtained
by getting the X pixmap from the 'target' display, which is locked.

[Thoughts on what is likely to be a thorny issue:]

One possibility: I don't know offhand if "Lock Screen" locks all
current screens, but it seems to me that it should.  In that case, at
least it could pop up its dialog on all screens, not just the one that
received the triggering event for popup (mouse or keyboard event).

The above behavior would need to be configurable since it would
conflict with the magnifier if and when the dialog's content was
available to the magnifier.  It would also mean that an 'unmagnified'
popup appeared on the target (magnified) display, which is
inappropriate but still an improvement over the current situation in
which _nothing_ appears on the target display.

Since screen lock hides all the important content on the source
display, there's no security reason for keeping it from the magnifier.
 I suspect that the server is being grabbed, which may be overkill -
it means that the screen, when locked, is more secure than when it's
in normal use by an end-user.  Is that critically important?

i.e. removing the server lock, and just locking the I/O and obscuring
the screen contents with an overlapping window, would afford security
equal to the case where the screen is in 'normal' use.  The only issue
likely to arise is that when an end-user is logged in, certain kinds
of attacks would be 'visible' to a "manned" terminal, whereas they
might go undetected if the X terminal were "unmanned".

Re: Bill's "one possibility" above - I think it is a very bad idea to
set this precedent.  I believe it is a very important rule that the
magnifier process should be the *only* process rendering to the
magnified (i.e. physical) display in normal use of the system.  Any
other policy is asking for trouble.

Until we have a mechanism for determining which screens are "owned by
GNOME", I don't think this is a bad precedent (or rather, I don't
think it would really constitute a precedent at all), so I guess I
disagree with Peter here. Note also that if screen-lock locks all
screens, it will obscure the magnifier too.

BTW, all these issues were raised long ago when we started talking
about xscreensaver accessibility impact...

THis is a dependency of 99505.

actually, it's really a duplicate (unless there is significant value
in separately tracking the server grab and window-posting issues).  I
am unconvinced that they need to be tracked separately yet as there is
no obvious progress on the bugs in bug reports.

*** This bug has been marked as a duplicate of 99505 ***