[Bug 39202] FPS - KDE desktop effects with 3.0 rc6 kernel

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=39202

--- Comment #33 from Ilija Hadzic <ihadzic at research.bell-labs.com> 2011-08-18 08:50:00 PDT ---
(In reply to comment #32)

> I can connect only the VGA connector as I have only one LCD monitor without DVI
> or HDMI slots. The video card has VGA, HDMI and DVI connectors.

If you have some spare change in your pocket you can get some HDMI-to-VGA
and DVI-to-VGA converter dongles to try out (they are no more than 
5-10 bucks a pop) and trying out different connectors might give us
some good datapoints.

> Maybe the old kernel is broken even on VGA (crtc1) (the patch says crtc>1 and
> not crtc>=1)?

No. crtc>1 is correct message associated with the patch, 
but the user space also plays the role here. 
Specifically the old kernel could only distinguish between primary and
secondary crtc and treated primary as 0 and secondary as 1. User space
on the other hand could at its own discretion map the real crtc number
to primary or secondary. Prior to the patch, radeon DDX called 0 
primary and everything else secondary so all crtcs >=1 mapped 
to 1, but 1 was correctly mapped.

Fixed radeon DDX maps all crtcs correctly, but it refuses to use
vblank synchronization with old kernel. New kernel on the other 
hand still understands and accepts primary/secondary notation
for backward compatibility with old DDX, but with the understanding
that it may wait on wrong CRTC if user space is old.

How KDE (assuming that it calls the vblank ioctl directly) determines
the CRTC number is anyone's guess but if it does similar primary/secondary
mapping of high crtcs like DDX did, things will look strange.
We need to find that out, so can you please check which CRTC does the
glxgears use in your case and which CRTC does the KDE use? You can do that
by enabling debug in drm (echo 7 > /sys/module/drm/parameters/debug)
and searching the kernel log for "waiting on vblank count %d, crtc %d\n"
string that comes from drm_wait_vblank function in drm_irq.c. Make sure
that you use the kernel *with* the crtc>1 patch because
the one without will not properly handle high crtcs.

Beware that the log will be very verbose once you turn the debug on. 
If you are overwhelmed by other messages you could temporary change
the relevant DRM_DEBUG statement in drm_irq.c into DRM_INFO and 
recompile the kernel; then you won't have to turn on the debug 
parameter. Observe the log and try to figure out which CRTCs are
used by whom. If it turns out that the one from KDE is different
from the one from glxgears, then we need to figure out which one
is wrong and why (in that case the problem will point to userland).

BTW, I may have mispoken in my previous post. Looking back at my logs
it's the VGA that typically sits on CRTC2 and DVI is CRTC1, so by using
the VGA port you may very easily be sitting on a CRTC number that is
mishandled in older kernels. On the other hand CRTCs are dynamically
routed to connectors and if you have only one connector hooked up 
to the monitor, the driver *should* in most cases route everything
to CRTC0, but that part of the code is quite complex and it is not
excluded that you indeed end up on CRTC2. We'll see that after you
do the experiment I described.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.