Date: Sun, 11 Dec 2011 17:57:05 +0800 From: Meowthink <meowthink@gmail.com> To: freebsd-x11@freebsd.org Subject: Problem with Intel GPU patch (cont.) Message-ID: <CABnABobKHTRYJ13C%2BTvuouaqETTHxTLTu7sDuG%2BUzJLdhbivyw@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Hello all, Could Anybody give a help? I've dug a little deeper on the problem, but still can't figure out where the problem lies. I tried to use a easier way to close output to main display, but eventually a mysterious thing: In additional to "xset dpms force off" which really switch off main display, either "xset dpms force standby" or "... suspend" will get VirtualGL works fine - at least in my test cases. After issued such a xset command, I can get 2 or more OpenGL apps rendered on the server side, then transferred to clients, even clients are on individual hardwares. The mysterious point is here: xset both standby/suspend mode only blanks my old CRT a second, and then the main display restores. This means, I can even get some OpenGL apps drawing on main display while have vgl rendered out of that screen. The "mixed", or "leaked" problem describe in former email occurred immediately after issuing an "xset dmps force on". Looking into codes, it seems X extension only passes these dpms states to the driver. And in the driver, intel_crt_dpms() suggests these operations only disables H-sync or V-sync? What I believed is, the problematic state (Pbuffer content mixed with main framebuffer) shows that, there's something wrong with the memory access. So I am confused now. Any suggestions? Regards, meowthink
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CABnABobKHTRYJ13C%2BTvuouaqETTHxTLTu7sDuG%2BUzJLdhbivyw>