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>
Not used by any external modules, so no need to keep it in public API.
Since it's used by DRI, still needs the _X_EXPORT flag, as long as DRI
is a dynamically loaded module.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1790>
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>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1788>
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>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1788>
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>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1788>
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>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1788>
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>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1788>
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>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1788>
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>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1788>
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>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1788>
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>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1788>
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>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1788>
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>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1788>
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>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1788>
Multiple CRTCs can be added on a per-screen basis with the new -crtcs
option. Each CRTC has one associated output. Outputs beyond the first
are disabled by default and can be enabled by setting a mode. Outputs
can be disabled again by setting the associated CRTC's mode and output
to None.
Signed-off-by: Andy Myers <andy.myers@zetier.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1749>
Enrico Weigelt, metux IT consult
Doug Brown
Andy Myers