Adding convenience function for writing out rpc buffer contents to
client and clear the buffer (free it's memory) afterwards.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The size of `int` is machine specific and may be 64 bits wide, which could
overflow the calloc'able size. Practically cannot happen here, since the
ListenTransCount can't go above MAX_CONNECTIONS, but compiler can't know
that and so spitting out a warning.
Using uint32_t really is sufficient here.
> ../os/connection.c: In function ‘CreateWellKnownSockets’:
> ../os/connection.c:274:22: warning: argument 1 range [18446744071562067968, 18446744073709551615] exceeds maximum object size 9223372036854775807 [-Walloc-size-larger-than=]
> 274 | ListenTransFds = calloc(ListenTransCount, sizeof(int));
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Since TRANS() now will always expand the same, it's better for
maintenance, having the function names written explicitly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
These are always enablde (x11_t is defined when XSERV_t is defined),
so no need for the #ifdef's anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The existing x_rpcbuf_write_string() function is just writing the string w/o
trailing zero. It's for cases where the string length is known by other means
(eg. some header field). In cases where we also need the trailing zero written
(eg. when sending lists of strings) this isn't sufficient.
Thus introducing another variant of this function, which is always writing
a leading zero. Using this one, the string's characters will be followed
by 1, 2 or 3 zeros (and also be 32bit aligned)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
when the err_clear flag is set, the buffer memory will automatically
be free()ed when allocation failed. This allows simplificatoin of
caller's error pathes: the caller doesn't need to to call x_rpcbuf_clear()
anymore and eg. can directly return out.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Remember allocation failure in new `error` field, for easing error
handling in complex callers: those now don't need to check each single
return value, but can (try to) continue their normal operation and
check for error condition later.
For example we can turn this:
for (....) {
if (!x_rpcbuf_write_CARD16(&rpcbuf,...)) {
[ various cleanups ]
return BadAlloc;
}
if (!rpcbuf_write_CARD8s(&rpcbuf,...)) {
[ various cleanups ]
return BadAlloc;
}
[ more of this ]
}
...
Into:
for (....) {
x_rpcbuf_write_CARD16(&rpcbuf,...));
x_rpcbuf_write_CARD8s(&rpcbuf,...));
[ more of this ]
}
...
if (&rpcbuf->error) {
[ various cleanups ]
return BadAlloc;
}
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Since so many request handlers have to assemble complex reply payloads,
we've got a lot complexity on counting the needed space and filling in
the data into the right places.
Thus adding a little dynamic buffer structure, where one just can append
data arbitrarily. The buffer will automatically allocate memory as-needed
and finally leave everything in a big memory block for later write-out.
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>
X has various ways to deal with DPI but all of the current methods have
some drawback (single global value, manually calculating from physical
dimensions, etc.) What is lacking is a simple value per output that
users and applications can use to communicate desired scaling values.
Fortunately, a generic output property mechanism already exists. And
they already send events whenever there is a change. So all we have to
do is make an "official" property for people to agree on and enshrine
it. In that case, all outputs can just always have the DPI property set
to something. In most cases, this will be 96 (the default), but one
could use the -dpi argument when launching or and that value will be
used instead. The intention is that 96 is the base that is equivalent to
1x scaling. i.e. 192 would be 2x, 144 would be 1.5x and so on. xrandr or
any other utility can modify this property at any time and applications
can choose to use the number in a way that makes sense.
Closes#208. Credit to @dec05eba for essentially coming up with the idea
of using output properties.
Signed-off-by: Dudemanguy <random342@airmail.cc>
Nvidia needs dma-buf for glamor acceleration to work
when using the modesetting ddx driver.
Signed-off-by: stefan11111 <stefan11111@shitposting.expert>
Port https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/751
to xlibre
Fixes glamor with modesetting on nvidia
This is needed for glamor to work with modesetting
on nvidia, according to the nvidia docs:
https://download.nvidia.com/XFree86/Linux-x86_64/510.39.01/README/gbm.html
From the mr above:
The X server was passing GBM bos directly to
eglCreateImageKHR using the EGL_NATIVE_PIXMAP_KHR
target. Given the EGL GBM platform spec claims it
is invalid to create a EGLSurface from a native
pixmap on the GBM platform, implying there is no
mapping between GBM objects and EGL's concept of
native pixmaps, this seems a bit questionable.
This change modifies the bo import function to
extract all the required data from the bo and then
imports it as a dma-buf instead when the dma-buf +
modifiers path is available.
Signed-off-by: stefan11111 <stefan11111@shitposting.expert>
