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>
The commit message to 6764471901 explains it,
but that doesn't stop the WTF moment when reading the code.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
We do the same thing here, compress them into one body.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Instead of accessing ti->listener[0] all the time.
No functional changes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
All callers currently ignore the new value, so this patch has no effect.
Inverse call graph:
DeliverTouchEmulatedEvent
DeliverEmulatedMotionEvent Ignores value
DeliverTouchBeginEvent
DeliverTouchEvent
DeliverTouchEvents Ignores value
DeliverTouchEndEvent
DeliverTouchEvent
DeliverTouchEvents Ignores value
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=59825
Signed-off-by: Piotr Dziwinski <piotrdz@gmail.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Swap events depent on the implementation of ScheduleSwap. By
unconditionally enabling GLX_INTEL_swap_event we're breaking
the system with drivers that don't support it because the apps
are forever stuck waiting for an event that will never be
delivered. So lets enable the extension only if the hooks it
depends on are actually there.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.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>
Otherwise this file is emitted in every unit that includes it.
Signed-off-by: Robert Morell <rmorell@nvidia.com>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This picks up support for Xi pointer barriers in the protocol.
Signed-off-by: Robert Morell <rmorell@nvidia.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Fixes build failure with --disable-xinerama introduced by
482e0cb cursor: Move pointer barrier code over to XI
Reason is new include order: sdksyms.sh includes xfixes.h, which previously
did not include xfixesint.h.
As of 482e0cb xfixes.h includes xibarriers.h which includes xfixesint.h
X.Org Bug 62015 <http://bugs.freedesktop.org/show_bug.cgi?id=62015>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Daniel Martin <consume.noise@gmail.com>
Renaming this function was missed in commit
9cbcb5bd6a, so both libfb.so and libwfb.so define
functions named fbDestroyGlyphCache.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Søren Sandmann <ssp@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
The main problem this patch addresses is that if a latch is put on
multi-level key with a Latch/Lock/Set, it is possible that after all
keys are released, still base modifiers are set, which typically will
make the keyboard unusable. To see how it happens (without the patch),
assume that key AltGr sets Mod5 when pressed by itself, and latches Mod3
when pressed together with Shift. Now press Shift, then AltGr and
release both keys in reverse order. Mod3 is now latched, and the
LatchMods filter remains active as the second filter. Now press AltGr;
Mod5 base modifier gets set, and the SetMods filter will become active
as the first filter. Release AltGr: First, the SetMods filter will set
clearMods to Mod5, then the LatchMods filter will overwrite clearMods
with Mod3. Result: the Mod5 base modifier will remain set. This
example becomes practically relevant for the revised German standard
layout (DIN 2137-1:2012-06).
Other changes implement the latch behaviour more accurately according to
the specification. For example, releasing a modifier latching key can
at the same time clear a locked modifier, promote another modifier that
is latched to locked, and latch a third modifier. Overall, what the
code does should be straightforward to compare what the XKB protocol
specification demands, see the table in section 6.3.
Finally, releasing a key no longer cancels a latch that has not become
pending yet. In my opinion, the specification is not clear; it speaks
of "operating" a key, which the patch effectivly interprets as "press"
rather than "press or release". From my experience, using the latter
interpretation makes latches on higher levels practically unusable. In
the example given above, one would have to release AltGr always before
Shift to get the Mod3-Latch. The practical relevance of latches on
higher levels is once more given by the revised German standard layout.
Signed-off-by: Andreas Wettstein <wettstein509@solnet.ch>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
e02f864fdf "Suppress cursor display until the first XDefineCursor() request"
disabled cursor display a priori unless -retro is given.
On a plain server, caling XFixesHideCursor() and XFixesShowCursor() would
show the default root cursor, despite no client actually defining a cursor.
Change the logic, disable CursorVisible by default and only enable it from
the window's CWCursor logic. If no window ever defines a cursor, said cursor
stays invisible.
X.Org Bug 58398 <http://bugs.freedesktop.org/show_bug.cgi?id=58398>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Bastien Nocera <hadess@hadess.net>
Reviewed-by: Daniel Martin <consume.noise@gmail.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>
dtime to the previous event is 0 on the first BarrierHit event.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
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=518960
Signed-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=891140
Reviewed-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>
Xlib doesn't use this value (it computes it from the reply length
instead) which is why nobody has noticed yet. But the spec
http://www.x.org/releases/X11R7.7/doc/kbproto/xkbproto.html
says that it should be set.
Signed-off-by: Peter Harris <pharris@opentext.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
==5712== 6 bytes in 1 blocks are still reachable in loss record 17 of 585
==5712== at 0x4A074CD: malloc (vg_replace_malloc.c:236)
==5712== by 0x3D1DE885B1: strndup (strndup.c:46)
==5712== by 0x41CB71: MakeAtom (atom.c:121)
==5712== by 0x55AE3E: XIGetKnownProperty (xiproperty.c:401)
==5712== by 0x4251C9: AddInputDevice (devices.c:312)
==5712== by 0x42AC0C: AllocDevicePair (devices.c:2657)
==5712== by 0x425E6E: InitCoreDevices (devices.c:677)
==5712== by 0x5ACA05: main (main.c:257)
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
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>
xkb.c: In function '_XkbSetNamesCheck':
xkb.c:3987:18: warning: variable 'names' set but not used
[-Wunused-but-set-variable]
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>
panoramiX.c: In function 'PanoramiXCreateConnectionBlock':
panoramiX.c:599:10: warning: declaration of 'disableBackingStore' shadows a
global declaration [-Wshadow]
In file included from ../include/windowstr.h:60:0,
from panoramiX.c:47:
../include/opaque.h:56:52: warning: shadowed declaration is here [-Wshadow]
panoramiX.c: In function 'PanoramiXConsolidate':
panoramiX.c:834:19: warning: declaration of 'pScreen' shadows a previous
local [-Wshadow]
panoramiX.c:813:15: warning: shadowed declaration is here [-Wshadow]
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>
xvdisp.c: In function 'ProcXvStopVideo':
xvdisp.c:712:11: warning: declaration of 'rc' shadows a previous local
[-Wshadow]
xvdisp.c:705:17: warning: shadowed declaration is here [-Wshadow]
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>
fbpict.c: In function 'fbGlyphs':
fbpict.c:188:6: warning: declaration of 'x' shadows a previous local
[-Wshadow]
fbpict.c:111:9: warning: shadowed declaration is here [-Wshadow]
fbpict.c:188:9: warning: declaration of 'y' shadows a previous local
[-Wshadow]
fbpict.c:111:12: warning: shadowed declaration is here [-Wshadow]
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Soren Sandmann <ssp@redhat.com>
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
Unused as of 5d309af2ed
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>
rrcrtc.c: In function 'RRCrtcDetachScanoutPixmap':
rrcrtc.c:366:9: warning: variable 'ret' set but not used
[-Wunused-but-set-variable]
rrcrtc.c: In function 'rrCheckPixmapBounding':
rrcrtc.c:505:13: warning: variable 'ret' set but not used
[-Wunused-but-set-variable]
rrcrtc.c:445:9: warning: unused variable 'i' [-Wunused-variable]
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>
Format strings with length modifiers but missing format specifier like "%0"
will read one byte past the array size.
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>
When an RandR shared pixmap is created in rrCreateSharedPixmap, it has a refcnt
of 1. Then, PixmapShareToSlave bumps the refcnt to 2. However, there's no
corresponding PixmapUnshareFromSlave where the refcnt can be decreased again,
and there's no convenient common place where the refcnt can be decremented when
the slave pixmap is destroyed.
Fix this by just unreffing the pixmap twice in RRCrtcDetachScanoutPixmap.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
