The previous code was working by luck, since the "device busy" error
when opening the 2nd device was ignored. With xserver 1.8, xinput2 is
a bit less tolerant and causes a segfault. Problem reported by sthen@
Thanks.
(but never made it into the 7.8 branch).
first:
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Thu Apr 22 12:47:41 2010 -0700
DRI2: add config query extension
Add a new DRI2 configuration query extension. Allows for DRI2
client code to query for common DRI2 configuration options.
second:
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Thu Apr 22 12:49:03 2010 -0700
DRI2/GLX: check for vblank_mode in DRI2 GLX code
Re-add support for the vblank_mode environment and configuration
variable. Useful for benchmarking and app control.
The final affect being that config and environment variables for
controlling swap mode work with dri2 now. which helps me a lot with
debugging.
ok matthieu@.
case libGL itself was dlopen()ed), it was using "libGL.so.1" (linux
convention, doesn't work on OpenBSD). Change it to "libGL.so" so it has
a hope in hell of working.
I finally wrote this patch when trying to port perl's OpenGL modules
ages ago and i finally decided that hacking each instance of dlopening
libGL to use RTLD_GLOBAL was dumb.
ok matthieu@
Since mesa changed some code, GL applications have been rather nasty to
the xserver, if they are unconstrained rendering wise they spam too many
requests at the xserver and make it slow as hell (even if the cpu is
fairly idle).
There is a throttling mechanism in the xserver (1.8 at least), but that
only really works if you are doing vblank syncing (which is turned off
in our intel driver right now for unrelated reasons), and even then an unsynced
client can cause the same problem.
While a proper fix is being worked on (I am in discussion with X
developers), comment out two conditionals in the intel mesa driver so
that even when using dri2 swapbuffers we wait on the swapbuffers before
last before rendeing more, this prevents almost DoSing the server.
Tested on ironlake, 855 and 965 by me (and my matthieu as well). ok
matthieu@
It is missing a few commits that I have yet to verify (ones that try and
continue if we lock the gpu rendering engine and can't reset it, for
example) taht will be verified and sent out for extra testing soon.
Should contain a bunch of speedups and some correctness improvements
(though rendercheck still gives some errors that I am looking into).
This has been in snaps since the first day of c2k10, any known issues
with just this driver have (to my knowledge) been fixed since. A problem
with macbooks pointed out by otto happens with both this and the in-tree
driver and thus doesn't stop this moving forward.
As well as the 2.12 improvements, this driver also has a backport
(partially aided by the backports in RHEL 5 kindly provided by Dave
Airlie) from the kms code of modesetting support for ironlake (arrandale
and clarkdale: the IGDs build into intel nehalem cpu dies) which has
been tested on a number of chipsets. Note that Display port and eDP
displays have not yet been worked on (and probably won't until I can
find a displayport monitor), but VGA and lvds at least are known to
work, sure beats vesa.
"no objection on my side" matthieu@, prodding (as always) from princess
marco.
