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>
function prototypes are by default always extern, so no need for
that extra qualifier.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The consumers always need to include <dix-config.h> at the very top
anyways, so no need to also include it (with extra guards) from
internal headers.
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>
All in-tree consumers already need to include dix-config.h on the very
top anyways, and there are no out-of-tree consumers (private to fb subsys)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
All in-tree consumers already need to include dix-config.h on the very
top anyways, and out-of-tree consumers don't have that include at all.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not supposed to be written to (once the pointer is assigned),
so should be marked const. Also document KdOsInit()
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
These will be used by subsequent commits for generic Kdrive
functions calling back into the OS specific parts
Signed-off-by: stefan11111 <stefan11111@shitposting.expert>
Kdrive X servers used to do the OS-speciffic init part using KdOsInit.
This was changed in modern Xorg because Xephyr is the only kdrive
X server there, so there was no need to keep this generic.
Since we want to eventually add Xfbdev, we need to add this back.
Signed-off-by: stefan11111 <stefan11111@shitposting.expert>
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>
