GitLab

Section "Monitor"
  Identifier "a21inch"
  Option "PreferredMode" "1600x1200"
  Option "ZoomModes" "1600x1200 1280x1024 1280x1024 640x480"
EndSection

The option's effect is to search for and mark once each named mode in
the output modes list.  So the specification order is free and the zoom
modes sequence follows the order of the output modes list.  All marked
modes are available via the Ctrl+Alt+Keypad-{Plus,Minus} key
combination.

See also http://bugs.freedesktop.org/show_bug.cgi?id=17954.

This option has its use for combined monitor and television setups.
It allows for easy switching between 60 Hz and 50 Hz modes even when a
monitor refuses to display the input signal.

(Includes a few minor changes suggested by Aaron for v2)
Signed-off-by: Servaas Vandenberghe <vdb@picaros.org>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Signed-off-by: Keith Packard <keithp@keithp.com>

Changes to correctly initialize the sRGB capability attribute and
transfer it between XServer and the client. Modifications include
extension string, transferring visual config attribs and fbconfig
attribs. Also, attribute is initialized in the modules which do not
really use it (xquartz and xwin).
This version advertises both ARB and EXT strings, and initializes
the capability to default value of FALSE. It has corrected required
GLX version and does not influence swrast. The sRGB capable attribute
is attached only to those configs which do have this capability.
Both ARB and EXT versions share the same GLX extension enabling bit.
Signed-off-by: Tomasz Lis <tomasz.lis@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Keith Packard <keithp@keithp.com>

ephyrvideo.c: In function 'ephyrPutVideo':
ephyrvideo.c:1009:42: warning: variable 'drw_h' set but not used
ephyrvideo.c:1009:31: warning: variable 'drw_w' set but not used
ephyrvideo.c:1009:20: warning: variable 'drw_y' set but not used
ephyrvideo.c:1009:9: warning: variable 'drw_x' set but not used
ephyrvideo.c: In function 'ephyrGetVideo':
ephyrvideo.c:1058:42: warning: variable 'drw_h' set but not used
ephyrvideo.c:1058:31: warning: variable 'drw_w' set but not used
ephyrvideo.c:1058:20: warning: variable 'drw_y' set but not used
ephyrvideo.c:1058:9: warning: variable 'drw_x' set but not used
ephyrvideo.c: In function 'ephyrPutStill':
ephyrvideo.c:1107:42: warning: variable 'drw_h' set but not used
ephyrvideo.c:1107:31: warning: variable 'drw_w' set but not used
ephyrvideo.c:1107:20: warning: variable 'drw_y' set but not used
ephyrvideo.c:1107:9: warning: variable 'drw_x' set but not used
ephyrvideo.c: In function 'ephyrGetStill':
ephyrvideo.c:1156:42: warning: variable 'drw_h' set but not used
ephyrvideo.c:1156:31: warning: variable 'drw_w' set but not used
ephyrvideo.c:1156:20: warning: variable 'drw_y' set but not used
ephyrvideo.c:1156:9: warning: variable 'drw_x' set but not used
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Robert Morell <rmorell@nvidia.com>

kinput.c: In function 'KdEnqueueKeyboardEvent':
kinput.c:1845:16: warning: variable 'ctrl' set but not used
kinput.c:1844:17: warning: variable 'keyc' set but not used

kinput.c: In function 'KdEnqueuePointerEvent':
kinput.c:1887:12: warning: variable 'ms' set but not used

kxv.c: In function 'KdXVDisable':
kxv.c:1181:19: warning: variable 'ScreenPriv' set but not used

mouse.c: In function 'ps2SkipInit':
mouse.c:444:9: warning: variable 'skipping' set but not used
mouse.c: In function 'ps2Init':
mouse.c:473:10: warning: variable 'waiting' set but not used
mouse.c:472:9: warning: variable 'skipping' set but not used

fbdev.c: In function 'fbdevRandRSetConfig':
fbdev.c:468:19: warning: variable 'newheight' set but not used
fbdev.c:468:9: warning: variable 'newwidth' set but not used
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Robert Morell <rmorell@nvidia.com>

Otherwise, displays driven by GPU screens remain on all the time.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Keith Packard <keithp@keithp.com>

Use bytes_per_line and bits_per_pixel from the created XImage to fix
    https://bugzilla.redhat.com/show_bug.cgi?id=518960Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

So in the cold plug server shutdown case, we reap the resources
before we call CloseScreen handlers, so the config->randr_provider
is a dangling pointer when the xf86CrtcCloseScreen handler is called,

however in the hot screen unplug case, we can't rely on automatically
reaped resources, so we need to clean up the provider in the xf86CrtcCloseScreen
case.

This patch provides a cleanup callback from the randr provider removal
into the DDX so it can cleanup properly, this then gets called by the automatic
code for cold plug, or if hot unplug it gets called explicitly.

Fixes a number of random server crashes on shutdown
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58174
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=891140Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>

The previous fix for the previous fix, didn't fully work,

If we don't set compat_output we end up doing derferences
of arrays with -1, leading to valgrind warnings.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Due to another bug, the modesetting/udl driver would fail to init properly
on hotplug, when it did the code didn't clean up properly, and on removing
the device the server could crash.

Found in F18 testing.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>

With this option passed, ephyr windows can be resized like normal
windows on the fly, without the need of an explicit parent window.
Signed-off-by: Daniel Martin <daniel.martin@secunet.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

xf86Cursor.c:19:18: warning: redundant redeclaration of 'inputInfo'
[-Wredundant-decls]
In file included from xf86Cursor.c:18:0:
../../../include/inputstr.h:614:57: note: previous declaration of
'inputInfo' was here
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>

Unused as of 5d309af2Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>

Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>

This is necessary when the input handler deletes itself from the
list. Bug found by Maarten Lankhorst, this patch uses the list macros
instead of open-coding the fix.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>

man xorg.conf states that the 'Device' identifier is required in the
'Screen' section, yet current xserver defaults properly and boots up
fine without it.

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=20742Signed-off-by: Bryce Harrington <bryce@canonical.com>
Signed-off-by: Keith Packard <keithp@keithp.com>

Instead of defaulting to -intel for Oaktrail, Medfield, and CDV chips,
default to -fbdev.  For Poulsbo (only), attempt to use -psb if it's
installed, and fallback to fbdev otherwise.  All other Intel chips
should use -intel.

This fixed an issue where -intel would load on these chips and cause a
boot failure.  Newer -intel drivers avoid the boot hang, but it's still
the wrong driver to load, so why take chances.

The patch was originally created by Stefan Dirsch for OpenSUSE.  We have
included it in our stable release (Ubuntu "quantal" 12.10) since
December.

ref:  https://bugzilla.novell.com/show_bug.cgi?id=772279
ref:  https://bugs.launchpad.net/ubuntu/+bug/1069031
Fixes:  https://bugs.freedesktop.org/show_bug.cgi?id=60514Signed-off-by: Bryce Harrington <bryce@canonical.com>
Signed-off-by: Keith Packard <keithp@keithp.com>

If we're about to abort, we're already in the signal handler and cannot call
down to the default device cleanup routines (which reset, free, alloc, and
do a bunch of other things).

Add a new DEVICE_ABORT mode to signal a driver's DeviceProc that it must
reset the hardware if needed but do nothing else. An actual HW reset is only
required for some drivers dealing with the HW directly.

This is largely backwards-compatible, hence the input ABI minor bump only.

Drivers we care about either return BadValue on a mode that's not
DEVICE_{INIT|ON|OFF|CLOSE} or print an error and return BadValue. Exception
here is vmmouse, which currently ignores it and would not reset anything.
This should be fixed if the reset is required.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>

If acpid sends a string in a format that we can't parse, bail out instead of
potentially dereferencing a NULL-pointer.

X.Org Bug 73227 <http://bugs.freedesktop.org/show_bug.cgi?id=73227>
Signed-off-by: Ted Felix <ted@tedfelix.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

dmx-config.h is a server header which includes dix-config.h. That again
defines a bunch of server-specifics, including setting the size of XID to
32 bit.

libX11 uses unsigned long (8 bits on x86_64). XGCValues thus ends up being
16 bytes smaller in xdmxconfig than in the library, causing garbage to be
sent to the server.

X.Org Bug 37502 <http://bugs.freedesktop.org/show_bug.cgi?id=37502>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>

Call find_header first, returning on failure before calling malloc.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>

Found by parfait 1.1 memory analyser:
   Memory leak of pointer 'pAdapt' allocated with malloc((88 * num_adaptors))
        at line 162 of hw/xfree86/common/xf86xvmc.c in function 'xf86XvMCScreenInit'.
          'pAdapt' allocated at line 158 with malloc((88 * num_adaptors)).
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>

Also avoids leaving invalid pointers in structures if realloc had to
move them elsewhere to make them larger.

Found by parfait 1.1 code analyzer:
   Memory leak of pointer 'newCallbacks' allocated with realloc(((char*)offman->FreeBoxesUpdateCallback), (8 * (offman->NumCallbacks + 1)))
        at line 328 of hw/xfree86/common/xf86fbman.c in function 'localRegisterFreeBoxCallback'.
          'newCallbacks' allocated at line 320 with realloc(((char*)offman->FreeBoxesUpdateCallback), (8 * (offman->NumCallbacks + 1))).
          newCallbacks leaks when newCallbacks != NULL at line 327.
   Memory leak of pointer 'newPrivates' allocated with realloc(((char*)offman->devPrivates), (8 * (offman->NumCallbacks + 1)))
        at line 328 of hw/xfree86/common/xf86fbman.c in function 'localRegisterFreeBoxCallback'.
          'newPrivates' allocated at line 324 with realloc(((char*)offman->devPrivates), (8 * (offman->NumCallbacks + 1))).
          newPrivates leaks when newCallbacks == NULL at line 327.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>

Reported by parfait 1.1 code analyzer:

Error: Null pointer dereference (CWE 476)
   Read from null pointer 'p'
        at line 746 of hw/xfree86/common/xf86Option.c in function 'xf86TokenToOptName'.
          Function 'xf86TokenToOptinfo' may return constant 'NULL' at line 721, called at line 745.
          Null pointer introduced at line 721 in function 'xf86TokenToOptinfo'.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>

Our in-house parfait 1.1 code analysis tool complained that every exit
path from xf86ValidateModes() in hw/xfree86/common/xf86Mode.c leaks the
storeClockRanges allocation made at line 1501 with XNFalloc.

Investigating, it seems that this code to copy the clock range list to
the clockRanges list in the screen pointer is just plain insane, and
according to git, has been since we first imported it from XFree86.

We start at line 1495 by walking the linked list from scrp->clockRanges
until we find the end.  But that was just a diversion, since we've found
the end and immediately forgotten it, and thus at 1499 we know that
storeClockRanges is NULL, but that's not a problem since we're going to
immediately overwrite that value as the first thing in the loop.

So we move on through this loop at 1499, which takes us through the
linked list from the clockRanges variable, and for every entry in
that list allocates a new structure and copies cp to it.  If we've
not filled in the screen's clockRanges pointer yet, we set it to
the first storeClockRanges we copied from cp.   Otherwise, as best
I can tell, we just drop it into memory and let it leak away, as
parfait warned.

And then we hit the loop action, which if we haven't hit the end of
the cp list, advances cp to the next item in the list, and then just
for the fun of it, also sets storeClockRanges to the ->next pointer it
has just copied from cp as well, even though it's going to overwrite
it as the very first instruction in the loop body.

v2: rewritten using nt_list_* macros from Xorg's list.h header
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>

Found by parfait 1.1 code analyser:
   Memory leak of pointer 'keymap' allocated with XGetKeyboardMapping(HostX.dpy, min_keycode, ((max_keycode - min_keycode) + 1), &host_width)
        at line 861 of hw/kdrive/ephyr/hostx.c in function 'hostx_load_keymap'.
          'keymap' allocated at line 845 with XGetKeyboardMapping(HostX.dpy, min_keycode, ((max_keycode - min_keycode) + 1), &host_width).
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>

Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>

Use ITaskBarList interface to ensure that the taskbar notices if the window has
changed it's style in a way which affects if the taskbar shows it or not.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>

Move styling update code from WM_WM_HINTS_EVENT to a function UpdateStyle(),
which is also invoked from WM_WM_MAP3, so everything which needs to be done
to style the window happens when it is mapped

(Otherwise, the appearance of the window is sensitive to the timing of the
notification of the windows appearance hint properties being set relative to
window creation. e.g. see [1])

[1] http://sourceware.org/ml/cygwin-xfree/2012-06/msg00004.htmlSigned-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>

Future work: It looks like this code could be rationalized quite a lot: It might
make sense to pull the checking for override-redirect up out of UpdateIcon() and
UpdateName() and consolidate WM_WM_MAP2 and WM_WM_MAP3
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>

Add a new WM_WM_HINTS_EVENT event to update window style if any of the
properties which affect window style change

Check PropertyNotify events for any of the window properties which we consider
to decide on the window style, and update the window style by sending a
WM_WM_HINTS_EVENT message to the WM.

This allows the styling of the window to change during it's lifetime.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>

Move reshape code, which was only used when handling a map event, from
winUpdateWindowPosition(), to put it explicitly in the map event handler.

Remove 'reshape' parameter from winUpdatePosition().

(Note that there's no handling of the ShapeNotify event to notice when the
window shape changes, instead we hook the screen SetShape procedure and reshape
the native window then)
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>

winglobals.h checks if RELOCATE_PROJECTROOT is defined to see if a declaration
of g_fLogFileChanged is needed, so must include xwin-config.h
Signed-off-by: Ryan Pavlik <rpavlik@iastate.edu>
Reviewed-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>

Introduced in 323869f3Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>

The changes to miPointerSetPosition interface from int->double breaks
the SIS driver build, so time to bump this.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

DGA only handles master devices but it does intercept slave device events as
well (since the event handlers are per event type, not per device).

The DGA code must thus call into UpdateDeviceState to reset the button/key
state on the slave device before it discards the remainder of the event.

Test case:
- Passive GrabModeSync on VCP
- Press button
- Enable DGA after ButtonPress
- AllowEvents(SyncPointer)
- Release button

The button release is handled by DGAProcessPointerEvent but the device state
is never updated, so the slave ends up with the button permanently down.
And since the master's button state is the union of the slave states, the
master has the button permanently down.

X.Org Bug 59100 <http://bugs.freedesktop.org/show_bug.cgi?id=59100>
Reported-by: Steven Elliott <selliott4@austin.rr.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>

Reported-by: Steven Elliott <selliott4@austin.rr.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Add missing #include <pthread.h>

In file included from /jhbuild/checkout/xorg/xserver/hw/xwin/winSetAppUserModelID.c:31:0:
/jhbuild/checkout/xorg/xserver/hw/xwin/winwindow.h:140:11: error: expected declaration specifiers or ‘...’ before ‘pthread_t’
/jhbuild/checkout/xorg/xserver/hw/xwin/winwindow.h:141:11: error: expected declaration specifiers or ‘...’ before ‘pthread_t’
/jhbuild/checkout/xorg/xserver/hw/xwin/winwindow.h:142:11: error: expected declaration specifiers or ‘...’ before ‘pthread_mutex_t’
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>

De-queuing Windows messages and X events happens in the same thread of
execution.  Draining the windows message queue can lead to the X event queue
overflowing if lots of those windows messages cause X events (e.g. if a keyboard
macro program has just dumped thousands of keypresses into the Windows message
queue).  See the mailing list thread [1] for more details.

Processing one Windows message per wakeup, rather than all of them gives the X
server a chance to do stuff as well after each message.

[1] http://cygwin.com/ml/cygwin-xfree/2010-01/msg00056.htmlSigned-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>

Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>