Bug 86513 - vlocking console session causes X mouse-pointer to vanish
vlocking console session causes X mouse-pointer to vanish
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
9
i386 Linux
high Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
: MoveUpstream
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-03-24 18:29 EST by ivan
Modified: 2007-03-27 00:01 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-04-28 05:26:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description ivan 2003-03-24 18:29:13 EST
Description of problem:
Starting from a text session (no X), I startup X and background it (so that I 
can go back and lock the session for security). When X has started, I go 
back to the text session and run vlock, and then switch back to X and continue.
Once the text session is vlock'd, the X mouse pointer vanishes. It returns 
if I un-vlock the text session.


Version-Release number of selected component (if applicable):


How reproducible:
Every time.

Steps to Reproduce:
1. Machine starts at init level3
2. login and: ssh-agent startx &
3. switch back to text login session (eg shift-alt-F1) and vlock session
4. when session vlock'd, switch back to X (alt-F7), and try moving mouse.
    
Actual results:
No mouse pointer

Expected results:
See mouse pointer move

Additional info:
If you switch back to the text session and unlock, then switch back to X, 
the mouse pointer is back.

This is RHL 8.1Beta3 (or is it 9Beta3 ;) on a Dell C200 laptop
Comment 1 Mike A. Harris 2003-04-05 21:05:53 EST
vlock is locking the mouse device, preventing the X server from using it
when you switch VTs.  What you are attempting to do is not really something
supported.  It may be able to hack up vlock to do what you wan't, but that's
something you'll have to research.

This isn't an XFree86 bug.
Comment 2 ivan 2003-04-06 07:51:44 EDT
Hrm - I know this definitely works OK when using RHL6.2 (what I'm writing 
this on, and XFree86-3.3.6), but I don't remember about the 7 series.

I'll try turning off GPM to see if that makes a difference.

The (obvious) problem is that, if you run up X (from command-line) and lock 
the screen for security, it is not secure as someone can "CTRL-ALT-F1", 
background your X session, and carry on logged in as you. This is the reason 
I do this.

I'm not sure where this "issue" lies (vlock or XFree86) but bearing in mind 
that it is security-related and used to work in a previous version of RHL, I 
would like to re-open the "bug".

Open to suggestions :)
Comment 3 Mike A. Harris 2003-04-06 09:13:12 EDT
If you really believe this is a bug in XFree86, please report it directly
to XFree86.org in their bugzilla as my official stance on this is that it
is not a bug in XFree86.  You can report it to them at:

    http://bugs.xfree86.org

I will leave this bug open for now until you have reported it upstream,
and an XFree86 developer has commented on it.  Please update this report
once you've done so, and provide a URL here to your upstream bug report
so I can track XFree86.org's official diagnosis.

Thanks.
Comment 4 Mike A. Harris 2003-04-08 10:59:49 EDT
Please update this report to indicate wether you plan on reporting this
upstream or not.
Comment 5 Mike A. Harris 2003-04-28 05:26:09 EDT
Closing bug report as NOTABUG

Note You need to log in before you can comment on or make changes to this bug.