Instead of everybody directly accessing the (internal) screenInfo struct,
let those consumers only interested in first screen use a little helper.
Also caching the value if it's needed several times.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
In preparation of upcoming screen iterator macros, compactify the
loop body a little bit. This function is so cold that it's not
really worth caching the screen's root window pointer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The macro will automatically return BadAlloc if the buffer is broken,
otherwise Success. Thus, we don't need extra prior rpcbuf check.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The Xi protocol has some pretty unclean design aspect: instead of adding a
new sub-request type, version 2.2 introduced a different request structure
with some extra fields. So depending on which version the client has selected,
we need to operate on separate structs.
In the current implementation, there's a unclean hack by using the extended
structure and only accessing the extra fields when using v2.2 or above.
Even though this works, it's making the code unnecessarily complicated and
blocking the use if canonical request parsing macros (which are coming with
subsequent commits).
Thus, it's time to clean it up and only use the exactly correct structs
in the two different cases. The trick is just branching by version and pick
out the the interesting values from the corresponding structs, so they can
later be used in the (mostly) version independent part.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Use x_rpcbuf_t also for writing individual fields and so let it also
do the byte-swapping.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
For better readability, declare the variables only where they're used,
and try to scope them, instead of declaring them all on the very top.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The code below the `out` label is using the rpcbuf variable, but we have
a jump site before the variable is declared. It had been overlooked, because
for yet unknown reasons the compiler doesn't complain at all about this.
We could assume that it at least moves the stack allocation upwards
(always could even happen even on function entry), but we don't know whether
the memory is already unitialized.
So, to be on safe-side, move the declaration upwards, before the first
jump site.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
When iterating screen lists, consistently use the same variable name
`walkScreen` for holding current screen pointer everywhere.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The client index (in the client table) can never be negative, thus
make it an unsigned short.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Use x_rpcbuf_t for reply payload assembly and byte-swap, instead of
writing in little pieces via complicated callbacks.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Skip allocation of temporay buffer for the atom IDs, instead walk through
the property list and write the IDs directly into the rpcbuf.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
x_rpcbuf_t allows easy accumulation of payload data and doing byteswap
(when necessary) at the same time.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Use x_rpcbuf_t for reply payload assembly and byte-swap, instead of
writing in little pieces via complicated callbacks.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Use x_rpcbuf_t for reply payload assembly and byte-swapping, instead
of writing in little pieces via complicated callbacks.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Use x_rpcbuf_t for reply payload assembly and byte-swapping, instead of
writing in little pieces via complicated callbacks.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This symbol is always defined, and the header is always present,
so no need to check for it.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The `types` variable is never used, just assigned NULL - and that NULL
value is passed to free(). This code is really doing nothing, never did so
since introduced in 2009.
Fixes: 8b6a370058
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The assert(iclients) was in a place where the iclients variable could
not have been initialized ever - the first assignment is done *after* that.
Since we already have a BUG_RETURN_VAL() right be before it's actually
dereferenced, there's no need for that assert() at all - so drop it.
See https://github.com/X11Libre/xserver/issues/330
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Fixes this build error on arch linux:
../Xi/exevents.c:1394:26: error: array subscript ‘InternalEvent {aka union _InternalEvent}[0]’ is partly outside array bounds of ‘DeviceEvent[1]’ {aka ‘struct _DeviceEvent[1]’} [-Werror=array-bounds=]
1394 | evtype = GetXI2Type(ev->any.type);
| ^~~~~~~~~~~~~~~~~~~~~~~~
../Xi/exevents.c: In function ‘DeliverEmulatedMotionEvent’:
../Xi/exevents.c:1571:17: note: object ‘motion’ of size 432
1571 | DeviceEvent motion;
|
which happens because of change in build options compared to master and gcc 15.1 in arch. I think this warning (and error) is a bug in gcc.
gcc 15.1 doesn't like when struct DeviceEvent is cast to union InternalEvent.
InternalEvent has a union any type and DeviceEvent type and these have to have a matching structure (for the header part).
When the InternalEvent is used in RetrieveTouchDeliveryData function it access the any field, which accessed the data defined previously in the device_event fields.
This change matches how its done in touch.c TouchEmitTouchEnd for example and it's "more correct",
since we are no longer casting from a smaller struct (DeviceEvent) to a larger struct (InternalEvent) when calling RetrieveTouchDeliveryData.
Signed-off-by: dec05eba <dec05eba@protonmail.com>
When looking up the window to select on and security hook returns
BadAccess, the request is just silently ignored, instead of rejected.
This way, security hook can prevent untrusted clients to listen on
arbitrary windows, without the client even noticing. The client won't
get this BadAccess error, but instead thinking everything's fine,
just not getting the actual events.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
