xrandr and vertical refresh trouble (intel video driver bug?)

kokoko3k · 2010-08-15 15:51:05

Trying to get a smooth video playback with mplayer, i added two modes via xrandr:

#NTSC (29.97*2)
        xrandr --newmode "1024x600x59.94"  49.150800  1024 1064 1168 1312  600 604 608 625  -HSync +VSync
        xrandr --addmode LVDS1 "1024x600x59.94"

#PAL (25*2)
        xrandr --newmode "1024x600x50.00" 39.00 1024 1056 1200 1232 600 613 618 631 -HSync +VSync
        xrandr --addmode LVDS1 "1024x600x50.00"

Now i can change it via "xrandr --output LVDS1 --mode "modenane", and that seems to work because the screen goes black for a while, and even changing tty via ctrl-alt Fx now takes a while (i'm using kms and the switch using native resolution is immediate).

Unfortunately, i've seen no improvements in playback smoothness, i'm using a simple test video which shows a white line crossing the screen on a black background, i set the fps manually via mplayer -fps 50 (25*2=PAL) or -fps 59.94 (29.97*2=NTSC), and i also tried to switch video output from xv to gl

Another strange thing is the fps reported by glxgears:

kokonicki@netbook ~ $ xrandr
Screen 0: minimum 320 x 200, current 1024 x 600, maximum 4096 x 4096
VGA1 disconnected (normal left inverted right x axis y axis)
LVDS1 connected 1024x600+0+0 (normal left inverted right x axis y axis) 220mm x 129mm
   1024x600       60.0 +
   800x600        60.3     56.2  
   640x480        59.9  
   800x480        59.4  
   1024x600x59.94   59.8  
   1024x600x50.00   50.2*    # <<--- Xrandr is saying the screen is at 50.2Hz
   1024x600_50.30   49.1  

kokonicki@netbook /usr/share/man $ glxgears
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.  #<-- Good!, so i can expect about 50fps here...
305 frames in 5.0 seconds = 60.856 FPS
306 frames in 5.0 seconds = 61.163 FPS
306 frames in 5.0 seconds = 61.163 FPS
306 frames in 5.0 seconds = 61.163 FPS
306 frames in 5.0 seconds = 61.163 FPS
235 frames in 5.0 seconds = 46.971 FPS
306 frames in 5.0 seconds = 61.163 FPS   # <<--- WTH? I'm getting 61.163fps instead!

...Even if xrandr claims to be at 50Hz and glxgears claims to be in sync with the verical refresh, it still outputs exactly 61.163fps, no matter what resolution/refresh i use.
How can this be possible? Have i spotted a bug in the video driver/xorg or am i doing something wrong?

Some relevant infos:
PC: Asus 1005HA
GPU:Intel Corporation Mobile 945GME Express Integrated Graphics Controller
xorg-server 1.8.1.902-1
xf86-video-intel 2.12.0-1

Last edited by kokoko3k (2010-08-15 15:56:01)

kokoko3k · 2010-08-16 15:22:31

An update:
Getting video output through VGA connector, everything works as expected, glxgears reports about the same value as the refresh rate (well, there is still a bug, i have to keep my finger on the touchpad, or else the fps drops to 20... (!) ).

At this point the question is: Is the LVDS technology unable to change the screen refresh rate by design?

-EDIT:
http://forums.gentoo.org/viewtopic-t-82 … art-0.html
this guy can set a (supposed) refresh rate of 999hz...

Last edited by kokoko3k (2010-08-16 15:24:15)

ewaller · 2010-08-16 17:01:11

Timing on LCD panels is not arbitrary. For any given panel, the horizontal and vertical timing are fixed.

I have designed LCD controllers. Most panels are 60Hz. Attempts to drive them at other rates are not pretty -- trust me. In some cases, it is possible to destroy a panel with incorrect timing. Note that this is not something you can not do from within xrandr, rather it is intrinsic to the LCD controller.

Edit: added missing word [not]

Last edited by ewaller (2010-08-16 17:50:58)

kokoko3k · 2010-08-16 17:46:53

Thank you for explaining, so i have to assume that the "on board" lcd panel is at fixed rate and the external one (through vga, it's a panasonic viera led/lcd) is not ?
Still the inconsistency between what xrandr reports and the real panel refresh is confusing me, and if the refresh isn't really changed, i can't explain the higher delay when switching to text tty.

ewaller · 2010-08-16 18:05:57

kokoko3k wrote:

Thank you for explaining, so i have to assume that the "on board" lcd panel is at fixed rate and the external one (through vga, it's a panasonic viera led/lcd) is not ?
Still the inconsistency between what xrandr reports and the real panel refresh is confusing me, and if the refresh isn't really changed, i can't explain the higher delay when switching to text tty.

Yes, the internal connection is known to be an LCD panel, whereas the VGA can be a CRT or an LCD. In the case of an LCD on a VGA connector, the controller receives and decodes the video signal and recovers the data, whatever the timing and format. Those data are then scaled to the native format of the LCD panel and are buffered in RAM. The backend reads data from RAM and drives the panel in use at the rate, in the format it demands.

I cannot really speak to the inconsistency regard xrandr and the actual refresh rate. I can envision some scenarios, but they would just be hypotheses.

One interesting thing about LCDs -- They don't flicker like CRTs. LCDs shutters pretty much remain static from frame to frame, emitting light for the entire period. CRTs only emit light from a pixel after it has been illuminated by the sweeping electron beam. This is why it is possible to photograph LCD displays at arbitrary shutter speeds. This does mitigate most of the need to drive the panel at one rate or the other. The only real issue is that, in order to eliminate mid-field tearing by synchronizing to a non-native frame rate, requires dropping frames when going from 60->50Hz or doubling frames when going from 50->60Hz.

kokoko3k · 2010-11-24 08:44:35

I made some other tests on totally different hardware that confirm what you said.
Using an external viera lcd tv connected via vga to an ion platform, the video driver was unable to get any edid data from the tv through the vga cable, but the manual fooled me claiming the display to accept a relative wide range of "input" refreshes, so i set a 72hz video mode and got about 72pfs with glx gears, but the output was very jerky compared to the 'native' 60hz mode.
It was clear that the panel was dropping some frames by its own; another lcd monitor connected to the ion in the exact same way was smooth at 72hz (same modeline)

Anyway that tv (viera) is able to display 50hz pal video streams smoothly without any kind of frame interpolation, so it seems that it is still able to 'output' at 50hz, am i wrong?
Also, i'm considering to buy an hdmi cable, because the panel doc says that it support 24hz video input through hdmi.

So i wonder what will i have to expect, once i will connect a 24hz signal via hdmi to the panel, A video frames interpolation from 24 to 30 (or 60) or a real 48hz video mode?

-Edit, typos-

Last edited by kokoko3k (2010-11-24 08:47:58)

ewaller · 2010-11-24 16:20:05

In PAL, the frame rate is 25 frames / sec (50 fields per second) for interlaced video, or 50 frames/sec for non interlaced video. This is close enough to the 24 frames second that they actually play cinematic movies not at 24 Frames/Second but rather at 25 Frames/Second. They perform some signal processing magic to the audio to keep it in sync without changing pitch.

In NTSC, they perform what is known as a 3:2 pull down. They convert 24 frames / second to 30 frames/second by showing 1 movie frame for 3 video fields, and the next video frame for 2 video fields. This means 5 video fields * 1/60 sec for 2 movie frames * 1/24 second. The time for each of these is 1/12 second SO they stay in sync and do not have to muck with the audio. This is why, if one pauses NTSC video that is displaying cinematic content, you sometimes get a frame that "jumps" or "jitters" when paused. This is because one of the two fields is from one movie frame, and the other video field is on the next movie frame. This is especially noticeable when the content between two movie frames is significant -- like a scene cut, an explosion, etc...

Arch Linux

#1 2010-08-15 15:51:05

xrandr and vertical refresh trouble (intel video driver bug?)

#2 2010-08-16 15:22:31

Re: xrandr and vertical refresh trouble (intel video driver bug?)

#3 2010-08-16 17:01:11

Re: xrandr and vertical refresh trouble (intel video driver bug?)

#4 2010-08-16 17:46:53

Re: xrandr and vertical refresh trouble (intel video driver bug?)

#5 2010-08-16 18:05:57

Re: xrandr and vertical refresh trouble (intel video driver bug?)

#6 2010-11-24 08:44:35

Re: xrandr and vertical refresh trouble (intel video driver bug?)

#7 2010-11-24 16:20:05

Re: xrandr and vertical refresh trouble (intel video driver bug?)

Board footer