In xnestOpenScreen(), some compilers/analyzers spitting out a false alarm on
`defaultVisual` field potentially used uninitialized. This can't practically
happen, but not all compilers/analyzers really can see that.
Adding a zero initializer doesn't cost us anything, so silencing that false
alarm is trivial.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
VisualID defaultVisual = 0;
int rootDepth = 0;
This makes certain that the variables are not undefined so it can silence a compiler warning I noticed when building the x11libre xserver.
Right now, we're only registering the depths of our visuals, which are
mirroring upstream's visuals. But forgotten to register the pixmap depths
that don't have an assiocated visual.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Since we're now using xcb for upstream X11 connection, it's cleaner to
use it's type for the window IDs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Now that we completely ported from Xlib to XCB, we can finally stop
importing Xlib :)
FIN.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
xnestWindowExposures() is a micro-optimization for the specific case that
a newly created window receives exposure events (from our upstream server)
inside the region we're already exposing on our own (miWindowExposures()):
it peeks the Xlib event queue for all expose events, checks whether their
areas are inside our exposure region and requeue's those that aren't.
Unfortunately, this depends on Xlib's internal queue mechamism, thus standing
in the way of moving to XCB (which doesn't have that).
Removing this doens't seem to make any practical difference, even with
demanding applications like GIMP. The only cost is potentially having some
initial window content painted twice, *if* the application really draws
something complicated right after creating the window.
*If* there'll really be a demand for such an optimization some day, it can
be reimplemented without any message queue: just redirecting all expose events
into recording them in a region, which is flushed out later. But for now,
there really doesn't seem to be any practical need for that.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Use the visuals lookup table introduced by previous commit for
looking up local vs upstream visuals and their colormaps.
Replacing the the old Xlib visuals table.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Record the associations between host's and our visuals as well their
corresponding cmaps in a global table, which's used later for lookups.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of going through mi machinery, just pass the ClearArea
request to the upstream window.
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>
Only key difference that calloc(), in contrast to rellocarray(),
is zero-initializing. The overhead is hard to measure on today's
machines, and it's safer programming practise to always allocate
zero-initialized, so one can't forget to do it explicitly.
Cocci rule:
@@
expression COUNT;
expression LEN;
@@
- xallocarray(COUNT,LEN)
+ calloc(COUNT,LEN)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using calloc() instead of malloc() as preventive measure, so there
never can be any hidden bugs or leaks due uninitialized memory.
The extra cost of using this compiler intrinsic should be practically
impossible to measure - in many cases a good compiler can even deduce
if certain areas really don't need to be zero'd (because they're written
to right after allocation) and create more efficient machine code.
The code pathes in question are pretty cold anyways, so it's probably
not worth even thinking about potential extra runtime costs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This file became pretty no-op, just including dix-config.h.
So we can remove it now and include dix-config.h directly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1632>
These files are always compiled w/ HAVE_XNEST_CONFIG_H and always
need to include this file, so the ifdef can be dropped.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
With aa3f5023e3, pScreen->devPrivate now is
initialized only once, which uncovered a silent bug in xnestOpenScreen:
It's NULL'ing the pScreen->devPrivate pointer which already had been
initialized by previous miScreenDevPrivateInit() call.
Fixes: aa3f5023e3
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1495>
For cleaner code, make sure every source needing something from Xdefs.h
does explicitly include it (not relying on indirect including)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1394>
Since it's storing an locally defined (ddx-internal) struct, it's better
not to abuse some globally defined key for this.
It just happened to work before, since CursorScreenKey is only used by DDX
(and there's only one DDX per executable) and they currently (!) have the
same size (pointer) - but that's a fragile programming style, so clean it up.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1342>
It's naming is a bit unprecise: it actually is used for storing
xnestCursorFuncPtr inside a Screen. Thus rename it to
xnestScreenCursorFuncKeyRec to make it bit more clear.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1342>
Slightly simplifies the callers since they don't need to check for
non-NULL anymore.
I do extremely hate the workarounds here to suppress misprite taking the
cursor down though. Surely there's a better way.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Xnest variant of ModifyPixmapHeader that creates new Pixmap in parent X
server if it's size is modified from 0x0 to anything bigger.
xnestCreatePixmap doesn't create pixmap in parent X server if it has
dimensions 0x0. If it is later resized and accessed, Xnest will be
aborted with BadDrawable error from parent X server because it will
use XID 0. This happens with ScratchPixmap, for example as used from
XaceCensorImage. Applications using XACE crash Xnest.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Collin
Enrico Weigelt, metux IT consult
Tom Yan
Adam Jackson
Alan Coopersmith
Michal Srb