On an FC5 box running 2.6.9-34.ELsmp with xorg 7.0.0/1.0.1 rpms, I'm having an issue getting output from an Xvfb session started with - Xvfb :2 -screen 0 640x480x16 -ac -shmem & xclock & Dumping root window to a file with the utility xwd or IM's import works. I can see the root window and the xclock window. I need to include this type of functionality in another program, so to start with i wrote a simple program (shm2xwd) that would grab the xwd format content from shmem which is "meant" to be written by Xvfb and output it to a file. In essence it does the following operations: ... shmptr = shmat( shmid, (void *)0, SHM_RDONLY ); /* attach to shmem */ int ctlrv = shmctl (shmid, IPC_STAT, &shmbuffer); /* get buffer info */ printf ("Buffer Size: %d\n", shmbuffer.shm_segsz); printf ("Buffer Attach Time: %s", ctime(&shmbuffer.shm_atime)); printf ("Buffer Change Time: %s", ctime(&shmbuffer.shm_ctime)); fd = open(argv[2], O_WRONLY | O_CREAT, mode); write (fd, shmptr, shmbuffer.shm_segsz); /* write framebuffer to file */ ... When i try and view file written by shm2xwd, all i see is an empty root window - I'm wondering if Xvfb is updating the shmem at all because looking at the output of this program: ./shm2xwd 3342352 x.xwd Buffer Size: 615328 Buffer Attach Time: Wed Sep 27 01:10:00 2006 Buffer Change Time: Tue Sep 26 17:27:25 2006 I see that the buffer change time was when i first started the Xvfb, but it hasn't been updated since - i.e. when i started/restarted xclock multiple times. I believe this is a bug.
I have confirmed this is still an issue with version 7.1/1.1.0 built from source. Using the switch -fbdir does not work correctly either. It writes the framebuffer directly to a file on initialisation but is not updated again.
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Is this still an issue?
Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please file a new report if you continue to experience issues with a current server.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.