Upcoming patches will need to retieve GC's XIDs on the upstream connection.
Moving this out into separate .c file, in order to not creating more
dependencies on Xlib headers, which we wanna get rid of.
For now, looking at the Xlib GC structure, attached to our DDX GCs.
When all users of the Xlib GC have gone (ie. moved all consumers to xcb),
we'll create the GC via xcb directly, thus replacing the Xlib GC struct
by XID - the interface of this helper will remain the same.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Fetching the setup data from xcb instead of Xlib, storing in our own struct,
holding all information needed for one particular upstream connection.
For now, there's only one, but future multi-upstream implementation will
change this to an array (and storing pointers to particular upstream in
various places).
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Since we're not indirectly writing via FILE anymore, this option has
become meaningless: it meant flushing out our in-process buffer to
the kernel, but we're now doing direct write() calls anyways.
xf86 still accepts the "flush" config file flag for backwards compatibility,
but it hasn't any practical meaning anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons, so
use the new window destructor hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons, so
use the new window destructor hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons, so
use the new window destructor hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons, so
use the new window destructor hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This wrapping function for Screen->ResizeWindow() is does nothing more than
just call the original functions. So no need to keep wrapping it at all.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This proc vector is optional (callers check for non-null) and neither fb nor
mi set it, so we can just assign our function directly. No need for wrapping.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This proc vector is optional (callers check for non-null) and neither fb nor
mi set it, so we can just assign our function directly. No need for wrapping.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This wrapping function for Screen->CopyWindow() is does nothing more than
just call the original functions. So no need to keep wrapping it at all.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Both engines, GDI as well as DirectDraw, using the same screen init finish function,
so no need to keep indirection via per-engine callback pointer.
The winFinishScreenInitFB() can also be made static now.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It does nothing more than just calling the original/wrapped function,
so we don't need that at all.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It does nothing more than just calling the original/wrapped function,
so we don't need that at all.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Even though the order of these fields shouldn't change anytime
soon, it's still better programming style to name'em explicitly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Even though the order of these fields shouldn't change anytime
soon, it's still better programming style to name'em explicitly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Even though the order of these fields shouldn't change anytime
soon, it's still better programming style to name'em explicitly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Even though the order of these fields shouldn't change anytime
soon, it's still better programming style to name'em explicitly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Even though the order of these fields shouldn't change anytime
soon, it's still better programming style to name'em explicitly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Even though the order of these fields shouldn't change anytime
soon, it's still better programming style to name'em explicitly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Even though the order of these fields shouldn't change anytime
soon, it's still better programming style to name'em explicitly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Even though the order of these fields shouldn't change anytime
soon, it's still better programming style to name'em explicitly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Even though the order of these fields shouldn't change anytime
soon, it's still better programming style to name'em explicitly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Even though the order of these fields shouldn't change anytime
soon, it's still better programming style to name'em explicitly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Even though the order of these fields shouldn't change anytime
soon, it's still better programming style to name'em explicitly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Enrico Weigelt, metux IT consult