fdo-mirrors/xserver
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/xorg/xserver.git synced 2025-12-20 01:10:03 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

Strip trailing whitespace from source files

Browse source 
Performed with: `git ls-files | xargs perl -i -p -e 's{[ \t]+$}{}'`

`git diff -w` & `git diff -b` show no diffs from this change

Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2074>
This commit is contained in:
Alan Coopersmith 2025-10-05 11:56:48 -07:00
parent 5210495f7d
commit d9389873d6
34 changed files with 332 additions and 332 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
Xext/xace.h
View file

@ -60,7 +60,7 @@ extern CallbackListPtr XaceHooks[XACE_NUM_HOOKS];
/* Entry point for hook functions. Called by Xserver.
* Required by libdbe and libextmod
*/
/* needs to be exported for in-tree modsetting driver, but not part
/* needs to be exported for in-tree modsetting driver, but not part
of public API for external modules */
_X_EXPORT int XaceHook(int hook, ... /* appropriate args for hook */);

2
config/10-quirks.conf
View file

@ -2,7 +2,7 @@
# Accelerometer device, posts data through ABS_X/ABS_Y, making X unusable
# http://bugs.freedesktop.org/show_bug.cgi?id=22442
# http://bugs.freedesktop.org/show_bug.cgi?id=22442
Section "InputClass"
Identifier "ThinkPad HDAPS accelerometer blacklist"
MatchProduct "ThinkPad HDAPS accelerometer data"

4
config/dbus-api
View file

@ -1,7 +1,7 @@
D-BUS Configuration API v2
----------------------------
The X server will register the bus name org.x.config.displayN, and the
The X server will register the bus name org.x.config.displayN, and the
object /org/x/config/N, where N is the display number.
Currently only hotplugging of input devices is supported.
@ -36,5 +36,5 @@ org.x.config.input:
X.h. See org.x.config.input.add. Error codes are negative numbers.
org.x.config.input.listDevices:
Lists the currently active devices. No argument.
Lists the currently active devices. No argument.
Return value is sequence of [<id> <name>] [<id> <name>] ..., i.e. [us].

32
config/x11-input.fdi
View file

@ -1,27 +1,27 @@
<?xml version="1.0" encoding="UTF-8"?>
<deviceinfo version="0.2">
<device>
<!-- The way this works:
Match against some input device (see the HAL specification for more
information), and then merge in keys, which you can use to specify
the configuration similar to the way you would in xorg.conf. You will
<!-- The way this works:
Match against some input device (see the HAL specification for more
information), and then merge in keys, which you can use to specify
the configuration similar to the way you would in xorg.conf. You will
need to restart HAL after making changes. If you are having issues,
starting X with the -logverbose 7 flag may yield useful information.
Keys Supported:
Key "input.x11_driver" (string)
This specifies the driver to use. You MUST specify this option,
or a driver will not be loaded and the rest will be ignored by
Xorg
Key "input.x11_options.<option name>" (string)
This allows you to specify arbitrary options to pass to the driver.
Anything you would normally specify in xorg.conf goes here. So, for
option "Mode" in xorg.conf, you would specify the key name of
"input.x11_options.Mode".
"input.x11_options.Mode".
Do not specify "input.x11_options.Device" since "input.device"
will be used automatically.
@ -35,7 +35,7 @@
"input.xkb.layout"
"input.xkb.variant"
"input.xkb.options"
These keys are deprecated. Use these instead:
"input.x11_options.XkbRules"
"input.x11_options.XkbModel"
@ -43,13 +43,13 @@
"input.x11_options.XkbVariant"
"input.x11_options.XkbOptions"
See the evdev documentation for more information.
FIXME: Support tablets too.
See the evdev documentation for more information.
FIXME: Support tablets too.
TODO: I think its fixed, can't test
-->
<match key="info.capabilities" contains="input.mouse">
<merge key="input.x11_driver" type="string">mouse</merge>
<match key="/org/freedesktop/Hal/devices/computer:system.kernel.name"

12
dix/BuiltInAtoms
View file

@ -133,7 +133,7 @@ RGB_COLOR_MAP @
compute a corresponding pixel value with the expression:
r * red_mult + g * green_mult + b * blue_mult + base_pixel
For gray-scale colormaps, only the colormap, red_max, red_mult,
and base_pixel fields are defined; the other fields are
ignored. To compute a gray-scale pixel value, use:
@ -273,7 +273,7 @@ SUBSCRIPT_Y @
UNDERLINE_POSITION @
Font property: INT32
UNDERLINE_THICKNESS @
Font property: CARD32
Font property: CARD32
STRIKEOUT_ASCENT @
Font property: INT32
STRIKEOUT_DESCENT @
@ -314,8 +314,8 @@ CAP_HEIGHT @
WM_CLASS @
Property name: (type: STRING)
Used (possibly by some window managers; definitely by
session managers) to look up resources in the resource
Used (possibly by some window managers; definitely by
session managers) to look up resources in the resource
data base on behalf of the client who set this property.
There are 2 elements:
{char *resource_name; char *resource_class;}
@ -323,7 +323,7 @@ WM_CLASS @
WM_TRANSIENT_FOR @
Property name: (type: WINDOW)
Used by transient top-level windows, such as dialog
boxes, to point to their logical "parents". The window
Used by transient top-level windows, such as dialog
boxes, to point to their logical "parents". The window
manager can then take down the dialog boxes when the
"parent" gets iconified, for instance.

220
doc/Xinput.xml
View file

@ -50,32 +50,32 @@ dard of the X Consortium and is therefore subject to change.
<title>X11 Input Extension Porting Document</title>
<para>
This document is intended to aid the process of integrating the
This document is intended to aid the process of integrating the
X11 Input Extension into an X server.
</para>
<para>
<!-- .LP -->
Most of the functionality provided by the input extension is
device- and implementation-independent, and should require no changes.
Most of the functionality provided by the input extension is
device- and implementation-independent, and should require no changes.
The functionality is implemented by
routines that typically reside in the server source tree directory
routines that typically reside in the server source tree directory
extensions/server/xinput.
This extension includes functions to enable and disable input extension devices,
select input, grab and focus those devices, query and change key
and button mappings, and others. The only input extension requirements
for the device-dependent part of X are that the input devices be
and button mappings, and others. The only input extension requirements
for the device-dependent part of X are that the input devices be
correctly initialized and input events from those devices be correctly
generated. Device-dependent X is responsible for reading input data from
generated. Device-dependent X is responsible for reading input data from
the input device hardware and if necessary, reformatting it into X events.
</para>
<para>
<!-- .LP -->
The process of initializing input extension devices is similar to that used
The process of initializing input extension devices is similar to that used
for the core devices, and is described in the following sections. When
multiple input devices are attached to X server, the choice of which devices
to initially use as the core X pointer and keyboard is left
to initially use as the core X pointer and keyboard is left
implementation-dependent. It is also up to each implementation to decide
whether all input devices will be opened by the server during its
whether all input devices will be opened by the server during its
initialization and kept open for the life of the server. The alternative is
to open only the X keyboard and X pointer during server initialization, and
open other input devices only when requested by a client to do so. Either
@ -95,10 +95,10 @@ events.
<title>Initializing Extension Devices</title>
<para>
<!-- .LP -->
Extension input devices are initialized in the same manner as the core
X input devices. Device-Independent X provides functions that can be
Extension input devices are initialized in the same manner as the core
X input devices. Device-Independent X provides functions that can be
called from DDX to initialize these devices. Which functions are called
and when will vary by implementation, and will depend on whether the
and when will vary by implementation, and will depend on whether the
implementation opens all the input devices available to X when X is initialized,
or waits until a client requests that a device be opened.
In the simplest case, DDX will open all input devices as part of its
@ -110,32 +110,32 @@ initialization, when the InitInput routine is called.
<!-- .LP -->
<literallayout class="monospaced">
Device-Independent X | Device-Dependent X
-------------------- | -------------------
|
-------------------- | -------------------
|
InitInput --------------&gt; | - do device-specific initialization
|
|
| - call AddInputDevice (deviceProc,AutoStart)
AddInputDevice |
AddInputDevice |
- creates DeviceIntRec |
- records deviceProc |
- adds new device to |
- adds new device to |
list of off_devices. |
sets dev-&gt;startup=AutoStart|
| - call one of:
sets dev-&gt;startup=AutoStart|
| - call one of:
| - RegisterPointerDevice (X pointer)
| - processInputProc = ProcessPointerEvents
| - RegisterKeyboardDevice (X keyboard)
| - processInputProc = ProcessKeyboardEvents
| - RegisterOtherDevice (extension device)
| - processInputProc = ProcessOtherEvents
|
|
|
|
InitAndStartDevices -----&gt; | - calls deviceProc with parameters
| (DEVICE_INIT, AutoStart)
sets dev-&gt;inited = return |
value from deviceProc |
|
| - in deviceProc, do one of:
value from deviceProc |
|
| - in deviceProc, do one of:
| - call InitPointerDeviceStruct (X pointer)
| - call InitKeyboardDeviceStruct (X keybd)
| - init extension device by calling some of:
@ -152,23 +152,23 @@ sets dev-&gt;inited = return |
| - InitIntegerFeedbackClassDeviceStruct
| - InitBellFeedbackClassDeviceStruct
| - init device name and type by:
| - calling MakeAtom with one of the
| - calling MakeAtom with one of the
| predefined names
| - calling AssignTypeAndName
|
|
for each device added |
by AddInputDevice, |
InitAndStartDevices |
calls EnableDevice if | - EnableDevice calls deviceProc with
|
|
for each device added |
by AddInputDevice, |
InitAndStartDevices |
calls EnableDevice if | - EnableDevice calls deviceProc with
dev-&gt;startup &amp; | (DEVICE_ON, AutoStart)
dev-&gt;inited |
|
dev-&gt;inited |
|
If deviceProc returns | - core devices are now enabled, extension
Success, EnableDevice | devices are now available to be accessed
move the device from | through the input extension protocol
inputInfo.off_devices | requests.
to inputInfo.devices |
inputInfo.off_devices | requests.
to inputInfo.devices |
</literallayout>
</para>
</sect2>
@ -216,7 +216,7 @@ InitInput(argc,argv)
DeviceProc kbdproc, ptrproc, extproc;
/**************************************************************
* Open the appropriate input devices, determine which are
* Open the appropriate input devices, determine which are
* available, and choose an X pointer and X keyboard device
* in some implementation-dependent manner.
***************************************************************/
@ -239,7 +239,7 @@ InitInput(argc,argv)
dev = AddInputDevice (ptrproc, TRUE);
RegisterPointerDevice (dev);
}
else
else
{
dev = AddInputDevice (extproc, FALSE);
RegisterOtherDevice (dev);
@ -256,7 +256,7 @@ InitInput(argc,argv)
<para>
<!-- .LP -->
After InitInput has returned,
InitAndStartDevices is the DIX routine that is called to enable input devices.
InitAndStartDevices is the DIX routine that is called to enable input devices.
It calls the device control routine that was passed to AddInputDevice,
with a mode value of DEVICE_INIT. The action taken by the device control
routine depends on how the device is to be used. If the device is to be
@ -271,7 +271,7 @@ input, and are described in the following sections.
</para>
<para>
<!-- .LP -->
A sample device control routine called from InitAndStartDevices is
A sample device control routine called from InitAndStartDevices is
shown below.
</para>
<para>
@ -299,7 +299,7 @@ Bool extproc (dev, mode)
InitValuatorClassDeviceStruct (dev, localdev-&gt;n_axes,);
motionproc, MOTION_BUF_SIZE, Absolute);
for (i=0; i&lt;localdev-&gt;n_axes; i++)
InitValuatorAxisStruct (dev, i, min_val, max_val,
InitValuatorAxisStruct (dev, i, min_val, max_val,
resolution);
InitFocusClassDeviceStruct (dev);
InitProximityClassDeviceStruct (dev);
@ -325,11 +325,11 @@ Bool extproc (dev, mode)
InitValuatorClassDeviceStruct (dev, localdev-&gt;n_axes,);
motionproc, MOTION_BUF_SIZE, Absolute);
for (i=0; i&lt;localdev-&gt;n_axes; i++)
InitValuatorAxisStruct (dev, i, min_val, max_val,
InitValuatorAxisStruct (dev, i, min_val, max_val,
resolution);
InitFocusClassDeviceStruct (dev);
}
localdev-&gt;atom =
localdev-&gt;atom =
MakeAtom(localdev-&gt;name, strlen(localdev-&gt;name), FALSE);
AssignTypeAndName (dev, localdev-&gt;atom, localdev-&gt;name);
break;
@ -350,8 +350,8 @@ Bool extproc (dev, mode)
<para>
<!-- .LP -->
The device control routine is called with a mode value of DEVICE_ON
by the DIX routine EnableDevice, which is called from InitAndStartDevices.
When called with this mode, it should call AddEnabledDevice to cause the
by the DIX routine EnableDevice, which is called from InitAndStartDevices.
When called with this mode, it should call AddEnabledDevice to cause the
server to begin checking for available input from this device.
</para>
<para>
@ -367,8 +367,8 @@ field is set by AddInputDevice to value of the second parameter (autoStart).
When the server is first initialized, it should only be checking for input
from the core X keyboard and pointer. One way to accomplish this is to
call AddInputDevice for the core X keyboard and pointer with an
autoStart value equal to TRUE, while calling AddInputDevice for
input extension devices with an autoStart value equal to FALSE. If this is
autoStart value equal to TRUE, while calling AddInputDevice for
input extension devices with an autoStart value equal to FALSE. If this is
done, EnableDevice will skip all input extension devices during server
initialization. In this case,
the OpenInputDevice routine should set the "startup" field to TRUE
@ -423,12 +423,12 @@ FeedbackClass - the device supports some kind of feedback.
<para>
<!-- .LP -->
DIX routines are provided to initialize the X pointer and keyboard, as in
previous releases of X. During X initialization, InitPointerDeviceStruct
previous releases of X. During X initialization, InitPointerDeviceStruct
is called to initialize the X pointer, and InitKeyboardDeviceStruct is
called to initialize the X keyboard. There is no
corresponding routine for extension input devices, since they do not all
support the same classes of input. Instead, DDX is responsible for the
initialization of the input classes supported by extension devices.
support the same classes of input. Instead, DDX is responsible for the
initialization of the input classes supported by extension devices.
A description of the routines provided by DIX to perform that initialization
follows.
</para>
@ -436,7 +436,7 @@ follows.
<title>InitKeyClassDeviceStruct</title>
<para>
<!-- .LP -->
This function is provided to allocate and initialize a KeyClassRec, and
This function is provided to allocate and initialize a KeyClassRec, and
should be called for extension devices that have keys. It is passed a pointer
to the device, and pointers to arrays of keysyms and modifiers reported by
the device. It returns FALSE if the KeyClassRec could not be allocated,
@ -464,10 +464,10 @@ that have keys.
<title>InitButtonClassDeviceStruct</title>
<para>
<!-- .LP -->
This function is provided to allocate and initialize a ButtonClassRec, and
should be called for extension devices that have buttons. It is passed a
pointer to the device, the number of buttons supported, and a map of the
reported button codes. It returns FALSE if the ButtonClassRec could not be
This function is provided to allocate and initialize a ButtonClassRec, and
should be called for extension devices that have buttons. It is passed a
pointer to the device, the number of buttons supported, and a map of the
reported button codes. It returns FALSE if the ButtonClassRec could not be
allocated. Its parameters are:
</para>
<para>
@ -491,11 +491,11 @@ have buttons.
<title>InitValuatorClassDeviceStruct</title>
<para>
<!-- .LP -->
This function is provided to allocate and initialize a ValuatorClassRec, and
This function is provided to allocate and initialize a ValuatorClassRec, and
should be called for extension devices that have valuators. It is passed the
number of axes of motion reported by the device, the address of the motion
history procedure for the device, the size of the motion history buffer,
and the mode (Absolute or Relative) of the device. It returns FALSE if
and the mode (Absolute or Relative) of the device. It returns FALSE if
the ValuatorClassRec could not be allocated. Its parameters are:
</para>
<para>
@ -521,14 +521,14 @@ report motion.
<title>InitValuatorAxisStruct</title>
<para>
<!-- .LP -->
This function is provided to initialize an XAxisInfoRec, and
should be called for core and extension devices that have valuators.
The space for the XAxisInfoRec is allocated by
This function is provided to initialize an XAxisInfoRec, and
should be called for core and extension devices that have valuators.
The space for the XAxisInfoRec is allocated by
the InitValuatorClassDeviceStruct function, but is not initialized.
</para>
<para>
<!-- .LP -->
InitValuatorAxisStruct should be called once for each axis of motion
InitValuatorAxisStruct should be called once for each axis of motion
reported by the device. Each
invocation should be passed the axis number (starting with 0), the
minimum value for that axis, the maximum value for that axis, and the
@ -547,7 +547,7 @@ InitValuatorAxisStruct(dev, axnum, minval, maxval, resolution)
<para>
<!-- .LP -->
This routine is not called by InitPointerDeviceStruct for the
core X pointer. It must be called explicitly for core and extension devices
core X pointer. It must be called explicitly for core and extension devices
that report motion.
</para>
</sect3>
@ -555,7 +555,7 @@ that report motion.
<title>InitFocusClassDeviceStruct</title>
<para>
<!-- .LP -->
This function is provided to allocate and initialize a FocusClassRec, and
This function is provided to allocate and initialize a FocusClassRec, and
should be called for extension devices that can be focused. It is passed a
pointer to the device, and returns FALSE if the allocation fails.
It has the following parameter:
@ -577,7 +577,7 @@ is left implementation-dependent.
<title>InitProximityClassDeviceStruct</title>
<para>
<!-- .LP -->
This function is provided to allocate and initialize a ProximityClassRec, and
This function is provided to allocate and initialize a ProximityClassRec, and
should be called for extension absolute pointing devices that report proximity.
It is passed a pointer to the device, and returns FALSE if the allocation fails.
It has the following parameter:
@ -597,8 +597,8 @@ InitProximityClassDeviceStruct(dev)
<title>InitKbdFeedbackClassDeviceStruct</title>
<para>
<!-- .LP -->
This function is provided to allocate and initialize a KbdFeedbackClassRec, and
may be called for extension devices that support some or all of the
This function is provided to allocate and initialize a KbdFeedbackClassRec, and
may be called for extension devices that support some or all of the
feedbacks that the core keyboard supports. It is passed a
pointer to the device, a pointer to the procedure that sounds the bell,
and a pointer to the device control procedure.
@ -621,7 +621,7 @@ and LedFeedbackClass feedbacks.
<title>InitPtrFeedbackClassDeviceStruct</title>
<para>
<!-- .LP -->
This function is provided to allocate and initialize a PtrFeedbackClassRec, and
This function is provided to allocate and initialize a PtrFeedbackClassRec, and
should be called for extension devices that allow the setting of acceleration
and threshold. It is passed a pointer to the device,
and a pointer to the device control procedure.
@ -644,7 +644,7 @@ that support the setting of acceleration and threshold.
<title>InitLedFeedbackClassDeviceStruct</title>
<para>
<!-- .LP -->
This function is provided to allocate and initialize a LedFeedbackClassRec, and
This function is provided to allocate and initialize a LedFeedbackClassRec, and
should be called for extension devices that have LEDs.
It is passed a pointer to the device,
and a pointer to the device control procedure.
@ -658,7 +658,7 @@ InitLedFeedbackClassDeviceStruct(dev, controlProc)
</para>
<para>
<!-- .LP -->
Up to 32 LEDs per feedback can be supported, and a device may have
Up to 32 LEDs per feedback can be supported, and a device may have
multiple feedbacks of the same type.
</para>
</sect4>
@ -666,7 +666,7 @@ multiple feedbacks of the same type.
<title>InitBellFeedbackClassDeviceStruct</title>
<para>
<!-- .LP -->
This function is provided to allocate and initialize a BellFeedbackClassRec,
This function is provided to allocate and initialize a BellFeedbackClassRec,
and should be called for extension devices that have a bell.
It is passed a pointer to the device,
and a pointer to the device control procedure.
@ -684,15 +684,15 @@ InitBellFeedbackClassDeviceStruct(dev, bellProc, controlProc)
<title>InitStringFeedbackClassDeviceStruct</title>
<para>
<!-- .LP -->
This function is provided to allocate and initialize a StringFeedbackClassRec,
and should be called for extension devices that have a display upon which a
This function is provided to allocate and initialize a StringFeedbackClassRec,
and should be called for extension devices that have a display upon which a
string can be displayed.
It is passed a pointer to the device,
and a pointer to the device control procedure.
It returns FALSE if the allocation fails, and has the following parameters:
<literallayout class="monospaced">
Bool
InitStringFeedbackClassDeviceStruct(dev, controlProc, max_symbols,
InitStringFeedbackClassDeviceStruct(dev, controlProc, max_symbols,
num_symbols_supported, symbols)
DeviceIntPtr dev;
void (*controlProc)();
@ -706,8 +706,8 @@ InitStringFeedbackClassDeviceStruct(dev, controlProc, max_symbols,
<title>InitIntegerFeedbackClassDeviceStruct</title>
<para>
<!-- .LP -->
This function is provided to allocate and initialize an
IntegerFeedbackClassRec,
This function is provided to allocate and initialize an
IntegerFeedbackClassRec,
and should be called for extension devices that have a display upon which an
integer can be displayed.
It is passed a pointer to the device,
@ -769,7 +769,7 @@ that device.
</para>
<para>
<!-- .LP -->
DisableDevice is not called by any input extension routines. It can be
DisableDevice is not called by any input extension routines. It can be
called from the CloseInputDevice routine, which is called by
ProcXCloseDevice when a client makes an XCloseDevice request. If
DisableDevice is called, it should only be called when the last client
@ -780,7 +780,7 @@ using the extension device has terminated or called XCloseDevice.
<title>Implementation-Dependent Routines</title>
<para>
<!-- .LP -->
Several input extension protocol requests have
Several input extension protocol requests have
implementation-dependent entry points. Default routines
are defined for these entry points and contained in the source
file extensions/server/xinput/xstubs.c. Some implementations may
@ -791,14 +791,14 @@ The following sections describe each of these routines.
<title>AddOtherInputDevices</title>
<para>
<!-- .LP -->
AddOtherInputDevice is called from ProcXListInputDevices as a result of
AddOtherInputDevice is called from ProcXListInputDevices as a result of
an XListInputDevices protocol request. It may be needed by
implementations that do not open extension input devices until requested
to do so by some client. These implementations may not initialize
all devices when the X server starts up, because some of those devices
may be in use. Since the XListInputDevices
function only lists those devices that have been initialized,
AddOtherInputDevices is called to give DDX a chance to
AddOtherInputDevices is called to give DDX a chance to
initialize any previously unavailable input devices.
</para>
<para>
@ -811,7 +811,7 @@ AddOtherInputDevices ()
DeviceIntPtr dev;
int i;
for (i=0; i&lt;MAX_DEVICES; i++)
for (i=0; i&lt;MAX_DEVICES; i++)
{
if (!local_dev[i].initialized &amp;&amp; available(local_dev[i]))
{
@ -827,7 +827,7 @@ AddOtherInputDevices ()
<para>
<!-- .LP -->
The default AddOtherInputDevices routine in xstubs.c does nothing.
If all input extension devices are initialized when the server
If all input extension devices are initialized when the server
starts up, it can be left as a null routine.
</para>
</sect2>
@ -839,13 +839,13 @@ Some X server implementations open all input devices when the server
is initialized and never close them. Other implementations may open only
the X pointer and keyboard devices during server initialization,
and open other input devices only when some client makes an
XOpenDevice request. This entry point is for the latter type of
XOpenDevice request. This entry point is for the latter type of
implementation.
</para>
<para>
<!-- .LP -->
If the physical device is not already open, it can be done in this routine.
In this case, the server must keep track of the fact that one or more clients
If the physical device is not already open, it can be done in this routine.
In this case, the server must keep track of the fact that one or more clients
have the device open, and physically close it when the last client that has
it open makes an XCloseDevice request.
</para>
@ -874,15 +874,15 @@ are opened during X server initialization and kept open).
<title>SetDeviceMode</title>
<para>
<!-- .LP -->
Some implementations support input devices that can report
Some implementations support input devices that can report
either absolute positional data or relative motion. The XSetDeviceMode
protocol request is provided to allow DDX to change the current mode of
protocol request is provided to allow DDX to change the current mode of
such a device.
</para>
<para>
<!-- .LP -->
The default implementation is to always return a BadMatch error. If the
implementation does not support any input devices that are capable of
implementation does not support any input devices that are capable of
reporting both relative motion and absolute position information, the
default implementation may be left unchanged.
</para>
@ -891,8 +891,8 @@ default implementation may be left unchanged.
<title>SetDeviceValuators</title>
<para>
<!-- .LP -->
Some implementations support input devices that allow their valuators to be
set to an initial value. The XSetDeviceValuators
Some implementations support input devices that allow their valuators to be
set to an initial value. The XSetDeviceValuators
protocol request is provided to allow DDX to set the valuators of
such a device.
</para>
@ -910,40 +910,40 @@ valuators to be set, the default implementation may be left unchanged.
The XChangePointerDevice protocol request is provided to change which device is
used as the X pointer. Some implementations may maintain information
specific to the X pointer in the private data structure pointed to by
the DeviceIntRec. ChangePointerDevice is called to allow such
the DeviceIntRec. ChangePointerDevice is called to allow such
implementations to move that information to the new pointer device.
The current location of the X cursor is an example of the type of
The current location of the X cursor is an example of the type of
information that might be affected.
</para>
<para>
<!-- .LP -->
The DeviceIntRec structure that describes the X pointer device does not
contain a FocusRec. If the device that has been made into the new X pointer
was previously a device that could be focused, ProcXChangePointerDevice will
The DeviceIntRec structure that describes the X pointer device does not
contain a FocusRec. If the device that has been made into the new X pointer
was previously a device that could be focused, ProcXChangePointerDevice will
free the FocusRec associated with that device.
</para>
<para>
<!-- .LP -->
If the server implementation desires to allow clients to focus the old pointer
If the server implementation desires to allow clients to focus the old pointer
device (which is now accessible through the input extension), it should call
InitFocusClassDeviceStruct for the old pointer device.
</para>
<para>
<!-- .LP -->
The XChangePointerDevice protocol request also allows the client
to choose which axes of the new pointer device are used to move
to choose which axes of the new pointer device are used to move
the X cursor in the X- and Y- directions. If the axes are different
than the default ones, the server implementation should record that fact.
</para>
<para>
<!-- .LP -->
If the server implementation supports input devices with valuators that
If the server implementation supports input devices with valuators that
are not allowed to be used as the X pointer, they should be screened out
by this routine and a BadDevice error returned.
</para>
<para>
<!-- .LP -->
The default implementation is to do nothing.
The default implementation is to do nothing.
</para>
</sect2>
<sect2 id="ChangeKeyboardDevice">
@ -953,19 +953,19 @@ The default implementation is to do nothing.
The XChangeKeyboardDevice protocol request is provided to change which device is
used as the X keyboard. Some implementations may maintain information
specific to the X keyboard in the private data structure pointed to by
the DeviceIntRec. ChangeKeyboardDevice is called to allow such
the DeviceIntRec. ChangeKeyboardDevice is called to allow such
implementations to move that information to the new keyboard device.
</para>
<para>
<!-- .LP -->
The X keyboard device can be focused, and the DeviceIntRec that describes
that device has a FocusRec. If the device that has been made into the new X
keyboard did not previously have a FocusRec,
that device has a FocusRec. If the device that has been made into the new X
keyboard did not previously have a FocusRec,
ProcXChangeKeyboardDevice will allocate one for it.
</para>
<para>
<!-- .LP -->
If the implementation does not want clients to be able to focus the old X
If the implementation does not want clients to be able to focus the old X
keyboard (which has now become available as an input extension device)
it should call DeleteFocusClassDeviceStruct to free the FocusRec.
</para>
@ -977,7 +977,7 @@ BadDevice error returned.
</para>
<para>
<!-- .LP -->
The default implementation is to do nothing.
The default implementation is to do nothing.
</para>
</sect2>
</sect1>
@ -986,11 +986,11 @@ The default implementation is to do nothing.
<para>
<!-- .LP -->
Events accessed through the input extension are analogous to the core input
events, but have different event types. They are of types
events, but have different event types. They are of types
<function>DeviceKeyPress</function>, <function>DeviceKeyRelease</function>, <function>DeviceButtonPress</function>,
<function>DeviceButtonRelease</function>, <function>DeviceDeviceMotionNotify</function>,
<function>DeviceProximityIn</function>, <function>DeviceProximityOut</function>, and <function>DeviceValuator</function>.
These event types are not constants. Instead, they are external integers
These event types are not constants. Instead, they are external integers
defined by the input extension. Their actual values will depend on which
extensions are supported by a server, and the order in which they are
initialized.
@ -1007,7 +1007,7 @@ input extension constants needed by DDX are defined in the file
Some events defined by the input extension contain more information than can
be contained in the 32-byte xEvent data structure. To send this information
to clients, DDX must generate two or more 32-byte wire events. The following
sections describe the contents of these events.
sections describe the contents of these events.
</para>
<sect2 id="Device_Key_Events">
<title>Device Key Events</title>
@ -1053,7 +1053,7 @@ valuator0 through valuator5 - the values of the valuators.
<para>
<!-- .LP -->
In order to pass this information to the input extension library, two 32-byte
wire events must be generated by DDX. The first has an event type of
wire events must be generated by DDX. The first has an event type of
<function>DeviceKeyPress</function>, and the second has an event type of <function>DeviceValuator</function>.
</para>
<para>
@ -1106,7 +1106,7 @@ The following code fragment shows how the two wire events could be initialized:
<para>
<!-- .LP -->
<function>DeviceButton</function> events contain all the information that is contained in
a core button event, and also the same additional information that a
a core button event, and also the same additional information that a
<function>DeviceKey</function> event contains.
</para>
</sect2>
@ -1174,8 +1174,8 @@ set correctly.
<title>Device Proximity Events</title>
<para>
<!-- .LP -->
Some input devices that report absolute positional information, such as
graphics tablets and touchscreens, may report proximity events.
Some input devices that report absolute positional information, such as
graphics tablets and touchscreens, may report proximity events.
<function>ProximityIn</function>
events are generated when a pointing device like a stylus, or in the case
of a touchscreen, the user's finger, comes into close proximity with the

2
doc/smartsched
View file

@ -8,7 +8,7 @@ History:
Since the original X server was written at Digital in 1987, the OS and DIX
layers shared responsibility for scheduling the order to service
client requests. The original design was simplistic; under the maximum
first make it work, then make it work well, this was a good idea. Now
first make it work, then make it work well, this was a good idea. Now
that we have a bit more experience with X applications, it's time to
rethink the design.

2
fb/fbbltone.c
View file

@ -137,7 +137,7 @@ static const FbBits fbStipple1Bits[2] = {
* Example: srcX = 0 dstX = 8 (FB unit 32 dstBpp 8)
*
* **** **** **** **** **** **** **** ****
* ^
* ^
* ******** ******** ******** ********
* ^
*

2
glamor/glamor_egl.c
View file

@ -1045,7 +1045,7 @@ glamor_egl_try_gles_api(ScrnInfoPtr scrn)
{
struct glamor_egl_screen_private *glamor_egl =
glamor_egl_get_screen_private(scrn);
static const EGLint config_attribs[] = {
EGL_CONTEXT_CLIENT_VERSION, 2,
EGL_NONE

2
hw/xfree86/common/vesamodes
View file

@ -2,7 +2,7 @@
// Default modes distilled from
// "VESA and Industry Standards and Guide for Computer Display Monitor
// Timing", version 1.0, revision 0.8, adopted September 17, 1998.
//
//
// $XFree86: xc/programs/Xserver/hw/xfree86/etc/vesamodes,v 1.3 1999/11/16 03:28:03 tsi Exp $

56
hw/xfree86/ddc/DDC.HOWTO
View file

@ -5,26 +5,26 @@
1) DDC INITIALIZATION
When implementing DDC in the driver one has the choice between
DDC1 and DDC2.
DDC1 data is continuously transmitted by a DDC1 capable display
device. The data is send serially over a data line; the Vsync
signal serves as clock. Only one EDID 1.x data block can be
transmitted using DDC1. Since transmission of an EDID1 block
using a regular Vsync frequency would take up several seconds
the driver can increase the Vsync frequency to up to 25 kHz as
DDC1 and DDC2.
DDC1 data is continuously transmitted by a DDC1 capable display
device. The data is send serially over a data line; the Vsync
signal serves as clock. Only one EDID 1.x data block can be
transmitted using DDC1. Since transmission of an EDID1 block
using a regular Vsync frequency would take up several seconds
the driver can increase the Vsync frequency to up to 25 kHz as
soon as it detects DDC1 activity on the data line.
DDC2 data is transmitted using the I2C protocol. This requires
an additional clock line. DDC2 is capable of transmitting EDID1
and EDID2 block as well as a VDIF block on display devices that
support these.
and EDID2 block as well as a VDIF block on display devices that
support these.
Display devices switch into the DDC2 mode as soon as they detect
activity on the DDC clock line. Once the are in DDC2 mode they
stop transmitting DDC1 signals until the next power cycle.
Some graphics chipset configurations which are not capable of
DDC2 might still be able to read DDC1 data. Where available
DDC2 it is preferable.
DDC2 it is preferable.
All relevant prototypes and defines are in xf86DDC.h.
DDC2 additionally requires I2C support. The I2C prototypes
are in xf86i2c.h.
@ -36,25 +36,25 @@
of the DDC line:
unsigned int XXX_ddc1Read(ScrnInfoPtr pScrn)
Additionally a function is required to increase the Vsync
frequency to max. 25 kHz.
frequency to max. 25 kHz.
void XXX_ddc1SetSpeed(ScrnInfoPtr pScrn, xf86ddcSpeed speed)
If the speed argument is DDC_FAST the function should increase
the Vsync frequency on DDC_SLOW it should restore the original
value. For convenience a generic ddc1SetSpeed() function is provided
in the vga module for VGA-like chipsets.
in the vga module for VGA-like chipsets.
void vgaHWddc1SetSpeed(ScrnInfoPtr pScrn, sf86ddcSpeed speed).
To read out the DDC1 data the driver should call
To read out the DDC1 data the driver should call
xf86MonPtr xf86DoEDID_DDC1(int scrnIndex,
xf86MonPtr xf86DoEDID_DDC1(int scrnIndex,
void (*DDC1SetSpeed)(ScrnInfoPtr, xf86ddcSpeed),
unsigned int (*DDC1Read)(ScrnInfoPtr))
in PreInit(). DDC1SetSpeed is a pointer to the SetSpeed()
function, DDC1Read has to point to the DDC1 read function.
The function will return a pointer to the xf86Monitor structure
@ -62,11 +62,11 @@
NULL will be returned on failure.
DDC2 Support
To read out DDC2 information I2C has to be initialized first.
(See documentation for the i2c module).
The function
(See documentation for the i2c module).
The function
xf86MonPtr xf86DoEDID_DDC2(int scrnIndex, I2CBusPtr pBus)
is provided to read out and process DDC2 data. A pointer
@ -76,16 +76,16 @@
which contains all information retrieved by DDC.
NULL will be returned on failure.
Printing monitor parameters
Printing monitor parameters
To print out the information contained in the xf86Monitor
structure the function
structure the function
xf86MonPtr xf86PrintEDID(xf86MonPtr monitor)
is provided.
Further processing of the xf86Monitor structure is not yet
Further processing of the xf86Monitor structure is not yet
implemented. However, it is planned to use the information
about video modes, gamma values etc.
Therefore it is strongly recommended to read out DDC data

48
hw/xfree86/doc/README.modes
View file

@ -42,7 +42,7 @@ goal is to always have one 'special' output which is used for operations
which need a single defined monitor (like XFree86-VidModeExtension mode
setting, RandR 1.1 mode setting, DDC property setting, etc.).
2.1.1 Output overview
2.1.1 Output overview
As outputs are connected to monitors, they hold a list of modes supported by
the monitor. If the monitor and output support DDC, then the list of modes
@ -102,12 +102,12 @@ This sets the range of screen sizes supported by the driver.
xf86CrtcPtr
xf86CrtcCreate (ScrnInfoPtr scrn,
const xf86CrtcFuncsRec *funcs)
Create one CRTC object. See the discussion below for a description of the
contents of the xf86CrtcFuncsRec. Note that this is done in PreInit, so it
should not be re-invoked at each server generation. Create one of these for
each CRTC present in the hardware.
xf86OutputPtr
xf86OutputCreate (ScrnInfoPtr scrn,
const xf86OutputFuncsRec *funcs,
@ -118,26 +118,26 @@ contents of the xf86OutputFuncsRec. This is also called from PreInit and
need not be re-invoked at each ScreenInit time. An Output should be created
for every Output present in the hardware, not just for outputs which have
detected monitors.
Bool
xf86OutputRename (xf86OutputPtr output, const char *name)
If necessary, the name of an output can be changed after it is created using
this function.
Bool
xf86InitialConfiguration (ScrnInfoPtr scrn, Bool canGrow)
Using the resources provided, and the configuration specified by the user,
this function computes an initial configuration for the server. It tries to
enable as much hardware as possible using some fairly simple heuristics.
enable as much hardware as possible using some fairly simple heuristics.
The 'canGrow' parameter indicates that the frame buffer does not have a fixed
size. When the frame buffer has a fixed size, the configuration selects a
'reasonablely large' frame buffer so that common reconfiguration options are
possible. For resizable frame buffers, the frame buffer is set to the smallest
size that encloses the desired configuration.
3.2 ScreenInit functions
These functions should be used during the driver ScreenInit phase.
@ -189,7 +189,7 @@ Functions called from the pScrn->SwitchMode hook, which is used by the
XFree86-VidModeExtension and the keypad mode switch commands.
Bool
xf86SetSingleMode (ScrnInfoPtr scrn,
xf86SetSingleMode (ScrnInfoPtr scrn,
DisplayModePtr desired,
Rotation rotation)
@ -237,7 +237,7 @@ specified CRTC are included in the mode setting process. 'x' and 'y' are the
offset within the frame buffer that the crtc is placed at. No checking is
done in this function to ensure that the mode is usable by the active
outputs.
void
xf86ProbeOutputModes (ScrnInfoPtr pScrn, int maxX, int maxY)
@ -246,7 +246,7 @@ and then acquires new mode lists for all monitors which are not disconnected.
Monitor configuration data is used to modify the mode lists returned by the
outputs. 'maxX' and 'maxY' limit the maximum size modes that will be
returned.
void
xf86SetScrnInfoModes (ScrnInfoPtr pScrn)
@ -258,7 +258,7 @@ Usually, the driver won't need to call this function as
xf86InitialConfiguration will do so automatically, as well as any RandR
functions which reprobe for modes. However, if the driver reprobes for modes
at other times using xf86ProbeOutputModes, this function needs to be called.
Bool
xf86DiDGAReInit (ScreenPtr pScreen)
@ -273,7 +273,7 @@ After any sequence of calls using xf86CrtcSetMode, this function cleans up
any leftover Output and CRTC objects by disabling them, saving power. It is
safe to call this whenever the server is running as it only disables objects
which are not currently in use.
4. CRTC operations
4.1 CRTC functions
@ -291,7 +291,7 @@ crtc dpms functions.
void
crtc->funcs->save (xf86CrtcPtr crtc)
void
crtc->funcs->restore (xf86CrtcPtr crtc)
@ -302,7 +302,7 @@ code here. In particular, the server itself never uses this function.
Bool
crtc->funcs->lock (xf86CrtcPtr crtc)
void
crtc->funcs->unlock (xf86CrtcPtr crtc)
@ -312,7 +312,7 @@ the hardware while the server is busy changing the output configuration. If
the lock function returns FALSE, the unlock function will not be invoked.
Bool
crtc->funcs->mode_fixup (xf86CrtcPtr crtc,
crtc->funcs->mode_fixup (xf86CrtcPtr crtc,
DisplayModePtr mode,
DisplayModePtr adjusted_mode)
@ -388,20 +388,20 @@ driver writer.
* Associated ScrnInfo
*/
ScrnInfoPtr scrn;
/**
* Active state of this CRTC
*
* Set when this CRTC is driving one or more outputs
*/
Bool enabled;
/** Track whether cursor is within CRTC range */
Bool cursorInRange;
/** Track state of cursor associated with this CRTC */
Bool cursorShown;
/**
* Active mode
*
@ -413,14 +413,14 @@ driver writer.
Rotation rotation;
PixmapPtr rotatedPixmap;
void *rotatedData;
/**
* Position on screen
*
* Locates this CRTC within the frame buffer
*/
int x, y;
/**
* Desired mode
*
@ -432,10 +432,10 @@ driver writer.
DisplayModeRec desiredMode;
Rotation desiredRotation;
int desiredX, desiredY;
/** crtc-specific functions */
const xf86CrtcFuncsRec *funcs;
/**
* Driver private
*
@ -455,7 +455,7 @@ driver writer.
#endif
};
5. Output functions.
6. Configuration

2
hw/xfree86/drivers/modesetting/driver.c
View file

@ -2324,7 +2324,7 @@ CloseScreen(ScreenPtr pScreen)
dixLookupPrivate(&pScreen->devPrivates, miPointerScreenKey);
if (PointPriv->spriteFuncs == &drmmode_sprite_funcs)
PointPriv->spriteFuncs = ms->SpriteFuncs;
PointPriv->spriteFuncs = ms->SpriteFuncs;
}
if (pScrn->vtSema) {

30
hw/xfree86/int10/INT10.HOWTO
View file

@ -30,7 +30,7 @@ calls to other int10 module functions.
--------------------
To allocate memory in the real mode execution environment
void * xf86Int10AllocPages(xf86Int10InfoPtr pInt,int num, int *off);
can be called. It allocates num consecutive pagesize chunks. It
@ -45,7 +45,7 @@ Is used to free num pages beginning at pbase.
-------------------------
The BIOS call is executed by calling:
void xf86ExecX86int10(xf86Int10InfoPtr pInt);
The number of the interrupt (normally 10) and the initial values of
@ -143,11 +143,11 @@ to find out if the user has requested not to initialize int10. If so
xf86InitInt10() should return NULL. Otherwise an xf86Int10InfoRec
should be allocated. This structure contains the following fields:
a. int entityIndex - index of the entity whose BIOS is to be
a. int entityIndex - index of the entity whose BIOS is to be
executed.
b. int scrnIndex - index of the screen assigned the entity.
c. pointer cpuRegs - pointer to a emulator/vm86-mode private
structure. May hold cpu register values
c. pointer cpuRegs - pointer to a emulator/vm86-mode private
structure. May hold cpu register values
for the emulator.
d. CARD16 BIOSseg - Video BIOS segment address.
e. pointer private - pointer to a os specific data structure.
@ -166,9 +166,9 @@ memory should be freed and xf86Int10Init(0 should exit returning NULL.
If the platform has a PC like system BIOS it may be copied to or
mapped into memory locations SYS_BIOS to SYS_SIZE-1 of the real mode
memory environment of this process. Otherwise the helper function:
memory environment of this process. Otherwise the helper function:
int setup_system_bios(CARD32 base_addr);
int setup_system_bios(CARD32 base_addr);
may be called to set up a rudimentary system BIOS sufficient to be
used to boot video BIOSes. base_addr specifies the virtual address
@ -181,16 +181,16 @@ cards by calling:
void reset_int_vect(xf86Int10InfoPtr pInt); To initialize the
correct video BIOS entry points the BIOS must be warm-booted. If no
PC-like int vector is available one can be set up by calling
PC-like int vector is available one can be set up by calling
void setup_int_vect(xf86Int10InfoPtr pInt);
void setup_int_vect(xf86Int10InfoPtr pInt);
In this case the video BIOS has to be warm-booted always. If the
video BIOS for this entity has been installed during boot it may be
mapped (or copied) directly to the correct address in the real mode
memory environment. Otherwise
int mapPciRom(xf86Int10InfoPtr pInt, unsigned char * address);
int mapPciRom(xf86Int10InfoPtr pInt, unsigned char * address);
should be called to copy the BIOS image from PCI ROM. 'address'
specifies the address this image should be copied to. Sufficient space
@ -199,7 +199,7 @@ mapPciRom(). This function will return the size of the BIOS image in
bytes if it was able to successfully copy the image and 0
otherwise. To create a well defined point to exit the softbooter
void set_return_trap(xf86Int10Ptr pInt);
void set_return_trap(xf86Int10Ptr pInt);
may be called. It sets up a 'hlt' instruction in the emulator memory
just above the BIOS variable area. Before entering real mode execution
@ -207,7 +207,7 @@ this address will be pushed onto the return stack. If the BIOS needs
to be warm-booted this should be done before leaving xf86InitInt10()
by setting num in the xf86Int10InfoRec to 0xe6 and calling
void xf86ExecX86int10(xf86Int10IfoPtr pInt);
void xf86ExecX86int10(xf86Int10IfoPtr pInt);
The implementation of this function will be discussed below. This
function should be wrapped by calls to void LockLegacyVGA(screen,
@ -240,7 +240,7 @@ the function
should be provided. If the entity to be freed was mapped by
MapCurrentInt10() this mapping needs to be undone also.
4.
4.
void * xf86Int10AllocPages(xf86Int10InfoPtr pInt,int num, int *off)
void xf86Int10FreePages(xf86Int10InfoPtr pInt, void *pbase, int num)
@ -277,7 +277,7 @@ set up the non-static real mode execution environment. On return from
setup_int() 'Int10Current' holds a pointer to the current
xf86Int10InfoRec.
It should start execution by calling
It should start execution by calling
Bool int_handler(xf86Int10InfoPtr pInt);
@ -287,7 +287,7 @@ the resulting register values back to the xf86Int10InfoRec structure
void finish_int(xf86Int10InfoPtr pInt);
should be called.
should be called.
Helper functions are provided to aid the implementation of a vm86
call:

2
hw/xfree86/modes/xf86Modes.c
View file

@ -810,7 +810,7 @@ xf86CVTMode(int HDisplay, int VDisplay, float VRefresh, Bool Reduced,
XNFasprintf(&tmp, "%dx%d", HDisplay, VDisplay);
Mode->name = tmp;
Mode->VDisplay = libxcvt_mode_info->vdisplay;
Mode->HDisplay = libxcvt_mode_info->hdisplay;
Mode->Clock = libxcvt_mode_info->dot_clock;

2
hw/xfree86/os-support/solaris/solaris-amd64.S
View file

@ -1,5 +1,5 @@
/ Copyright (c) 2005, Oracle and/or its affiliates.
/
/
/ Permission is hereby granted, free of charge, to any person obtaining a
/ copy of this software and associated documentation files (the "Software"),
/ to deal in the Software without restriction, including without limitation

2
hw/xfree86/os-support/solaris/solaris-ia32.S
View file

@ -1,5 +1,5 @@
/ Copyright (c) 2004, Oracle and/or its affiliates.
/
/
/ Permission is hereby granted, free of charge, to any person obtaining a
/ copy of this software and associated documentation files (the "Software"),
/ to deal in the Software without restriction, including without limitation

6
hw/xfree86/os-support/solaris/solaris-sparcv8plus.S
View file

@ -1,5 +1,5 @@
/* Copyright (c) 2004, Oracle and/or its affiliates.
*
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
* to deal in the Software without restriction, including without limitation
@ -31,8 +31,8 @@
#endif
/* Converted from common/compiler.h gcc inline format to Sun cc inline
* format by Kenjiro Tsuji
*
* format by Kenjiro Tsuji
*
* The value 0x88 means ASI_PRIMARY_LITTLE.
* The store or load to/from the address space will be done
* as little-endian. In the original xrog code, the value

14
hw/xquartz/X11Application.m
View file

@ -902,7 +902,7 @@ wait_for_mieq_init(void);
[e type] == NSOtherMouseDragged ||
[e type] == NSRightMouseDragged ||
[e type] == NSMouseMoved ||
[e type] == NSTabletPoint ||
[e type] == NSTabletPoint ||
[e type] == NSScrollWheel;
isTabletEvent = ([e type] == NSTabletPoint) ||
@ -985,7 +985,7 @@ wait_for_mieq_init(void);
NX_DEVICELCTLKEYMASK | NX_DEVICERCTLKEYMASK,
NX_DEVICELCTLKEYMASK);
modifierFlags = ensure_flag(modifierFlags, NX_SHIFTMASK,
NX_DEVICELSHIFTKEYMASK | NX_DEVICERSHIFTKEYMASK,
NX_DEVICELSHIFTKEYMASK | NX_DEVICERSHIFTKEYMASK,
NX_DEVICELSHIFTKEYMASK);
modifierFlags = ensure_flag(modifierFlags, NX_COMMANDMASK,
NX_DEVICELCMDKEYMASK | NX_DEVICERCMDKEYMASK,
@ -1201,16 +1201,16 @@ handle_mouse:
if (source) {
double lineHeight = CGEventSourceGetPixelsPerLine(source);
CFRelease(source);
/* There's no real reason for the 1/5 ratio here other than that
* it feels like a good ratio after some testing.
*/
deltaX *= lineHeight / 5.0;
deltaY *= lineHeight / 5.0;
}
#endif
if (XQuartzScrollInDeviceDirection &&
[e isDirectionInvertedFromDevice]) {
deltaX *= -1;
@ -1244,7 +1244,7 @@ handle_mouse:
}
/* Eat up the deficit, but ensure that something is
* always sent
* always sent
*/
if (fabs(deltaX) > fabs(deficit_x)) {
deltaX -= deficit_x;
@ -1277,7 +1277,7 @@ handle_mouse:
}
/* Eat up the deficit, but ensure that something is
* always sent
* always sent
*/
if (fabs(deltaY) > fabs(deficit_y)) {
deltaY -= deficit_y;

2
hw/xwayland/xwayland-glamor.c
View file

@ -65,7 +65,7 @@ void
xwl_glamor_egl_make_current(struct xwl_screen *xwl_screen)
{
EGLContext ctx = xwl_screen->glamor_ctx->ctx;
if (lastGLContext == ctx)
return;

2
hw/xwin/winconfig.c
View file

@ -25,7 +25,7 @@
*or other dealings in this Software without prior written authorization
*from the XFree86 Project.
*
* Authors: Alexander Gottwald
* Authors: Alexander Gottwald
*/
#ifdef HAVE_XWIN_CONFIG_H

2
hw/xwin/winconfig.h
View file

@ -27,7 +27,7 @@
*or other dealings in this Software without prior written authorization
*from the XFree86 Project.
*
* Authors: Alexander Gottwald
* Authors: Alexander Gottwald
*/
#include "win.h"

2
hw/xwin/winmsg.c
View file

@ -25,7 +25,7 @@
*or other dealings in this Software without prior written authorization
*from the XFree86 Project.
*
* Authors: Alexander Gottwald
* Authors: Alexander Gottwald
*/
#ifdef HAVE_XWIN_CONFIG_H

2
hw/xwin/winmsg.h
View file

@ -25,7 +25,7 @@
*or other dealings in this Software without prior written authorization
*from the XFree86 Project.
*
* Authors: Alexander Gottwald
* Authors: Alexander Gottwald
*/
#ifndef __WIN_MSG_H__

2
hw/xwin/winprefslex.l
View file

@ -118,7 +118,7 @@ parse_file (FILE *file)
if (!file)
return 1;
yylineno = 1;
yyin = file;
ret = yyparse ();

12
hw/xwin/winprefsyacc.y
View file

@ -51,7 +51,7 @@
/* The global pref settings */
WINPREFS pref;
/* The working menu */
/* The working menu */
static MENUPARSED menu;
/* Functions for parsing the tokens into out structure */
@ -139,7 +139,7 @@ line: NEWLINE
;
newline_or_nada:
newline_or_nada:
| NEWLINE newline_or_nada
;
@ -335,19 +335,19 @@ CloseMenu (void)
ErrorF("LoadPreferences: Empty menu detected\n");
return;
}
if (pref.menuItems)
pref.menu = realloc (pref.menu, (pref.menuItems+1)*sizeof(MENUPARSED));
else
pref.menu = malloc (sizeof(MENUPARSED));
memcpy (pref.menu+pref.menuItems, &menu, sizeof(MENUPARSED));
pref.menuItems++;
memset (&menu, 0, sizeof(MENUPARSED));
}
static void
static void
OpenIcons (void)
{
if (pref.icon != NULL) {
@ -377,7 +377,7 @@ AddIconLine (char *matchstr, char *iconfile)
pref.iconItems++;
}
static void
static void
CloseIcons (void)
{
}

2
include/xkb-config.h.in
View file

@ -1,5 +1,5 @@
/* xkb-config.h.in: not at all generated. -*- c -*-
*
*
*/
#ifndef _XKB_CONFIG_H_

2
include/xorg-config.h.meson.in
View file

@ -1,5 +1,5 @@
/* xorg-config.h.in: not at all generated. -*- c -*-
*
*
* This file differs from xorg-server.h.in in that -server is installed
* with the rest of the SDK for external drivers/modules to use, whereas
* -config is for internal use only (i.e. building the DDX).

168
miext/rootless/README.txt
View file

@ -8,80 +8,80 @@
Introduction
The generic rootless layer allows an X server to be implemented
on top of another window server in a cooperative manner. This allows the
X11 windows and native windows of the underlying window server to
coexist on the same screen. The layer is called "rootless" because the root
window of the X server is generally not drawn. Instead, each top-level
child of the root window is represented as a separate on-screen window by
the underlying window server. The layer is referred to as "generic"
because it abstracts away the details of the underlying window system and
contains code that is useful for any rootless X server. The code for the
generic rootless layer is located in xc/programs/Xserver/miext/rootless. To
build a complete rootless X server requires a specific rootless
implementation, which provides functions that allow the generic rootless
The generic rootless layer allows an X server to be implemented
on top of another window server in a cooperative manner. This allows the
X11 windows and native windows of the underlying window server to
coexist on the same screen. The layer is called "rootless" because the root
window of the X server is generally not drawn. Instead, each top-level
child of the root window is represented as a separate on-screen window by
the underlying window server. The layer is referred to as "generic"
because it abstracts away the details of the underlying window system and
contains code that is useful for any rootless X server. The code for the
generic rootless layer is located in xc/programs/Xserver/miext/rootless. To
build a complete rootless X server requires a specific rootless
implementation, which provides functions that allow the generic rootless
layer to interact with the underlying window system.
Concepts
In the context of a rootless X server the term window is used to
mean many fundamentally different things. For X11 a window is a DDX
resource that describes a visible, or potentially visible, rectangle on the
screen. A top-level window is a direct child of the root window. To avoid
confusion, an on-screen native window of the underlying window system
is referred to as a "frame". The generic rootless layer associates each
mapped top-level X11 window with a frame. An X11 window may be said
In the context of a rootless X server the term window is used to
mean many fundamentally different things. For X11 a window is a DDX
resource that describes a visible, or potentially visible, rectangle on the
screen. A top-level window is a direct child of the root window. To avoid
confusion, an on-screen native window of the underlying window system
is referred to as a "frame". The generic rootless layer associates each
mapped top-level X11 window with a frame. An X11 window may be said
to be "framed" if it or its top-level parent is represented by a frame.
The generic rootless layer models each frame as being backed at
all times by a backing buffer, which is periodically flushed to the screen.
If the underlying window system does not provide a backing buffer for
frames, this must be done by the rootless implementation. The generic
rootless layer model does not assume it always has access to the frames'
backing buffers. Any drawing to the buffer will be proceeded by a call to
the rootless implementation's StartDrawing() function and StopDrawing()
will be called when the drawing is concluded. The address of the frame's
backing buffer is returned by the StartDrawing() function and it can
The generic rootless layer models each frame as being backed at
all times by a backing buffer, which is periodically flushed to the screen.
If the underlying window system does not provide a backing buffer for
frames, this must be done by the rootless implementation. The generic
rootless layer model does not assume it always has access to the frames'
backing buffers. Any drawing to the buffer will be proceeded by a call to
the rootless implementation's StartDrawing() function and StopDrawing()
will be called when the drawing is concluded. The address of the frame's
backing buffer is returned by the StartDrawing() function and it can
change between successive calls.
Because each frame is assumed to have a backing buffer, the
generic rootless layer will stop Expose events being generated when the
regions of visibility of a frame change on screen. This is similar to backing
store, but backing buffers are different in that they always store a copy of
the entire window contents, not just the obscured portions. The price paid
in increased memory consumption is made up by the greatly decreased
Because each frame is assumed to have a backing buffer, the
generic rootless layer will stop Expose events being generated when the
regions of visibility of a frame change on screen. This is similar to backing
store, but backing buffers are different in that they always store a copy of
the entire window contents, not just the obscured portions. The price paid
in increased memory consumption is made up by the greatly decreased
complexity in not having to track and record regions as they are obscured.
Rootless Implementation
The specifics of the underlying window system are provided to the
The specifics of the underlying window system are provided to the
generic rootless layer through rootless implementation functions, compile-
time options, and runtime parameters. The rootless implementation
functions are a list of functions that allow the generic rootless layer to
perform operations such as creating, destroying, moving, and resizing
frames. Some of the implementation functions are optional. A detailed
description of the rootless implementation functions is provided in
time options, and runtime parameters. The rootless implementation
functions are a list of functions that allow the generic rootless layer to
perform operations such as creating, destroying, moving, and resizing
frames. Some of the implementation functions are optional. A detailed
description of the rootless implementation functions is provided in
Appendix A.
By design, a rootless implementation should only have to include
the rootless.h header file. The rootlessCommon.h file contains definitions
internal to the generic rootless layer. (If you find you need to use
rootlessCommon.h in your implementation, let the generic rootless layer
maintainers know. This could be an area where the generic rootless layer
should be generalized.) A rootless implementation should also modify
By design, a rootless implementation should only have to include
the rootless.h header file. The rootlessCommon.h file contains definitions
internal to the generic rootless layer. (If you find you need to use
rootlessCommon.h in your implementation, let the generic rootless layer
maintainers know. This could be an area where the generic rootless layer
should be generalized.) A rootless implementation should also modify
rootlessConfig.h to specify compile time options for its platform.
The following compile-time options are defined in
The following compile-time options are defined in
rootlessConfig.h:
o ROOTLESS_PROTECT_ALPHA: By default for a color bit depth of 24 and
32 bits per pixel, fb will overwrite the "unused" 8 bits to optimize
drawing speed. If this is true, the alpha channel of frames is
protected and is not modified when drawing to them. The bits
containing the alpha channel are defined by the macro
RootlessAlphaMask(bpp), which should return a bit mask for
protected and is not modified when drawing to them. The bits
containing the alpha channel are defined by the macro
RootlessAlphaMask(bpp), which should return a bit mask for
various bits per pixel.
o ROOTLESS_REDISPLAY_DELAY: Time in milliseconds between updates to
@ -103,56 +103,56 @@ rootlessConfig.h:
Accelerated Drawing
The rootless implementation typically does not have direct access
to the hardware. Its access to the graphics hardware is generally through
the API of the underlying window system. This underlying API may not
overlap well with the X11 drawing primitives. The generic rootless layer
falls back to using fb for all its 2-D drawing. Providing optional rootless
implementation acceleration functions can accelerate some graphics
primitives and some window functions. Typically calling through to the
underlying window systems API will not speed up these operations for
small enough areas. The rootless_*_threshold runtime options allow the
rootless implementation to provide hints for when the acceleration
The rootless implementation typically does not have direct access
to the hardware. Its access to the graphics hardware is generally through
the API of the underlying window system. This underlying API may not
overlap well with the X11 drawing primitives. The generic rootless layer
falls back to using fb for all its 2-D drawing. Providing optional rootless
implementation acceleration functions can accelerate some graphics
primitives and some window functions. Typically calling through to the
underlying window systems API will not speed up these operations for
small enough areas. The rootless_*_threshold runtime options allow the
rootless implementation to provide hints for when the acceleration
functions should be used instead of fb.
Alpha Channel Protection
If the bits per pixel is greater then the color bit depth, the contents
of the extra bits are undefined by the X11 protocol. Some window systems
will use these extra bits as an alpha channel. The generic rootless layer can
be configured to protect these bits and make sure they are not modified by
other parts of the X server. To protect the alpha channel
ROOTLESS_PROTECT_ALPHA and RootlessAlphaMask(bpp) must be
set appropriately as described under the compile time options. This
ensures that the X11 graphics primitives do not overwrite the alpha
channel in an attempt to optimize drawing. In addition, the window
functions PaintWindow() and Composite() must be replaced by alpha
If the bits per pixel is greater then the color bit depth, the contents
of the extra bits are undefined by the X11 protocol. Some window systems
will use these extra bits as an alpha channel. The generic rootless layer can
be configured to protect these bits and make sure they are not modified by
other parts of the X server. To protect the alpha channel
ROOTLESS_PROTECT_ALPHA and RootlessAlphaMask(bpp) must be
set appropriately as described under the compile time options. This
ensures that the X11 graphics primitives do not overwrite the alpha
channel in an attempt to optimize drawing. In addition, the window
functions PaintWindow() and Composite() must be replaced by alpha
channel safe variants. These are provided in rootless/safeAlpha.
Credits
The generic rootless layer was originally conceived and developed
by Greg Parker as part of the XDarwin X server on Mac OS X. John
Harper made later optimizations to this code but removed its generic
independence of the underlying window system. Torrey T. Lyons
reintroduced the generic abstractions and made the rootless code suitable
The generic rootless layer was originally conceived and developed
by Greg Parker as part of the XDarwin X server on Mac OS X. John
Harper made later optimizations to this code but removed its generic
independence of the underlying window system. Torrey T. Lyons
reintroduced the generic abstractions and made the rootless code suitable
for use by other X servers.
Appendix A: Rootless Implementation Functions
The rootless implementation functions are defined in rootless.h. It
is intended that rootless.h contains the complete interface that is needed by
rootless implementations. The definitions contained in rootlessCommon.h
are intended for internal use by the generic rootless layer and are more
The rootless implementation functions are defined in rootless.h. It
is intended that rootless.h contains the complete interface that is needed by
rootless implementations. The definitions contained in rootlessCommon.h
are intended for internal use by the generic rootless layer and are more
likely to change.
Most of these functions take a RootlessFrameID as a parameter.
The RootlessFrameID is an opaque object that is returned by the
implementation's CreateFrame() function. The generic rootless layer does
not use this frame id other than to pass it back to the rootless
Most of these functions take a RootlessFrameID as a parameter.
The RootlessFrameID is an opaque object that is returned by the
implementation's CreateFrame() function. The generic rootless layer does
not use this frame id other than to pass it back to the rootless
implementation to indicate the frame to operate on.
/*
@ -188,7 +188,7 @@ typedef void (*RootlessDestroyFrameProc)
* pScreen Screen to move the new frame to
* newX, newY New position of the frame
*/
typedef void (*RootlessMoveFrameProc)
typedef void (*RootlessMoveFrameProc)
(RootlessFrameID wid, ScreenPtr pScreen, int newX, int newY);
/*

2
randr/rrcrtc.c
View file

@ -2087,6 +2087,6 @@ RRHasScanoutPixmap(ScreenPtr pScreen)
if (crtc->scanout_pixmap)
return TRUE;
}
return FALSE;
}

8
record/record.c
View file

@ -444,7 +444,7 @@ RecordFindClientOnContext(RecordContextPtr pContext,
*
* Side Effects:
* The big request is recorded with the correct length field re-inserted.
*
*
* Note: this function exists mainly to make RecordARequest smaller.
*/
static void
@ -842,7 +842,7 @@ RecordFlushAllContexts(CallbackListPtr *pcbl,
* If oneclient is zero, recording hooks needed for all clients and
* protocol on the RCAP are installed. If oneclient is non-zero,
* only those hooks needed for the specified client are installed.
*
*
* Client requestVectors may be altered. numEnabledRCAPs will be
* incremented if oneclient == 0. Callbacks may be added to
* various callback lists.
@ -927,7 +927,7 @@ RecordInstallHooks(RecordClientsAndProtocolPtr pRCAP, XID oneclient)
* If oneclient is zero, recording hooks needed for all clients and
* protocol on the RCAP may be uninstalled. If oneclient is non-zero,
* only those hooks needed for the specified client may be uninstalled.
*
*
* Client requestVectors may be altered. numEnabledRCAPs will be
* decremented if oneclient == 0. Callbacks may be deleted from
* various callback lists.
@ -2760,7 +2760,7 @@ RecordAClientStateChange(CallbackListPtr *pcbl, void *nulldata,
*
* Side Effects:
* Performs any cleanup needed by RECORD at server shutdown time.
*
*
*/
static void
RecordCloseDown(ExtensionEntry * extEntry)

4
test/bugs/bug1354.c
View file

@ -10,11 +10,11 @@
/*
* This is a test which try to test correct glamor colors when rendered.
* It should be run with fullscreen Xephyr (with glamor) with present and with
* It should be run with fullscreen Xephyr (with glamor) with present and with
* etalon high-level Xserver (can be any, on CI - Xvfb). For testing this test
* creates an image in Xephyr X server, which filled by one of colors defined in
* test_pixels. Then it captures central pixel from both Xephyr and Xserver above.
* If pixels differ - test failed. Sleep is used to ensure than presentation on both
* If pixels differ - test failed. Sleep is used to ensure than presentation on both
* Xephyr and Xvfb kicks (xcb_aux_sync was not enough) and test results will be actual
*/

2
xkb/README.compiled
View file

@ -6,7 +6,7 @@ so it is not a safe place to store compiled keymaps for long periods of
time. The default keymap for any server is usually stored in:
X<num>-default.xkm
where <num> is the display number of the server in question, which makes
it possible for several servers *on the same host* to share the same
it possible for several servers *on the same host* to share the same
directory.
Unless the X server is modified, sharing this directory between servers on

10
xorg-server.m4
View file

@ -1,14 +1,14 @@
dnl Copyright 2005 Red Hat, Inc
dnl
dnl
dnl Permission to use, copy, modify, distribute, and sell this software and its
dnl documentation for any purpose is hereby granted without fee, provided that
dnl the above copyright notice appear in all copies and that both that
dnl copyright notice and this permission notice appear in supporting
dnl documentation.
dnl
dnl
dnl The above copyright notice and this permission notice shall be included
dnl in all copies or substantial portions of the Software.
dnl
dnl
dnl THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
dnl OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
dnl MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
@ -16,12 +16,12 @@ dnl IN NO EVENT SHALL THE OPEN GROUP BE LIABLE FOR ANY CLAIM, DAMAGES OR
dnl OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
dnl ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
dnl OTHER DEALINGS IN THE SOFTWARE.
dnl
dnl
dnl Except as contained in this notice, the name of the copyright holders shall
dnl not be used in advertising or otherwise to promote the sale, use or
dnl other dealings in this Software without prior written authorization
dnl from the copyright holders.
dnl
dnl
# XORG_DRIVER_CHECK_EXT(MACRO, PROTO)
# --------------------------