When using any XAAPixmapOps, we call into unknown but freshly
unwrapped callbacks (like fb ones). Unlike the XAA*Fallback calls,
we did so without syncing first, exposing us to all kinds of
synchronisation issues.
I believe that the rendering errors appeared now because *PaintWindow
vanished (e4d11e58), and we just use miPaintWindow instead. This
takes a less direct route to the hw and ends up at
PolyFillRectPixmap, which very often left drawing artifacts.
We now sync accordingly, and no longer get the rendering artifacts i
was methodically reproducing on radeonhd, radeon, unichrome...
Also, in order to allow driver authors to remove extensive syncing
or flushing to hide this issue, create XAA_VERSION_ defines, put
them in xaa.h and bump the patchlevel.
(novell bug #435791)
When setting the depth to 24, leave bpp unset so the logic to pick
a supported value is used instead of ignoring the driver's preference
and forcing 32 bpp.
The swrast DRI provider gets pushed on the glx provider stack at every
server generation, so the stack turns into a circular list on regen.
X.Org bug#18388 <https://bugs.freedesktop.org/show_bug.cgi?id=18388>
GL/capabilities.c: Add handleDepthModes(), and extend
handleRendererDescription() for the various depth and multisampling flags.
Add initialization of the new config options to initConfig().
GL/capabilities.h: Add depth and multisample config members.
GL/visualConfigs.c: Add depth and multisampling support to the visual config
setup.
(cherry picked from commit f527381eea)
GL/capabilities.c: #if 0 (for now) any capabilities above 8 bits per channel,
because they introduce drawing problems.
GL/indirect.c: Comment out some visual setup code that shouldn't be running, and
actually seemed to cause some problems. The current visualConfigs.c code seems
to do a reasonable job of setting up visuals for XQuartz.
GL/visualConfigs.c: Make use of the proper visual .class. Eliminate depth 0.
It seems we really just want 24 for now, and 0 I think was a flaw in the original
code.
(cherry picked from commit 1e5f63f15e)
Works around a silly bug in the kernel that causes wakeup storms after
too many keypresses. Should fix the kernel bug too, but this at least
keeps the idle wakeup count below 1000/sec.
When a user specifies the position of an output for which no modes exist
(for whatever reason) assume that the width and height of this output
is 0. The result will be the same as if this output isn't taken into
consideration at all and thus should be sane. It will prevent a segfault
when trying to determine the width and height of a non-existent mode.
It was accidentally lost when factoring out __glXDRIdoReleaseTexImage, so this
is a regression fix and should probably be backported to server-1.5-branch.
If the event is an XI event, we need to work on the correct device, not on
the VCK.
Adds XIGetDevice(event) function to extract the device from an event.
Really, this was a bad idea. It's not security, the UI features that would
have been cool (e.g. clicking through windows) aren't implemented anyway, and
there's nothing you can't achieve just by using plain XI anyway.
Requires inputproto 1.9.99.6.
When MouseKeys are activated, keyboard devices may generate fake mouse button
events through XKB. Let's get then running through the appropriate paths, i.e.
as XI events on the correct device.
To make matters more fun, ProcessOtherEvents drops events if the DIX device
state cannot be updated accordingly, i.e. all button events from keyboard
devices.
Hence we need to get the paired MD for the device in XkbDDXFakeDeviceButton,
and post the event through the paired MD (usually the VCP).
Removes now-unused ddxFakeBtn.c.
Note: this patch only half-arsedly fixed button events, motion events are a
more complicated matter.
These weren't even being used, which isn't overly surprising, given that
they were already in the struct.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
A couple of coding style cleanups, a warning fix via removing a
now-unused label, and also put an else so we don't spuriously trip a
condition that should admittedly never occur anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
newTypes is a local variable which always has an address. newTypesIn,
on the other hand, might be sus.
See also 5544c51447.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
This is used in libGL to determine a preferred visual. glxinfo -v will also
report "visualCaveat=Slow" for such visuals.
(cherry picked from commit d5c17f585a)
