Not sure why these are conditionals, anyway. This one really needs
revisiting, but at least causes configure, rather than the compilation,
to bomb out.
If the pixel in framebuffer memory isn't modified since we uploaded it, we
can just read from the system memory copy, wihch avoids both a readback and
an accelerator stall.
In principle this function is still wrong, and all the framebuffer pixel
access should be going through (w)fb so we can get pixel layout corrections.
Set the new randr crtc of the output before the output change notification is
delivered to the clients.
Remove RROutputSetCrtc as it is not really necessary. All we have to do is set
the output's crtc on RRCrtcNotify
When the PreferredMode option is selected in the config file, remove the
M_T_PREFERRED bit from all other preferred modes to force the config file
mode to be selected.
Code that disabled mode detection on disabled outputs would confuse
applications by listing said outputs as connected but without any modes.
This makes the disabled state in the config file affect only the initial
configuration and not subsequent modifications by RandR.
The DDX code was ignoring pending properties for computing when mode setting
was required. This meant that configurations differing only in property
values would not cause the mode to be set.
Besides being slightly simpler to read, it's now trivial to add a depth-16
visual to a depth-24 screen just by adding a line for it in the alternate
visual list. Visuals for indexed depths are slightly tricky still.
If your loader is as bad as elfloader, then it makes sense for the
server to have some stubs for you to assign to / break on. However it
is no longer 1996.
I made a mistake in some new code using MakeAtom, passing the size of the
string instead of the length of the string. Figuring there might be other
such mistakes, I reviewed the server code and found four bugs of the same
form.
When checking how to validate the selected mode and position against the
current screen size, the test against 90/270 rotation did not mask out
reflection, so that when reflection was specified, the 90/270 test would
never succeed. This caused incorrect bounds checking and would return
an error to the user instead of rotating the screen.
The previous scheme didn't work when the client didn't create the core drawable,
e.g. the root or composite overlay window. Use refcounting via special client
resources to fix that.
XkbCopyKeymap reallocates the destination keymap when it is not large enough
to hold the source data. When reallocating the map->types data, it needs to
zero out the new entries. The computation for where to start bzero'ing was
accounting for the size of the data type twice, once implicitly in the
pointer arithmetic, and once explicitly with '* sizeof (XkbKeyTypeRec)'.
This would often lead to random memory corruption when the destination
keymap had existing map->types data.
