It's a counter and size value - we're getting lots of signedness warnings,
so use size_t instead of (signed) int.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used anywhere else than just once in this header, so we can directly
inline it. Also adding explicit typecast to silence signedness warning.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The X11 protocol defines the sequenceNumber reply fields as `CARD16`, but the
Xserver is traditionally sloppy and using just `int`. Need to explicitly cast,
in order to silence compiler warnings.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Callers usually need this value as CARD32 (the X11 protocol's native type
of the .length header field), so convert it here in order to reduce
unnecessary compiler warnings.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
strlen() returns an size_t, but the string lengths here is limited to 16bit,
so we need to explictly cast, in order to shut down compiler warning.
Strings longer than 64k really shouldn't ever happen.
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>
this field is used a counter, thus should be unsigned, instead of having
dozens of signess warnings or adding casts to suppress them.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
GC's serialNumber field is unsigned int, but DrawableRec's is unsigned long,
so we need to typecast.
It would be better if they all had the same type, but we can't change them easily,
as that might cause ABI break.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
These values are assigned to `unsigned short` fields, and we're only
getting in smaller numbers that fit well into it. So fixing compiler
warning on type size mismatch by using short args.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
We're trying to use size_t for sizes whereever possible, but WriteToClient()
is part of ABI, so we can't fix it's parameter types - need to explicitly
cast, in order to silence the compiler warnings.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
> In file included from ../Xext/xvdisp.c:33:
> ../Xext/xvdisp.c: In function ‘ProcXvQueryImageAttributes’:
> ../Xext/xvdisp.c:768:19: warning: typedef ‘int_size_wrong_’ locally defined but not used [-Wunused-local-typedefs]
> 768 | __size_assert(int, sizeof(INT32));
> | ^~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Use x_rpcbuf_t for reply payload assembly and X_SEND_REPLY_WITH_RPCBUF()
for sending it all out.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
rename them to indicate that they're not the global payload buffer,
but temporary childs for sub-replies.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
These were global variables that were tracking how many
slots of one kind were claimed by drivers,
or if slots of one kind were claimed by drivers.
There were used inconsistently, sometimes they were `int`'s,
sometimes they were `Bool`'s.
All they were doing was to kill the server in various circumstances,
that were often incorrect and lead to bug reports, and guard against
a very speciffic kind of driver code error in `xf86ClaimFbSlot`,
that was also prone to false-positives.
Now that both these uses were removed,
these globals are no longer used, so we can remove them.
Signed-off-by: stefan11111 <stefan11111@shitposting.expert>
The intent of both these checks, I assume,
is that drivers don't claim 2 slots at once (fb, pci, plarform).
If we actually want to implement checking like this,
we would have to put a {fb,pci,platform}SlotClaimed in each driver struct.
We could definitely do that, but it seems weird
to single out this error to protect against.
By design, drivers are able to execute arbitrary code.
Nothing is stopping them from doing `*(volatile char*)0=0;`
in preinit or in one of the probes.
If we do decide to keep these checks, we have to be careful of corner cases.
What happens if a driver is used with multiple cards, one pci one not?
We could also keep track of how many slots a driver claims,
and reject any further claims after the count reaches 1.
We would still have to make that counter per driver and per card.
Signed-off-by: stefan11111 <stefan11111@shitposting.expert>
f.d.o is failing too often in recent times, so switching to our
own mirrors at github.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
In DragonFlyBSD the host_machine.system() variable is set to 'dragonfly' and does not end with 'bsd'. Changed a check to correctly detect 'dragonfly' as a member of BSD OSs.
bsd/bsd_kmod.c is used for dealing with kernel modules on FreeBSD, enabled this file for DragonFlyBSD too, because they both have the same APIs in this context.
Signed-off-by: b-aaz <b-aazbsd@proton.me>
The cursor pitch can depend on crtc.
Since we only use the sizes reported by SIZE_HINTS,
we can allocate a small cache for pitches in each crtc.
Signed-off-by: stefan11111 <stefan11111@shitposting.expert>
Nobody's using this pointer anymore, everybody's using the global
screenInfo structure.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have a hole bunch of extra functions, if we can just easily
inline the few relevant lines.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
arc4random_buf() is a pretty standard libc function on Unix'oid platforms,
but not all our targets have it, thus we need a fallback there. Currently we
have GenerateRandomData(), which either just wraps arc4random_buf() or provides
some fallback implementation.
For those cases it's easier to just implement missing functions directly
instead of having custom wrapper functions. So, drop GenerateRandomData()
in favor of arc4random_buf() and provide fallback implementation for where
it is missing.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Follow-up on renaming dixGetFirstScreenPtr() to dixGetMasterScreen():
also rename the target variables for correct technical terminology.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
In Xinerama/Panoramix configuration there's one screen that's having special
meaning - it's used for simulating as the frontend for all client operations:
the clients (should) only talk to that screen, while panoramix subsystem is
proxying those operations to all the other screens (with certain changed
applied, eg. coordinate transformations).
Historically, this screen happens to be the first one in the system (some of
it's proc's are hooked up in order to achieve desired behaviour). That's why it
used to be accessed via screenInfo.screens[0] - that already had been encapsulated
into a tiny helper `dixGetFirstScreen()`.
a) the correct terminus technicus for a situation where one device (or SW entity)
entirely controlling others is a master-slave-relationship: the controlling
device/entity is `master`, the controlled ones are `slave` (to that specific
master).
b) the term "first screen" is inacurate and misleading here: what the caller's are
actually interest in isn't the first entry in the screen array, but the screen
that's controlling the others. With upcoming refactoring of the Xinerama/Panoramix
subsystem, this might well be a different array index than 0.
c) the term `default` also wouldn't match: `default` implies there's a real practical
choice, and such value applies when no explicit choice has been made. But in this
case, it practically doesn't make sense (except perhaps for debugging purpose)
for a client to use any different screen.
Therefore fixing the function name to the correct technical terminology.
(for sake of patch readability, renaming corresponding variables is left to
subsequent patches).
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
