with Ctrl Alt *.
This is not the complete fix but mitigates the issue for now.
Bug was introduced to OpenBSD in the xserver update on 2011/11/05
(commit 7d2543a3cb3 upstream), so it affects -current since that date,
but no OpenBSD releases.
ok matthieu@ phessler@ dcoppa@, also tested by schwarze@, jj@
If you want this fix before new snapshots are available, copy the new
file to /usr/X11R6/share/X11/xkb/compat/xfree86 and reload the kbmap e.g.
setxkbmap $(setxkbmap -query | awk '/layout/ { print $2 }')
(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@
update mesa.
Specifically, we disallow in radeondrm for dri clients mapping
registers, so don't try and map them (and thus fail as we currently
were). for r300+ this was only used for falling back on old drm versions
(doesn't matter). For r100, the new BO abstraction used the SWI number
(in hardware scratch reg 3) for the buffer age, so use the newly added
getparam member to grab that info instead of trying to read the mapped
registers.
Update to the lastest kernel headers before you even think about
building this or trying to use a snapshot on r100/r200.
So now radeon works with mesa again, hoorah!
Tested on rv250 by Josh Elsasser, and on R420 (and x800) by myself.
Specifically, fix checks on the data so then we use the correct
sanitised length. From Peter Harris (pharris AT opentext DOT com), an
xcb developer, via David Coppa (dcoppa AT gmail DOT com); thanks!
requested by deraadt@
is correctly handled. without fixes to mesa and the ddx, the so-called
backwards compat goop that was added just plain does not work and ends
up with rendering bullshit.
light of day and has already been removed in mesa master (ages ago).
As a bonus, removes the annoying "falling back to classic" message on
launching a gl application.
ok matthieu@.
from this was removed from the kernel and is very much deprecated.
Pageflipping is also probably broken and should not be used. Similar
change happened in mesa master a while back.
ok matthieu@
