Bug 68602

Summary: import gives bad results if X session being hit isn't current VT
Product: [Retired] Red Hat Public Beta Reporter: James Manning <jmm>
Component: XFree86Assignee: Mike A. Harris <mharris>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: limbo   
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: 2002-07-13 22:54:12 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:
Bug Depends On:    
Bug Blocks: 67218    
Attachments:
Description Flags
sshot attempt of a fresh X
none
attempted shot of kde starting up
none
sshot of :0 when it wasn't the currently selected vt
none
XFree86.0.log - hopefully helpful if this is specific to the driver none

Description James Manning 2002-07-11 16:22:26 UTC 
Description of Problem:
see bug #68601 - basically attempting to import -window root on a fresh X gives
weird results

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

How Reproducible:
100%

Steps to Reproduce:
1. X :2 (or whatever's not taken)
2. import -display :2 -window root /tmp/sshot.png
3. kview /tmp/sshot.png (or whatever viewer)

Actual Results:
bizarre - i'll attach my sshot attempt results, although bug 68601 has it too

Expected Results:
an sshot that shows the black X cursor, gray background, etc.

Additional Information:
I'd guess it's because X hasn't really displayed anything yet, so what get
sshot'd it just the pattern that X inititialized the double-buffering location
(not in video ram I'd imagine) to - not sure though
Comment 1 James Manning 2002-07-11 16:24:10 UTC 
Created attachment 64826 [details]
sshot attempt of a fresh X
Comment 2 James Manning 2002-07-11 20:41:35 UTC 
actually, it looks like it's not just limited to that case - I just tried to
sshot KDE starting up just after I logged in to kdm and the results are just as
bad - attempted sshot to come
Comment 3 James Manning 2002-07-11 20:42:27 UTC 
Created attachment 64984 [details]
attempted shot of kde starting up
Comment 4 James Manning 2002-07-12 15:25:14 UTC 
ok, playing around some more, what looks to be the problem is that if the import
runs when the X server being import'd isn't the currently selected vt, then you
get the garbage sshot's.  Since import does the same in both cases, I'm more
likely to believe this is XF86's issue to deal with, so I'll change the assignment.

Mike - lemme know what I can do to debug this further
Comment 5 James Manning 2002-07-12 15:26:01 UTC 
changing summary to better reflect the bug
Comment 6 James Manning 2002-07-12 15:27:39 UTC 
Created attachment 65144 [details]
sshot of :0 when it wasn't the currently selected vt
Comment 7 James Manning 2002-07-13 22:54:08 UTC 
Created attachment 65267 [details]
XFree86.0.log - hopefully helpful if this is specific to the driver
Comment 8 Mike A. Harris 2002-07-23 09:55:22 UTC 
Multiple concurrant X servers do not simultaneously "share" the video
hardware.  They use it one at a time.  When you VTswitch out of one X
server, it completely restores the video card to it's state prior
to entering X, and switching to the other X server restores the video
state that that X server set up.

I'm not exactly sure I'd call this a bug.  However if it is in fact
a bug, there isn't anything I/we can do about it, as I have no Savage
video hardware or documentation, so any fixes will have to come
from the upstream XFree86 Savage video driver maintainer.  I recommend
discussing this on xpert list to get a concensus of the
issue first, then contact Tim Roberts if it turns out to be considered
a bug.

Feel free to update this report with your findings, and if a patch or
fix results, I'll try to include it if possible.