From d9389873d65a08912dfd5ee8bbc52728d05234c2 Mon Sep 17 00:00:00 2001 From: Alan Coopersmith Date: Sun, 5 Oct 2025 11:56:48 -0700 Subject: [PATCH] Strip trailing whitespace from source files 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 Part-of: --- Xext/xace.h | 2 +- config/10-quirks.conf | 2 +- config/dbus-api | 4 +- config/x11-input.fdi | 32 +-- dix/BuiltInAtoms | 12 +- doc/Xinput.xml | 220 +++++++++--------- doc/smartsched | 2 +- fb/fbbltone.c | 2 +- glamor/glamor_egl.c | 2 +- hw/xfree86/common/vesamodes | 2 +- hw/xfree86/ddc/DDC.HOWTO | 56 ++--- hw/xfree86/doc/README.modes | 48 ++-- hw/xfree86/drivers/modesetting/driver.c | 2 +- hw/xfree86/int10/INT10.HOWTO | 30 +-- hw/xfree86/modes/xf86Modes.c | 2 +- hw/xfree86/os-support/solaris/solaris-amd64.S | 2 +- hw/xfree86/os-support/solaris/solaris-ia32.S | 2 +- .../os-support/solaris/solaris-sparcv8plus.S | 6 +- hw/xquartz/X11Application.m | 14 +- hw/xwayland/xwayland-glamor.c | 2 +- hw/xwin/winconfig.c | 2 +- hw/xwin/winconfig.h | 2 +- hw/xwin/winmsg.c | 2 +- hw/xwin/winmsg.h | 2 +- hw/xwin/winprefslex.l | 2 +- hw/xwin/winprefsyacc.y | 12 +- include/xkb-config.h.in | 2 +- include/xorg-config.h.meson.in | 2 +- miext/rootless/README.txt | 168 ++++++------- randr/rrcrtc.c | 2 +- record/record.c | 8 +- test/bugs/bug1354.c | 4 +- xkb/README.compiled | 2 +- xorg-server.m4 | 10 +- 34 files changed, 332 insertions(+), 332 deletions(-) diff --git a/Xext/xace.h b/Xext/xace.h index ad3dac4f8..354724080 100644 --- a/Xext/xace.h +++ b/Xext/xace.h @@ -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 */); diff --git a/config/10-quirks.conf b/config/10-quirks.conf index 54dd908a7..df499d6da 100644 --- a/config/10-quirks.conf +++ b/config/10-quirks.conf @@ -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" diff --git a/config/dbus-api b/config/dbus-api index 018e98657..0bd5e2b39 100644 --- a/config/dbus-api +++ b/config/dbus-api @@ -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 [ ] [ ] ..., i.e. [us]. diff --git a/config/x11-input.fdi b/config/x11-input.fdi index b263f36cb..fd7841ec8 100644 --- a/config/x11-input.fdi +++ b/config/x11-input.fdi @@ -1,27 +1,27 @@ - - - + mouse X11 Input Extension Porting Document -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. -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. -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. Initializing Extension Devices -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. Device-Independent X | Device-Dependent X --------------------- | ------------------- - | +-------------------- | ------------------- + | InitInput --------------> | - 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->startup=AutoStart| - | - call one of: +sets dev->startup=AutoStart| + | - call one of: | - RegisterPointerDevice (X pointer) | - processInputProc = ProcessPointerEvents | - RegisterKeyboardDevice (X keyboard) | - processInputProc = ProcessKeyboardEvents | - RegisterOtherDevice (extension device) | - processInputProc = ProcessOtherEvents - | - | + | + | InitAndStartDevices -----> | - calls deviceProc with parameters | (DEVICE_INIT, AutoStart) sets dev->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->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->startup & | (DEVICE_ON, AutoStart) - dev->inited | - | + dev->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 | @@ -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) 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. -A sample device control routine called from InitAndStartDevices is +A sample device control routine called from InitAndStartDevices is shown below. @@ -299,7 +299,7 @@ Bool extproc (dev, mode) InitValuatorClassDeviceStruct (dev, localdev->n_axes,); motionproc, MOTION_BUF_SIZE, Absolute); for (i=0; i<localdev->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->n_axes,); motionproc, MOTION_BUF_SIZE, Absolute); for (i=0; i<localdev->n_axes; i++) - InitValuatorAxisStruct (dev, i, min_val, max_val, + InitValuatorAxisStruct (dev, i, min_val, max_val, resolution); InitFocusClassDeviceStruct (dev); } - localdev->atom = + localdev->atom = MakeAtom(localdev->name, strlen(localdev->name), FALSE); AssignTypeAndName (dev, localdev->atom, localdev->name); break; @@ -350,8 +350,8 @@ Bool extproc (dev, mode) 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. @@ -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. 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. @@ -436,7 +436,7 @@ follows. InitKeyClassDeviceStruct -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. InitButtonClassDeviceStruct -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: @@ -491,11 +491,11 @@ have buttons. InitValuatorClassDeviceStruct -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: @@ -521,14 +521,14 @@ report motion. InitValuatorAxisStruct -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. -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) 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. @@ -555,7 +555,7 @@ that report motion. InitFocusClassDeviceStruct -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. InitProximityClassDeviceStruct -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) InitKbdFeedbackClassDeviceStruct -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. InitPtrFeedbackClassDeviceStruct -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. InitLedFeedbackClassDeviceStruct -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) -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. @@ -666,7 +666,7 @@ multiple feedbacks of the same type. InitBellFeedbackClassDeviceStruct -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) InitStringFeedbackClassDeviceStruct -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: 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, InitIntegerFeedbackClassDeviceStruct -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. -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. Implementation-Dependent Routines -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. AddOtherInputDevices -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. @@ -811,7 +811,7 @@ AddOtherInputDevices () DeviceIntPtr dev; int i; - for (i=0; i<MAX_DEVICES; i++) + for (i=0; i<MAX_DEVICES; i++) { if (!local_dev[i].initialized && available(local_dev[i])) { @@ -827,7 +827,7 @@ AddOtherInputDevices () 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. @@ -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. -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. @@ -874,15 +874,15 @@ are opened during X server initialization and kept open). SetDeviceMode -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. 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. @@ -891,8 +891,8 @@ default implementation may be left unchanged. SetDeviceValuators -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. @@ -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. -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. -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. 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. -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. -The default implementation is to do nothing. +The default implementation is to do nothing. @@ -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. 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. -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. @@ -977,7 +977,7 @@ BadDevice error returned. -The default implementation is to do nothing. +The default implementation is to do nothing. @@ -986,11 +986,11 @@ The default implementation is to do nothing. 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 DeviceKeyPress, DeviceKeyRelease, DeviceButtonPress, DeviceButtonRelease, DeviceDeviceMotionNotify, DeviceProximityIn, DeviceProximityOut, and DeviceValuator. -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. Device Key Events @@ -1053,7 +1053,7 @@ valuator0 through valuator5 - the values of the valuators. 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 DeviceKeyPress, and the second has an event type of DeviceValuator. @@ -1106,7 +1106,7 @@ The following code fragment shows how the two wire events could be initialized: DeviceButton 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 DeviceKey event contains. @@ -1174,8 +1174,8 @@ set correctly. Device Proximity Events -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. ProximityIn 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 diff --git a/doc/smartsched b/doc/smartsched index bd7627410..e34b7ad5a 100644 --- a/doc/smartsched +++ b/doc/smartsched @@ -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. diff --git a/fb/fbbltone.c b/fb/fbbltone.c index 732a89a9c..e5ac3f89f 100644 --- a/fb/fbbltone.c +++ b/fb/fbbltone.c @@ -137,7 +137,7 @@ static const FbBits fbStipple1Bits[2] = { * Example: srcX = 0 dstX = 8 (FB unit 32 dstBpp 8) * * **** **** **** **** **** **** **** **** - * ^ + * ^ * ******** ******** ******** ******** * ^ * diff --git a/glamor/glamor_egl.c b/glamor/glamor_egl.c index 5302df675..2fc63ba46 100644 --- a/glamor/glamor_egl.c +++ b/glamor/glamor_egl.c @@ -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 diff --git a/hw/xfree86/common/vesamodes b/hw/xfree86/common/vesamodes index 2bc886276..343f1a4ed 100644 --- a/hw/xfree86/common/vesamodes +++ b/hw/xfree86/common/vesamodes @@ -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 $ diff --git a/hw/xfree86/ddc/DDC.HOWTO b/hw/xfree86/ddc/DDC.HOWTO index 1d06ca124..30cd77f58 100644 --- a/hw/xfree86/ddc/DDC.HOWTO +++ b/hw/xfree86/ddc/DDC.HOWTO @@ -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 diff --git a/hw/xfree86/doc/README.modes b/hw/xfree86/doc/README.modes index 54543bf0a..ec9e53cf6 100644 --- a/hw/xfree86/doc/README.modes +++ b/hw/xfree86/doc/README.modes @@ -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 diff --git a/hw/xfree86/drivers/modesetting/driver.c b/hw/xfree86/drivers/modesetting/driver.c index d7958806b..68bdca8a8 100644 --- a/hw/xfree86/drivers/modesetting/driver.c +++ b/hw/xfree86/drivers/modesetting/driver.c @@ -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) { diff --git a/hw/xfree86/int10/INT10.HOWTO b/hw/xfree86/int10/INT10.HOWTO index 13477ce87..babdbcb19 100644 --- a/hw/xfree86/int10/INT10.HOWTO +++ b/hw/xfree86/int10/INT10.HOWTO @@ -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: diff --git a/hw/xfree86/modes/xf86Modes.c b/hw/xfree86/modes/xf86Modes.c index 091ce6333..370f4646b 100644 --- a/hw/xfree86/modes/xf86Modes.c +++ b/hw/xfree86/modes/xf86Modes.c @@ -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; diff --git a/hw/xfree86/os-support/solaris/solaris-amd64.S b/hw/xfree86/os-support/solaris/solaris-amd64.S index 830c9c6ee..030a03f48 100644 --- a/hw/xfree86/os-support/solaris/solaris-amd64.S +++ b/hw/xfree86/os-support/solaris/solaris-amd64.S @@ -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 diff --git a/hw/xfree86/os-support/solaris/solaris-ia32.S b/hw/xfree86/os-support/solaris/solaris-ia32.S index 00e8d5fba..8eb3db2de 100644 --- a/hw/xfree86/os-support/solaris/solaris-ia32.S +++ b/hw/xfree86/os-support/solaris/solaris-ia32.S @@ -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 diff --git a/hw/xfree86/os-support/solaris/solaris-sparcv8plus.S b/hw/xfree86/os-support/solaris/solaris-sparcv8plus.S index 4c448d970..d2a6aae85 100644 --- a/hw/xfree86/os-support/solaris/solaris-sparcv8plus.S +++ b/hw/xfree86/os-support/solaris/solaris-sparcv8plus.S @@ -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 diff --git a/hw/xquartz/X11Application.m b/hw/xquartz/X11Application.m index b2e2d6540..b6ab264c4 100644 --- a/hw/xquartz/X11Application.m +++ b/hw/xquartz/X11Application.m @@ -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; diff --git a/hw/xwayland/xwayland-glamor.c b/hw/xwayland/xwayland-glamor.c index 6618a0a34..b7f98d3ac 100644 --- a/hw/xwayland/xwayland-glamor.c +++ b/hw/xwayland/xwayland-glamor.c @@ -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; diff --git a/hw/xwin/winconfig.c b/hw/xwin/winconfig.c index 4f16b21e0..41af9f0c8 100644 --- a/hw/xwin/winconfig.c +++ b/hw/xwin/winconfig.c @@ -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 diff --git a/hw/xwin/winconfig.h b/hw/xwin/winconfig.h index bd1f59650..6a61066ba 100644 --- a/hw/xwin/winconfig.h +++ b/hw/xwin/winconfig.h @@ -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" diff --git a/hw/xwin/winmsg.c b/hw/xwin/winmsg.c index 8629875c3..56a7debea 100644 --- a/hw/xwin/winmsg.c +++ b/hw/xwin/winmsg.c @@ -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 diff --git a/hw/xwin/winmsg.h b/hw/xwin/winmsg.h index 02f672f08..caaf6ca41 100644 --- a/hw/xwin/winmsg.h +++ b/hw/xwin/winmsg.h @@ -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__ diff --git a/hw/xwin/winprefslex.l b/hw/xwin/winprefslex.l index 9e6f0d6d4..0b400a594 100644 --- a/hw/xwin/winprefslex.l +++ b/hw/xwin/winprefslex.l @@ -118,7 +118,7 @@ parse_file (FILE *file) if (!file) return 1; - + yylineno = 1; yyin = file; ret = yyparse (); diff --git a/hw/xwin/winprefsyacc.y b/hw/xwin/winprefsyacc.y index 9bb28ae92..ee83f7ec5 100644 --- a/hw/xwin/winprefsyacc.y +++ b/hw/xwin/winprefsyacc.y @@ -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) { } diff --git a/include/xkb-config.h.in b/include/xkb-config.h.in index 7b6a671b8..3c45ea07e 100644 --- a/include/xkb-config.h.in +++ b/include/xkb-config.h.in @@ -1,5 +1,5 @@ /* xkb-config.h.in: not at all generated. -*- c -*- - * + * */ #ifndef _XKB_CONFIG_H_ diff --git a/include/xorg-config.h.meson.in b/include/xorg-config.h.meson.in index 192c340dc..9f040c2ee 100644 --- a/include/xorg-config.h.meson.in +++ b/include/xorg-config.h.meson.in @@ -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). diff --git a/miext/rootless/README.txt b/miext/rootless/README.txt index 8a3b2bedf..f5ebc9080 100644 --- a/miext/rootless/README.txt +++ b/miext/rootless/README.txt @@ -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); /* diff --git a/randr/rrcrtc.c b/randr/rrcrtc.c index 42421b1ce..e7e79f56c 100644 --- a/randr/rrcrtc.c +++ b/randr/rrcrtc.c @@ -2087,6 +2087,6 @@ RRHasScanoutPixmap(ScreenPtr pScreen) if (crtc->scanout_pixmap) return TRUE; } - + return FALSE; } diff --git a/record/record.c b/record/record.c index c6ff5a27e..0e9080de0 100644 --- a/record/record.c +++ b/record/record.c @@ -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) diff --git a/test/bugs/bug1354.c b/test/bugs/bug1354.c index edc3f228c..b7242745e 100644 --- a/test/bugs/bug1354.c +++ b/test/bugs/bug1354.c @@ -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 */ diff --git a/xkb/README.compiled b/xkb/README.compiled index 71caa2f63..373fbd561 100644 --- a/xkb/README.compiled +++ b/xkb/README.compiled @@ -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-default.xkm where 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 diff --git a/xorg-server.m4 b/xorg-server.m4 index 195bda5d8..8eba0958d 100644 --- a/xorg-server.m4 +++ b/xorg-server.m4 @@ -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) # --------------------------