Even though they're defined to zero by the spec, we've seen an EDID block
where the (empty) ASCII strings were stuffed in a byte early, leading to the
descriptor being considered a detailed timing instead.
If the driver isn't compatible to the server, all bets are off anyway wrt
the contents of the fields that we're validating, which can lead to bogus
error messages.
The only functional changes in this patch are a removal of use of
Xtrans internals -- replaced by xcb, which doesn't seem to be used
elsewhere in the server? Pity.
Also, a fix to make all X11 windows pop to the front of the display
when the X11.app icon is clicked -- currently takes two clicks,
not sure why.
At least on my system (10.5 with the latest and greatest modules),
Xquartz now builds out of the box. It doesn't quite work yet, but
hey -- you have to start somewhere. ;)
this fixes a breakage caused by 7a4ec34e25.
When running a non DTRACE aware system that is not darwin*, DTRACE was getting
required. Now it is not anymore.
This was an attempt to avoid scratch gc creation and validation for paintwin
because that was expensive. This is not the case in current servers, and the
danger of failure to implement it correctly (as seen in all previous
implementations) is high enough to justify removing it. No performance
difference detected with x11perf -create -move -resize -circulate on Xvfb.
Leave the screen hooks for PaintWindow* in for now to avoid ABI change.
Instead of drawing to window pixmap for everything, draw to window for
background as that works for Xnest and Xdmx; draw to pixmap for borders
which neither of those X servers use.
miPaintWindow was drawing to the root window, or (sometimes) drawing to the
window after smashing the window clip list. This is losing, and easily fixed
by just drawing to the window pixmap.
Because our "popen" implementation uses stdio, and because nobody's stdio
library is capable of surviving signals, we need to make absolutely sure
that we hide the SIGALRM from the smart scheduler. Otherwise, when you
open a menu in openoffice, and it recompiles XKB to deal with the
accelerators, and you popen xkbcomp because we suck, then the scheduler
will tell you you're taking forever doing something stupid, and the
wait() code will get confused, and input will hang and your CPU usage
slams to 100%. Down, not across.
Improve exaShmPutImage performance and reuse its core in exaPutImage as it
seems faster than the previous code when the driver doesn't provide an
UploadToScreen hook.
Make sure all damage records are notified of the damage incurred by actual
ShmPutImage calls.
Remove superfluous manual damage tracking for actual PutImage calls.