Bug 86513

Summary: vlocking console session causes X mouse-pointer to vanish
Product: [Retired] Red Hat Linux Reporter: ivan
Component: XFree86Assignee: Mike A. Harris <mharris>
Status: CLOSED NOTABUG QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: high    
Version: 9Keywords: MoveUpstream
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-04-28 09:26:09 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description ivan 2003-03-24 23:29:13 UTC
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-06 02:05:53 UTC
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 11:51:44 UTC
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 13:13:12 UTC
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 14:59:49 UTC
Please update this report to indicate wether you plan on reporting this
upstream or not.

Comment 5 Mike A. Harris 2003-04-28 09:26:09 UTC
Closing bug report as NOTABUG