Retrieves the ClientPtr for the owner of given resource.
This way reducing the sites directly accessing clients[] array.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Make it type-safe and a bit more obvious what it really does,
also adding some inline documentation. Since it's just some
bit shifting magic, it's qualified for inlining.
The CLIENT_ID() macro isn't used by any external modules, so the
new function doesn't need to be in a public header.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Hide internals (drop the need to include windowstr.h), make it typesafe
as well as the naming easier to understand.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
XID = 0 already is used as sign for error in several places,
so let's use that here, too.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The old PCCONS driver only seems to be used on minimal install disks and
cannot coexist with newer ones (at least that's the feedback I've gotten
from BSD community), so there's probably no practical use case for
supporting it in Xorg anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Now that the name clash on GC type between Xserver and xlib has been fixed,
there's no need to do the special renaming hack anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Both xlib as well as the Xserver use the same identifier "GC" for
different types. While on xlib it's just the numerical ID of a GC,
the xserver defines a struct for it by the same name. This is this
ugly and needs ridiculous hacks for Xserver code that needs xlib.
Easy to solve by just renaming the GC typedef to GCRec (consistent
with how we're naming other structs) and replacing GC* by GCPtr.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The function actually operates on ClientRec, so we can pass it in
directly, so it doesn't need to fetch it from clients[] array itself.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by anybody, neither Xserver nor drivers, so no need to
keep it around any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using calloc() instead of malloc() as preventive measure, so there
never can be any hidden bugs or leaks due uninitialized memory.
The extra cost of using this compiler intrinsic should be practically
impossible to measure - in many cases a good compiler can even deduce
if certain areas really don't need to be zero'd (because they're written
to right after allocation) and create more efficient machine code.
The code pathes in question are pretty cold anyways, so it's probably
not worth even thinking about potential extra runtime costs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using calloc() instead of malloc() as preventive measure, so there
never can be any hidden bugs or leaks due uninitialized memory.
The extra cost of using this compiler intrinsic should be practically
impossible to measure - in many cases a good compiler can even deduce
if certain areas really don't need to be zero'd (because they're written
to right after allocation) and create more efficient machine code.
The code pathes in question are pretty cold anyways, so it's probably
not worth even thinking about potential extra runtime costs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using calloc() instead of malloc() as preventive measure, so there
never can be any hidden bugs or leaks due uninitialized memory.
The extra cost of using this compiler intrinsic should be practically
impossible to measure - in many cases a good compiler can even deduce
if certain areas really don't need to be zero'd (because they're written
to right after allocation) and create more efficient machine code.
The code pathes in question are pretty cold anyways, so it's probably
not worth even thinking about potential extra runtime costs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using calloc() instead of malloc() as preventive measure, so there
never can be any hidden bugs or leaks due uninitialized memory.
The extra cost of using this compiler intrinsic should be practically
impossible to measure - in many cases a good compiler can even deduce
if certain areas really don't need to be zero'd (because they're written
to right after allocation) and create more efficient machine code.
The code pathes in question are pretty cold anyways, so it's probably
not worth even thinking about potential extra runtime costs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using calloc() instead of malloc() as preventive measure, so there
never can be any hidden bugs or leaks due uninitialized memory.
The extra cost of using this compiler intrinsic should be practically
impossible to measure - in many cases a good compiler can even deduce
if certain areas really don't need to be zero'd (because they're written
to right after allocation) and create more efficient machine code.
The code pathes in question are pretty cold anyways, so it's probably
not worth even thinking about potential extra runtime costs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using calloc() instead of malloc() as preventive measure, so there
never can be any hidden bugs or leaks due uninitialized memory.
The extra cost of using this compiler intrinsic should be practically
impossible to measure - in many cases a good compiler can even deduce
if certain areas really don't need to be zero'd (because they're written
to right after allocation) and create more efficient machine code.
The code pathes in question are pretty cold anyways, so it's probably
not worth even thinking about potential extra runtime costs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used anywhere, neither Xserver nor drivers, so no need to keep it anymore.
According to git history, it had been introduced introduced in 2003 (*1),
but never called (inside the Xserver) - unclear whether it ever had been
actually used somewhere.
*1) 9508a382f8
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
There doesn't seem to be any driver for these cards anymore,
so no need for trying to probe them anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
There doesn't seem to be any sungt driver anymore, so no need for
trying to probe those cards any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
There doesn't seem to be any suncg12 driver anymore, so no need for
trying to probe those cards any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
There doesn't seem to be any suncg8 driver anymore, so no need for
trying to probe those cards any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
There doesn't seem to be any suncg4 driver anymore, so no need for
trying to probe those cards any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
There doesn't seem to be any suncg2 driver anymore, no need for trying
to probe those cards any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
There doesn't seem to be any sunbw2 driver anymore, so no need for trying
to probe those cards any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's always enabled for very long time now (at least since meson transition),
there doesn't seem to be any need to ever disable it again. So we can reduce
code complexity by removing all the ifdef's.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new PostCreateScreenResources screen hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Right now, extensions that need to be called after the CreateScreenResources
proc had been run, must wrap the screen proc vector directly (all of them
forming kind of daisy chain), and so - when called - temporarily restore the
previous one, call it, wrap again, and if the call was successful finally
doing it's own stuff. (same is done for many other procs)
While that approach is looking nice and elegant on the drawing board, it's
complicated, dangerous like a chainsaw and makes debugging hard, leading to
pretty blurred API borders.
Instead introducing a simple approach for letting extension hook into a
post-CreateScreenResources callback list safely, w/o having to care much
about side effects with the call chain. Extensions now can simply register
their business logic and get called back - w/o ever having to mess with the
ScreenRec's internal structures.
Note that these hooks are executed *AFTER* the original CreateScreenResources()
proc had been called SUCCESSFULLY (returned TRUE), so callees can rely on
the DDX/driver had already done it's job.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
This one doesn't look so trivial at first glance, but I've checked that
other functions called by xf86CrtcCloseScreen() just free'ing up some
memory and removing the CRTCs from some lists - thus a change in
execution order really shouldn't matter at all.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Right now, extension specific actions on screen closing implemented by wrapping
the ScreenRec's PositionWindow() proc pointer: the extensions are storing the
original pointer in their private data and putting in their own one. On each
call, their proc restores the original one, calls it, and switches back again.
When multiple extensions doing so, they're forming a kind of daisy chain.
(the same is done for lots of other procs)
While that approach is looking nice and elegant on the drawing board, it's
complicated, dangerous like a chainsaw and makes debugging hard, leading to
pretty blurred API borders.
This commit introduces a simple approach for letting extension hook into the
screen closing path safely, w/o having to care much about side effects with
the call chain. Extensions now can simply register their hook proc (and an
opaque pointer) and get called back - w/o ever having to mess with the
ScreenRec's internal structures. These hooks are called before the original
vector (usually handled by DDX/screen driver directly) is called.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new window destructor hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new window destructor hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new window destructor hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new window destructor hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
xwin relies on mi_priv.h being included indirectly, thus depending
on exact include within other header files. This can easily break if
something in other headers slightly changes.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The symbol isn't set anywhere, and git history didn't show anything
were it ever had been set, thus no need to keep this.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for complicated wrapping/unwrapping: it's always just
miCreateResources() anyway - so we can call it directly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to wrap CloseScreen proc vector, we can call KdCloseScreen() from
KdXVCloseScreen() directly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to wrap CloseScreen proc vector, we can call fbCloseScreen() from
KdCloseScreen() directly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for complicated wrapping/unwrapping: it's always just
miCreateResources() anyway - so we can call it directly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for complicated wrapping/unwrapping: it's always just
miCreateResources() anyway - so we can call it directly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This wrapping function for Screen->ResizeWindow() is does nothing more than
just call the original functions. So no need to keep wrapping it at all.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This proc vector is optional (callers check for non-null) and neither fb nor
mi set it, so we can just assign our function directly. No need for wrapping.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This proc vector is optional (callers check for non-null) and neither fb nor
mi set it, so we can just assign our function directly. No need for wrapping.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This wrapping function for Screen->CopyWindow() is does nothing more than
just call the original functions. So no need to keep wrapping it at all.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Both engines, GDI as well as DirectDraw, using the same screen init finish function,
so no need to keep indirection via per-engine callback pointer.
The winFinishScreenInitFB() can also be made static now.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It does nothing more than just calling the original/wrapped function,
so we don't need that at all.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It does nothing more than just calling the original/wrapped function,
so we don't need that at all.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for complicated wrapping/unwrapping: it's always just
miCreateResources() anyway - so we can call it directly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used anywhere, neither internal nor external.
(BTW, those defines are only used within xf86-video-fbdev, so they maybe
could be moved over there.)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used anywhere, neither internal nor external (drivers), so no need
to keep it any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used anywhere, neither internal nor external (drivers), so no need
to keep it any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used anywhere, neither internal nor external (drivers), so no need
to keep it any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used anywhere, neither internal nor external (drivers), so no need
to keep it any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used anywhere, neither internal nor external (drivers), so no need
to keep it any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by any external consumers, only within the same source file,
so can become static.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This header has now become obsolete. There're also no external consumers
(drivers, etc) left, so it now finally can be dropped entirely.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Even if those situations shouldn't practically happen, it's better to have
some sanity checks just in case.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's safer not relying on all ScreenProc's actually filled.
../dix/events.c: In function ‘CheckPhysLimits’:
../dix/events.c:780:14: warning: dereference of NULL ‘pScreen’ [CWE-476] [-Wanalyzer-null-dereference]
780 | (*pScreen->SetCursorPosition)
| ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The pointer to the window properties is currently inside the WindowOptional
structure, which may or may not exist at any given time. Thus, before accessing
those fields, at least need to check whether it exists, potentially need to
create it first.
Since a pointer is small (in relation to WindowRec) and windows having properties
is a pretty common, we can make our life much simpler here by moving the pointer
directly into WindowRec, so we don't need extra WindowOptionalRec allocation.
This also fixes an analyzer warning on potential NULL dereference issue:
| ../dix/property.c: In function ‘dixChangeWindowProperty’:
|../dix/property.c:343:37: warning: dereference of NULL ‘*pWin.optional’ [CWE-476] [-Wanalyzer-null-dereference]
| 343 | pProp->next = pWin->optional->userProps;
| | ~~~~~~~~~~~~~~^~~~~~~~~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Be more cautious on possible NULL pointers or not yet registered
devPrivates. Better a gracefully fail instead of hard segfault.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Even though it *should* never be actually hit, it's still safer
to check for NULL instead of letting us crash with segfault.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Even though it's unlikely ever getting it, still safer to have some
extra checks / asserts than unexpected segfault.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Safer (and easier to understand) if we look at the result pointer
instead of the counter for testing whether device wasn't found.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Better try to handle memory allocation gracefully than just hard
crashing by segfault.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Even though chances are really low it's ever getting hit, it's still safer
to have some sanity checks (which don't cost us much) than risking segfault.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
There's (remote) chance that the (internal) module name could become
NULL (eg. allocation failure). Even though chances to hit it are very
low, it's still better to have a check here (that doesn't cost us much),
just in case. Assert fail is still better than segfault, since we're
at least getting some hint what might have happened.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Adding paranoid extra checks against allocation failure and NULL pointers.
Even though might not be actually hit in practise, it's still better to
be cautious, just in case. And reducing analyzer noise this way.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The analyzer warnings (possible NULL dereference) are probably just
false alarms. But for safety adding assert()'s, which don't cost us
anything in non-debug builds.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's only rarely used and can be easily achieved by generic means,
eg. via ulimit or supervisor settings.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
A slight change in include order can cause Xlib to be included and defining
"GC" type, which is conflicting with Xserver's own type by same name.
As long as MR !1393 hasn't merged yet, we need to do an ugly workaround
using some preprocessor black magic.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It doesn't serve any practical purpose anymore and also isn't included
by any external driver, thus also no need to keep it in SDK.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Protecting against NULL pointers and allocation failures.
Printing out a bug warning in those cases.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's now only a wrapper calling xf86PostKeyEvent(), and no external driver
using it anymore, so we can drop it entirely.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This never seemed to be actually enabled, just ifdef'ed out, so no
need to keep it around any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by any drivers, so no need to keep it exported.
Also spending it for a better fitter name.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The include has become empty now. Not used by any external drivers,
so it can be dropped now.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
* not used by any external drivers, so no need to keep it exported
* choose better fitting name: InputDevGetSpriteCursor()
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Gets rid of many warnings from `mandoc -T lint` of the form:
mandoc: ./man/Xserver.man:621:7: STYLE: whitespace at end of input line
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2009>
Xwayland has its own XYToWindow() handler to account for the case when
the pointer leaves an X11 surface to enter another Wayland native window
(which of course are unknown to Xwayland).
When that occurs, Xwayland will treat it as if the pointer had entered
the root window so that the X11 clients receive an appropriate leave
event.
When the pointer leaves the X11 surface, Xwayland will call
CheckMotion() to update the sprite coordinates and possibly the cursor.
However, CheckMotion() will call back into the XYToWindow() handler,
which will then pretend the window has entered the root window, and that
may cause the wrong cursor to be applied.
To avoid the issue, change the order we do things, by calling
CheckMotion() first prior to clear up the internal focus window so that
the first call to XYToWindow() will return the correct X11 window so we
get to update the cursor correctly.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1811
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1915>
Found by clang 19.1.7:
hw/xfree86/drivers/modesetting/driver.c:163:21:
warning: initializer overrides prior initialization of this subobject
[-Winitializer-overrides]
163 | ._modinfo1_ = MODINFOSTRING2,
| ^~~~~~~~~~~~~~
hw/xfree86/drivers/modesetting/driver.c:162:21:
note: previous initialization is here
162 | ._modinfo1_ = MODINFOSTRING1,
| ^~~~~~~~~~~~~~
Fixes: 2a10eff6c ("xfree86: modsetting: use explicit field initializers for XF86ModuleData")
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1910>
Clears warning from clang 19.1.7:
hw/xfree86/common/xf86DefModeSet.c:288:62:
warning: no newline at end of file [-Wnewline-eof]
288 | const int xf86NumDefaultModes = ARRAY_SIZE(xf86DefaultModes);
| ^
Fixes: 3bf7ff703 ("Size xf86DefaultModes explicitly.")
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1910>
The WriteReplyToClient() macro is used for cases where byte swapping
is implemented in a separate callback function (set in a global vector
table). Since Xwl extension doesn't have such a callback, but does the
byte swapping directly in it's request handlers, there's no need to
call the WriteReplyToClient() macro - we can use WriteToClient() instead.
Fixes: 2700bc6045 - xwayland: add support for the XWAYLAND extension
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1878>
Use the correct macro for the font change of a single argument or
split the argument into two.
43:.BI Keyboard
46:.BI Pointer
52:.BI PointerAbsolute
58:.BI PointerAbsoluteProximity
62:.BI Touch
103:.BI xf86ITEventWaitForSync
-.-.
Wrong distance between sentences in the input file.
Separate the sentences and subordinate clauses; each begins on a new
line. See man-pages(7) ("Conventions for source file layout") and
"info groff" ("Input Conventions").
19:server as input events. It supports the full set of the xf86 driver APIs
20:exposed by Xorg. The primary use cases of this input driver are various
29:is created after the driver is initialized. The paths to the socket is passed
37:Sets the path where the driver will create a named socket. Any existing file
47:Initializes a relative-mode pointer device. It will have four valuators -
53:Initializes an absolute-mode pointer device. It will have four valuators -
87:specifies the protocol version supported by it. If this version is lower than
91:to the driver. Each event is an instance of one of the
93:structs. The length field defines the full length of the struct in bytes and
96:The responses from the server follow the same structure. Each response is an
99:structs. The length field defines the full length of the struct in bytes and
104:event. After sending such event, the client must read of a
106:events. The completion of the read operation indicates that Xorg has fully
-.-.
The name of a man page is typeset in bold and the section in roman
(see man-pages(7)).
24:Please refer to xorg.conf(5) for general configuration
112:Xorg(1), xorg.conf(5), Xserver(1), X(7)
-.-
Additionally:
"read of a xf86... event" -> "read an xf86... event"
Originally from: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1095449
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1875>
Wrong distance between sentences in the input file.
Separate the sentences and subordinate clauses; each begins on a new
line. See man-pages(7) ("Conventions for source file layout") and
"info groff" ("Input Conventions").
Mark a final abbreviation point as such by suffixing it with "\&".
25:Disables acceleration of uploading pixmap data to the framebuffer. Default: No.
-.-.
Split a punctuation mark from a single argument for a two-font macro
40:.BR xorg.conf(5).
-.-.
Section headings (.SH and .SS) do not need quoting.
38:.SH "SEE ALSO"
-.-.
Output from "test-groff -mandoc -t -K utf8 -rF0 -rHY=0 -rCHECKSTYLE=10 -ww -z ":
an.tmac:<stdin>:40: misuse, warning: .BR is for at least 2 arguments, got 1
Use macro '.B' for one argument or split argument.
Originally from: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1095446
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1875>
In order to be able to build on Linux w/ platform_noop
(when no recent enough libdrm found), a few more dummy functions
are needed here.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1848>
even through this specific case is correct and safe, it's safer to
remove all VLA usages and forbid them completely by compiler flag.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1819>
Not used by any external modules, so no need to keep it in public API.
Since it's used by DRI, still needs the _X_EXPORT flag, as long as DRI
is a dynamically loaded module.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1790>
Even though the order of these fields shouldn't change anytime
soon, it's still better programming style to name'em explicitly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1788>
Even though the order of these fields shouldn't change anytime
soon, it's still better programming style to name'em explicitly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1788>
Even though the order of these fields shouldn't change anytime
soon, it's still better programming style to name'em explicitly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1788>
Even though the order of these fields shouldn't change anytime
soon, it's still better programming style to name'em explicitly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1788>
Even though the order of these fields shouldn't change anytime
soon, it's still better programming style to name'em explicitly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1788>
Even though the order of these fields shouldn't change anytime
soon, it's still better programming style to name'em explicitly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1788>
Even though the order of these fields shouldn't change anytime
soon, it's still better programming style to name'em explicitly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1788>
Even though the order of these fields shouldn't change anytime
soon, it's still better programming style to name'em explicitly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1788>
Even though the order of these fields shouldn't change anytime
soon, it's still better programming style to name'em explicitly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1788>
Even though the order of these fields shouldn't change anytime
soon, it's still better programming style to name'em explicitly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1788>
Even though the order of these fields shouldn't change anytime
soon, it's still better programming style to name'em explicitly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1788>
Even though the order of these fields shouldn't change anytime
soon, it's still better programming style to name'em explicitly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1788>
Multiple CRTCs can be added on a per-screen basis with the new -crtcs
option. Each CRTC has one associated output. Outputs beyond the first
are disabled by default and can be enabled by setting a mode. Outputs
can be disabled again by setting the associated CRTC's mode and output
to None.
Signed-off-by: Andy Myers <andy.myers@zetier.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1749>
<X11/Xdefs.h> is needed for `Bool` type.
Consumers shouldn't have to rely on Xdefs.h being accidentally included
by something else.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1782>
Enrico Weigelt, metux IT consult
Alan Coopersmith
Olivier Fourdan
Bjarni Ingi Gislason
Tanguy Ortolo
Peter Hutterer
Doug Brown
Andy Myers
Aki Sakurai
Spiky Caterpillar