Now, fbcmap_mi.c contains the fb functions which just wrap mi functions.
Previously, these were in fbcmap.c and compiled when XFree86Server was defined.
Now, clients of fbcmap should either use fbcmap.c or fbcmap_mi.c and not worry
about setting the XFree86Server symbol.
Erasing this variable causes some outputs (SDVO on intel) to fail
to be correctly reset at server reset time.
(cherry picked from commit 56262a4ee943f328d089a8eb4aa70b9a4bd5d135)
It seems that the changes to X input exposed a problem that wasn't detected
before. The axis clipping code in GetPointerEvents() uses those limits to
constrain the pointer's coordinate range. The max was zero so the pointer
couldn't move.
Use new dmxCoreMotion2() function which enqueues motion events with
GetPointerEvents()/mieqEnqueue().
The clipAxis() code in GetPointerEvents() is causing some grief. The
limits seem to have always been (0,0) according to the original calls
to InitValuatorAxisStruct() in dmxinputinit.c.
Terrible hack for now: Call InitValuatorAxisStruct() with hard-coded max
values of 1280 (my screen width).
Calloc cursor struct to ensure devPrivates are zeroed out and don't
increase the refcnt for devices automatically when allocating a new
cursor. Use new DeviceIsPointerType() to detect if device is a pointer
_before_ device has been activated and can thus be identified and set
up grab functions accordingly. This way we can increase the refcnt
when we get a pointer grab.
Additionally, protect libcw setup behind checks for Render, to avoid
segfaulting if Render isn't available (xnest).
The previous setup was an ABI-preserving dance, which is better nuked now.
Now, anything that needs libcw must explicitly initialize it, and
miDisableCompositeWrapper (previously only called by EXA and presumably binary
drivers) is gone.
Yes, two changes in one commit. Sorry 'bout that.
The first change ensures that when pending property values have been
changed, a mode set to the current mode will actually do something, rather
than being identified as a no-op. In addition, the driver no longer needs to
manage the migration of pending to current values, that is handled both
within the xf86 mode setting code (to deal with non-RandR changes) as well
as within the RandR extension itself.
The second change eliminates the two-call Create/AttachScreen stuff that was
done in a failed attempt to create RandR resources before the screen
structures were allocated. Merging these back into the Create function is
cleaner.
(cherry picked from commit 57e87e0d006cbf1f5b175fe02eeb981f741d92f0)
Conflicts:
randr/randrstr.h
randr/rrcrtc.c
I think master and server-1.3-branch are more in sync now.
