LessThan/GreaterThan comparisons were used in the wakeup handler,
and LessOrEqual/GreaterOrEqual in the block handler.
Change it to use LessOrEqual/GreaterOrEqual in both functions,
since this is what XSyncNegativeComparison and
XSyncPositiveComparison imply.
This reverts commit 2243b30e54. The existing
DRI interface doesn't let us get from a __DRIdrawable to the corresponding
X drawable, and thus, we can't implement AIGLX damage tracking with the
current interface.
As a result, we can remove the quirks that existed to flip the bits back around
for us. This is not confirmed in all cases due to lack of bugs containing EDID
blocks associated with the quirks, but is likely true.
RRFirstOutput returns the first active output, which won't be set until
after RRScanOldConfig is finished running. Instead, just use the first
output (which is the only output present with an old driver, after all).
I exported the evdev driver to Xephyr server. I'm running it using something
like:
$ ./hw/kdrive/ephyr/Xephyr :1 -mouse evdev,,device=/dev/input/event4 -keybd \
evdev,,device=/dev/input/event1,xkbmodel=abnt2,xkblayout=br
It also closes /#5668.
Don't use our DBusError for property getting, because we simply don't care:
this fixes D-Bus error spew to stderr. Thanks Michel Dänzer for debugging
and testing.
and the Xephyr virtual mouse keeps alive. With this patch the semantic changes
turning '-pointer' && 'Xephyr virtual mouse' always false.
Now we can open a device pointer and pass its options in Xephyr's command line
without having other pointer unused.
Don't call fbFinishWrap until the pixman_image_t that stores the pointer is
actually freed. This prevents corruption or crashes caused by accessing a
wrapped pointer after the wrapping is torn down.
The outport is most likely unnecessary on any currently used hardware,
the byte copy is necessary from what I know on IA64 and friends so leave it.
Add a new API entry point which lets a driver select the old behaviour if
such a needs is ever found.
This gives me ~20% speed up on startup on 945 hardware.
This avoids some inefficiency in creating a temporary Picture
for every glyph at rendering time. My measurements with an i965
showed the previous patch causing a 10-15% slowdown for NoAccel
and XAA cases, (while providing an 18% speedup for EXA).
With this change, the NoAccel and XAA performance regression is
eliminated, and the overall EXA speedup, (before any of the
glyphs-as-pixmaps work), is now 32%.
Instead of system-memory data which prevents accelerated
compositing of glyphs, (at least without forcing an upload
of the glyph data before compositing).
Using a cryptographically strong hash means that comparing the
hash alone is sufficient for determining glyph equality (no need
to compare the glyph bits directly). This will allow us to replace
system-memory copies of the glyph bits, (which we've only been
holding onto for comparisons), with Pixmaps.
This is a cleanup without any real savings (yet). Previously, the
implementation would allocate a new glyph, then (often) find it in
the cache, and immediately discard the allocated object. This
re-organization first uses a new FindGlyphByHash function and only
allocates the glyph if nothing is found.
This isn't a real savings yet, since FindGlyphByHash currently still
does a temporary glyph allocation, but this is expected to be replaced
immediately as we switch to an alternate hashing mechanism (SHA1).
This is in preparation for a future change that will take advantage
of being able to compute a hash for a separate xGlyphInfo and chunk
of bits without a combined Glyph object.
This prevents situations where the server doesn't use the target the
client thinks it does, usually resulting in the texture being sampled as all
white.
