On certain setups, it might still be useful to force a particular cursor
size via xorg.conf.
For example, if on a system the automatic probes fail, or if the user wants
a particular cursor size, that is higher that the minimum size.
Signed-off-by: stefan11111 <stefan11111@shitposting.expert>
On most cards, SIZE_HINTS isn't available.
Without this, most users would have to set the fallback cursor size themselves,
or rely on the 64x64 default.
Signed-off-by: stefan11111 <stefan11111@shitposting.expert>
For cpu_family(), meson returns "sparc" for 32-bit sparc,
and "sparc64" for 64-bit sparc, regardless of the OS in use.
For cpu(), meson returns values like "sun4v" on Solaris/SPARC,
and doesn't promise stability of the values, or portability across
OS'es, unlike cpu_family().
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2070>
There is no explanation for these values, but the one we are
currently using doesn't work.
Use the values from vendor-speciffic drivers, which do work.
Signed-off-by: stefan11111 <stefan11111@shitposting.expert>
Don't rely on this file just being included indirectly by somebody else
just by accident.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
iterating over screen list via lambda-esque macros calls like this
DIX_FOR_EACH_SCREEN({
do_something
});
withing the body, the iterator variables `walkScreenIdx` and `walkScreen`
are defined and can be directly used (read-only). the code inside the body
is running in a separate scope.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for having extra functions and redundant code when it can
be done with just few LoC.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
There's nothing actually do be done by the swapped dispatcher, the
original already does everything on its own.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for having lots of extra functions and redundant dispatcher,
when it can be done by directly inlining those few LoC.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
* the pScreenInfo isn't needed: we're always getting global screenInfo
passed in here (there's only one, globally, anyways)
* use the common iterator variable names
* handle first and auxillary screens all in the same loop
(we can just branch by idx)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by any external drivers, so no need to keep them in public
SDK headers. Since they're never used by drivers, it's effectively
not an ABI change, so can safely be done within ABI-25.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by any drivers, no no need to keep it in public SDK.
Since it's not used by drivers, it's effectively not an ABI change,
so can be done within ABI-25.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
these symbols aren't used by any external drivers (not even proprietary
Nvidia), so no need to keep them exported any longer:
* present_check_flips
* present_register_complete_notify
* present_can_window_flip
* uint32_t FakeScreenFps
Since it's not any *effective* ABI change, can go into current ABI-25 line.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The request handler already refusing non-local access, so no need
for any extra swapped handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The request handler already refusing non-local access, so no need
for any extra swapped handler.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Don't rely on this file just being included indirectly by somebody else
just by accident.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Don't rely on this file just being included indirectly by somebody else
just by accident.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Don't rely on this file just being included indirectly by somebody else
just by accident.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Move functions/macros dealing with request parsing or reply assembly/write
out of the big dix_priv.h into their own headers. This new header will also
get more of those function/macros soon (yet still in the pipeline).
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
According to linux's Documentation/admin-guide/devices.txt,
framebuffers are named /dev/fb[0-31].
As such, we have to handle 2 digit numbers in framebuffer devices.
Signed-off-by: stefan11111 <stefan11111@shitposting.expert>
The pci probe was broken already, lots of pci devices were not detected as such.
Since fixing it properly required a bit of extra code complexity,
and those devices would be detected on the fallback probe, I didn't
bother fixing it untill now.
However, there is another problem created by this.
The pci probe was accepting the device passed by the user without
doing any checks on it.
This means that in multi-card setups, fbdevhw might claim the
wrong pci slot.
Fixing this requires fixing the pci probe in order to try and determine
whether the device passed by the user is the same as the pci device
passed to the pci probe.
This commit fixes the pci probe.
If no device is passed by the user, the probe finds a pci framebuffer device.
If a device is passed, the pci probe only return TRUE if the pci device
passed to it is the same as the device passed by the user.
Signed-off-by: stefan11111 <stefan11111@shitposting.expert>
These xf86_num_platform_devices and xf86_platform_devices fields aren't
_X_EXPORTED, so no drivers can use them - and none are trying so.
Thus move them to internal / non-sdk header.
Not an ABI change.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
We often use very large cursor sizes, compared to the sizes of the
curor glyphs, e.g. 64x64 cursors and 16x16 or smaller glyphs.
This patch makes is so that we only paint the size of the new
cursor glyph and clear the old one if needed, instead of painting
the entire cursor buffer, which is often far larger than the glyphs.
Signed-off-by: stefan11111 <stefan11111@shitposting.expert>
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>
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>
