Capturing server screen configured as follow, the screen capture occurs but the ratio captured is not 16:9, is that due to video card ?

Did :

cvt 1920 1080 60

xrandr --newmode "1920x1080_60.00"  173.00  1920 2048 2248 2576  1080 1083 1088 1120 -hsync +vsync

xrandr --addmode screen 1920x1080_60.00

xrandr --output screen --mode 1920x1080_60.00

Here is the output of hwinfo --framebuffer

02: None 00.0: 11001 VESA Framebuffer                           
  [Created at bios.459]
  Unique ID: rdCR.mCUP8WwEfLD
  Hardware Class: framebuffer
  Model: "Matrox MGA-G200"
  Vendor: "Matrox"
  Device: "MGA-G200"
  SubVendor: "Matrox Graphics Inc."
  Revision: "00"
  Memory Size: 16 MB
  Memory Range: 0x00000000-0x00ffffff (rw)
  Mode 0x0301: 640x480 (+640), 8 bits
  Mode 0x0310: 640x480 (+1280), 15 bits
  Mode 0x0311: 640x480 (+1280), 16 bits
  Mode 0x0312: 640x480 (+2560), 24 bits
  Mode 0x0300: 640x400 (+640), 8 bits
  Mode 0x0303: 800x600 (+800), 8 bits
  Mode 0x0313: 800x600 (+1600), 15 bits
  Mode 0x0314: 800x600 (+1600), 16 bits
  Mode 0x0315: 800x600 (+3200), 24 bits
  Mode 0x0305: 1024x768 (+1024), 8 bits
  Mode 0x0316: 1024x768 (+2048), 15 bits
  Mode 0x0317: 1024x768 (+2048), 16 bits
  Mode 0x0318: 1024x768 (+4096), 24 bits
  Mode 0x0307: 1280x1024 (+1280), 8 bits
  Mode 0x0319: 1280x1024 (+2560), 15 bits
  Mode 0x031a: 1280x1024 (+2560), 16 bits
  Mode 0x031b: 1280x1024 (+5120), 24 bits
  Mode 0x031c: 1600x1200 (+3200), 15 bits
  Mode 0x031d: 1600x1200 (+3200), 16 bits
  Mode 0x031e: 1600x1200 (+6400), 24 bits
  Config Status: cfg=new, avail=yes, need=no, active=unknown

xrandr output:

Screen 0: minimum 1 x 1, current 1920 x 1080, maximum 1920 x 1080
screen connected 1920x1080+0+0 0mm x 0mm
   1920x1080      0.00* 

ran Xvfb :0 -screen 0 1920x1080x24 &

to illustrate in red is the section that is supposed to be 1280px long (should not show black on right side ) and what is inside will display but not with the correct ratio

enter image description here


Xvfb is not a VESA frame buffer, but a virtual frame buffer X server.

man Xvfb says:


Xvfb is an X server that can run on machines with no display hardware and no physical input devices. It emulates a dumb framebuffer using virtual memory.

The primary use of this server was intended to be server testing. The fb code for any depth can be exercised with this server without the need for real hardware that supports the desired depths. The X community has found many other novel uses for Xvfb, including testing clients against unusual depths and screen configurations, doing batch processing with Xvfb as a background rendering engine, load testing, as an aid to porting the X server to a new platform, and providing an unobtrusive way to run applications that don't really need an X server but insist on having one anyway.

In other words, Xvfb does not use your video card at all, so your capture ratio issue cannot be caused by it.

Note that in your xrandr output, the physical size of the screen is listed as 0mm x 0mm. If an application uses this information to determine whether or not the pixels in the selected resolution are squares or elongated rectangles, these values may cause strange results. The application might fall back to a default ratio used on older hardware (perhaps 4:3?) or attempt to divide by zero and then do something completely strange.

In the comments, you mentioned that the purpose of all this is to capture a CSS animation. If it's because you cannot access the webserver hosting the animation directly on your workstation, but this server can, then there are other ways around that problem. (Another fine example of an XY problem.)

For example, you might use SSH's dynamic port forwarding:

1.) Make a SSH connection with dynamic port forwarding from your workstation to the server. You can freely choose the port number: I'll use 1234 in this example.

workstation$ ssh -D 1234 direxit@server

This will make your SSH client create a SOCKS proxy whose inbound side is in the specified port on your workstation, and the outbound side is at the other end of the SSH connection, on the server.

2.) Back on your workstation, configure your browser to use a SOCKS proxy located on localhost, in the port number you chose in the previous step. This will make all outgoing connections go first through the SSH connection to the server, and from there to their actual destinations.

3.) If using Firefox, go to about:config and set network.proxy.socks_remote_dns to true, so that DNS resolution will happen through the SOCKS proxy too. For other browsers, you might have to add the site's IP address and hostname to the hosts file of your workstation if it isn't directly resolvable on your workstation.

4.) Now you can do your capturing directly on the workstation, with the browser running fully local (so minimal display lag) but the browser's network connections routed through the remote server (so the system hosting the CSS animation will see your browser's connection as coming from the server).

5.) Once you're done, remember to remove the SOCKS proxy configuration settings from your browser, or the browser won't be able to connect to anything at all once the SSH connection with the dynamic forwarding is terminated.

  • ok great wasn't sure about video card, so yes physical screen size is zero because there is no screen connected, is there a way to force that value with a size in millimiters that mimics a 16:9 display ? @telcoM – direxit Feb 10 '19 at 9:36
  • No, the physical screen size is zero because Xvfb will never use any actual screen at all. It just allocates a block of RAM memory and pretends it's a display. It looks like Xvfb just does not implement those parts of the protocol that deal with reporting the size of a physical screen. As a result, the X11 protocol falls back to default assumptions of the original X11 protocol design, made back in year 1987 or so. What are you actually doing that requires capturing specifically 16:9 screenshots of a Xvfb "display"? – telcoM Feb 10 '19 at 10:22
  • i am capturing css animation to feed ffmpeg – direxit Feb 10 '19 at 10:32
  • See my updated answer for a completely different approach to your problem. – telcoM Feb 10 '19 at 11:00
  • Thanks, right now i'm using chrome ( pupeeter ) with a nodejs script that connect to localhost:3000 ( where the actual animation happens) -> then ffmpeg is fed with the x11grab option, can't see why ssh with solve resolution pb as it is a protocol. and all of this is hapening on serverside only, there is no distant workstation involved – direxit Feb 10 '19 at 11:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.