The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The authorative source of the request frame size is client->req_len,
especially with big requests larger than 2^18 bytes.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The authorative source of the request frame size is client->req_len,
especially with big requests larger than 2^18 bytes.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The authorative source of the request frame size is client->req_len,
especially with big requests larger than 2^18 bytes.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The authorative source of the request frame size is client->req_len,
especially with big requests larger than 2^18 bytes.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The authorative source of the request frame size is client->req_len,
especially with big requests larger than 2^18 bytes.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The authorative source of the request frame size is client->req_len,
especially with big requests larger than 2^18 bytes.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The authorative source of the request frame size is client->req_len,
especially with big requests larger than 2^18 bytes.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The authorative source of the request frame size is client->req_len,
especially with big requests larger than 2^18 bytes.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The authorative source of the request frame size is client->req_len,
especially with big requests larger than 2^18 bytes.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
XServer refuses the create windows with different color depth than the parent's,
just in the special case that neither border pixmap nor border pixel is given,
even if the screen supports it. (that's also one of the reasons why Xnest fails
to run with different color depths than the default one)
it really doesn't make sense to deny this, while it's allowed when having a
border color or pixmap set.
Fixes: ded6147b - R6.6 is the Xorg base-line
Closes:https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1644
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
ProcRRGetScreenResources() vs. RRGetScreenResourcesCurrent() have different
semantics - this also must be followed in byte-swapped case.
Fixes: fc70839431 - Add server support for RRGetScreenResourcesCurrent
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The array size is determined on compile time, so no need to use a vla
which always has the same size anyways.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The backtrace buffer size (BT_SIZE) is determined by compile time,
so we can change BT_SIZE into a #define to turn vla into fixed array.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have duplicated byte swapping macros in GLX for things that
the core alreay provides. Using core's macros is actually even easier.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
We now have two copies of the same write path in both swapped and
non-swapped branch. One is enough.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The reply length (in units as well as bytes) can safely be determined
at compile time, by using sizeof() operator. No need for unnecessarily
complicated shifting bits back and forth.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The spec defines the reply as array of "CARD32", not "int". The latter
just accidentially has the same type (for now :o), but it's *semantically*
incorrect. Using CARD32 instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Our array here really is fixed, but it's size is determined by a variable
(that's assigned a fix values), unncessarily making it a VLA (even making
it const doesn't change that), so giving false alarms when compiling w/
-Wvla or -Werror=vla.
Replacing the variable by #define trivially fixes this.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The reply struct's size can safely be determined by the sizeof()
operator, so no need for using an extra define here. Making the code
easier to read and also open the door for future convenience macros
that might determine the buffer size on their own.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Assigning structs at declaration is quicker to read/understand. No need
to support ancient compilers that couldn't do that, anymore.
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>
Now that no Xlib operations (besides opening and closing connection)
aren't used anymore, we can move over the last pieces and use XCB
instead of Xlib for connecting the upstream Xserver.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Now that no X11 calls are being done via Xlib anymore, we're free to
also move over event receiving, leaving Xlib pretty much unused.
Also need to add a simple event queue mechanism, because we've go a
screen operation (see xnestBitBlitHelper) that needs to collect up
certain events for it's return value.
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>
Enrico Weigelt, metux IT consult