Document the fact that ReputImage is used for stills as well as images.
Signed-off-by: Ville Syrjälä <ville.syrjala@nokia.com>
Reviewed-by: Luc Verhaegen <luc.verhaegen@basyskom.de>
PutImage/PutStill respect the GC clip, however ReputImage does not.
PutImage/PutStill are supposed to be oneshot operations so ReputImage
should never expand the area covered by the clip, instead it should
only shrink if the window clip shrinks. So commandeer clientClip
into use by ReputImage and initially make it a copy of the original
GC composite clip. Whenever ReputImage needs reclipping update
clientClip with the newly calculated composite clip.
Signed-off-by: Ville Syrjälä <ville.syrjala@nokia.com>
Reviewed-by: Luc Verhaegen <luc.verhaegen@basyskom.de>
clipOrg never changes except when clientClip changes, so instead of
keeping copies of both originals translate clientClip by clipOrg
immediately and just keep the translated clientClip.
Signed-off-by: Ville Syrjälä <ville.syrjala@nokia.com>
Reviewed-by: Luc Verhaegen <luc.verhaegen@basyskom.de>
Also reput PutVideo/GetVideo ports in AdjustFrame. This makes the
overlay track the screen panning instead of staying stationary in the
wrong place.
Signed-off-by: Ville Syrjälä <ville.syrjala@nokia.com>
Reviewed-by: Luc Verhaegen <luc.verhaegen@basyskom.de>
Nothing should change in AdjustFrame that would need the composite clip
to be recomputed.
Signed-off-by: Ville Syrjälä <ville.syrjala@nokia.com>
Reviewed-by: Luc Verhaegen <luc.verhaegen@basyskom.de>
When ClipNotify gets called for a visible window, reput instead of
stopping the port. This eliminates nasty overlay flickering that
happens during clip changes.
If the window is invisible or if ReputImage isn't supported stop
and remove the port from the window as was done before.
Signed-off-by: Ville Syrjälä <ville.syrjala@nokia.com>
Reviewed-by: Luc Verhaegen <luc.verhaegen@basyskom.de>
Modify xf86XVReputOrStopPort() to allow stopping of all types of ports.
Will be useful later.
No functional change.
Signed-off-by: Ville Syrjälä <ville.syrjala@nokia.com>
Reviewed-by: Luc Verhaegen <luc.verhaegen@basyskom.de>
WinPriv->PortRec should never be NULL as WinPriv itself would be removed
from the list when the port is removed from the window.
Signed-off-by: Ville Syrjälä <ville.syrjala@nokia.com>
Reviewed-by: Luc Verhaegen <luc.verhaegen@basyskom.de>
A different approach which requires less variables setting
and internal knowledge of the reused code.
Changing from "install" to "not install" is very easy now.
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Signed-off-by: Keith Packard <keithp@keithp.com>
Relative paths don't always work in distcheck when srcdir not = builddir
include $(top_srcdir)/doc/xml/xmlrules.in
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This fixes a gamma issue on vt switch observed with KDM. VT switching away
and back would result in a black screen. Avoid this by storing the current
gamma information on init.
https://bugzilla.redhat.com/show_bug.cgi?id=533217
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 entering the VT, re-apply the saved gamma settings for each screen.
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 the vt gets a vhangup from under us, then the tty will appear ready
in select(), but trying to tcflush() it will return -EIO, so we'll spin
around at 100% CPU for no reason. Notice this condition and unregister
the handler if it happens.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
That helps us get rid of:
| CC xf86Config.lo
| xf86Config.c: In function ‘T.174’:
| xf86Config.c:1228: warning: ‘Pointer$module’ may be used uninitialized in this function
| xf86Config.c:1097: note: ‘Pointer$module’ was declared here
| xf86Config.c:1228: warning: ‘Pointer$drv’ may be used uninitialized in this function
| xf86Config.c:1097: note: ‘Pointer$drv’ was declared here
| xf86Config.c:1228: warning: ‘Pointer$type_name’ may be used uninitialized in this function
| xf86Config.c:1097: note: ‘Pointer$type_name’ was declared here
| xf86Config.c:1228: warning: ‘Pointer$private’ may be used uninitialized in this function
| xf86Config.c:1097: note: ‘Pointer$private’ was declared here
| xf86Config.c:1228: warning: ‘Pointer$dev’ may be used uninitialized in this function
| xf86Config.c:1097: note: ‘Pointer$dev’ was declared here
| xf86Config.c:1228: warning: ‘Pointer$fd’ may be used uninitialized in this function
| xf86Config.c:1097: note: ‘Pointer$fd’ was declared here
| xf86Config.c:1228: warning: ‘Pointer$set_device_valuators’ may be used uninitialized in this function
| xf86Config.c:1097: note: ‘Pointer$set_device_valuators’ was declared here
| xf86Config.c:1228: warning: ‘Pointer$switch_mode’ may be used uninitialized in this function
| xf86Config.c:1097: note: ‘Pointer$switch_mode’ was declared here
| xf86Config.c:1228: warning: ‘Pointer$control_proc’ may be used uninitialized in this function
| xf86Config.c:1097: note: ‘Pointer$control_proc’ was declared here
| xf86Config.c:1228: warning: ‘Pointer$read_input’ may be used uninitialized in this function
| xf86Config.c:1097: note: ‘Pointer$read_input’ was declared here
| xf86Config.c:1228: warning: ‘Pointer$device_control’ may be used uninitialized in this function
| xf86Config.c:1097: note: ‘Pointer$device_control’ was declared here
| xf86Config.c:1228: warning: ‘Pointer$flags’ may be used uninitialized in this function
| xf86Config.c:1097: note: ‘Pointer$flags’ was declared here
| xf86Config.c:1228: warning: ‘Pointer$next’ may be used uninitialized in this function
| xf86Config.c:1097: note: ‘Pointer$next’ was declared here
Signed-off-by: Cyril Brulebois <kibi@debian.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is a more accurate name for the actual functionality than
allowEmptyInput. Historically, allowEmptyInput has allowed the server to
start with no input devices. Since 1.4 and the introduction of VCP and VCK,
there are always two input devices present.
allowEmptyInput was changed in behaviour to essentially "ignore xorg.conf
devices or not", auto-adding the built-in devices if disabled.
Rename to forceInputDevices, because that's essentially what it does. When
disabled (i.e. when hotplugging is enabled), it disables all
mouse/kbd/vmmouse devices configured in the xorg.conf file.
When enabled, it forces the traditional behaviour for input devices:
- use input devices configured in the server layout
- if none are configured, use the first pointer and the first keyboard
device in the xorg.conf
- if none are configured, create the default pointer/keyboard devices.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Not used in the initial import, and also not documented.
Signed-off-by: Jesse Adkins <jesserayadkins@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
An estimated 100% (rounded down to the nearest percent) of the people who
have this in their configuration don't actually know what this option does.
Protect the users from themselves.
IIRC, AEI on was useful for some time between 1.4 and 1.5 and never since.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dan Nicholson <dbn.lists@gmail.com>
In all these cases, any rendering implied by this damage has already
occurred, and we want to get the damage out to the client. Some of
the DamageRegionAppend calls were explicitly telling damage to flush
the reportAfter damage out, but not all.
Bug #30260. Fixes the compiz wallpaper plugin with client damage
changed to reportAfter.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=24348
Before (data flag ignored -> broken):
66 DATA:
e944f1 JMP 1ff6
After (fixed):
66 DATA:
e944f1ffff JMP 00001ff8
This subtle difference in the length of decoded instruction meant
that the VBE call jumped to the routine setting AX=0x14F (VBE Failed)
instead of the routine that set AX=0x4F (VBE success).
The ability to run the same code in vm86 significantly aided the
debugging of this issue. Those X.org developers who would like to drop
vm86 better take special care towards _all_ vesa bugs, as those will
expose further issues.
Patch applies easily to even xserver 1.4.2.
Signed-off-by: Luc Verhaegen <libv@skynet.be>
Tested-by: Luc Verhaegen <libv@skynet.be>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Disable timer/keyboard trapping on GNU/Hurd for now
Trapping disabled for now, as some VBIOSes (mga-g450 notably) use these
ports, and the int10 wrapper is not emulating them.
It's effectively what happens in the Linux variant too, as iopl() is used there,
making the ioperm() meaningless.
Signed-off-by: Olaf Buddenhagen <antrik@users.sf.net>
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
DDX driver may implement schedule swap without GetMSC. In that case we
can't call GetMSC in DRI2SwapBuffers.
Signed-off-by: Pauli Nieminen <ext-pauli.nieminen@nokia.com>
Reviewed-by: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
CC: Keith Packard <keithp@keithp.com>
CC: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
This patch has been generated by the following Coccinelle semantic patch:
@@
expression E;
@@
- if (E != NULL)
- free(E);
+ free(E);
Signed-off-by: Cyril Brulebois <kibi@debian.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
../../../../hw/xfree86/common/xf86Config.c: In function 'configDRI':
../../../../hw/xfree86/common/xf86Config.c:2213:9: warning: unused variable
'i'
Introduced in 788bfbf18a
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
../../../../hw/xfree86/common/xf86Config.c: In function
'fixup_video_driver_list':
../../../../hw/xfree86/common/xf86Config.c:507:19: warning: unused variable
'atimisc'
../../../../hw/xfree86/common/xf86Config.c:507:12: warning: unused variable
'ati'
Introduced in 52577ae8ee.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
The functions in these files have not been used since trap
rasterization was moved to pixman. They survived until now to preserve
the server abi.
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Signed-off-by: Søren Sandmann <ssp@redhat.com>
Some drivers, most notably the mouse driver need this and reimplementing on
the driver side doesn't make sense.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Fix Xserver on GNU/Hurd into using the "mem" device instead of
the deprecated "iopl" device.
Reviewed-by: Olaf Buddenhagen <antrik@users.sf.net>
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
The XI2 protocol supports per-axis modes, but the server so far does
not. This change adds support in the server.
A complication is the fact that XI1 does not support per-axis modes.
The solution provided here is to set a per-device mode that defines the
mode of at least the first two valuators (X and Y). Note that initializing
the first two axes to a different mode than the device mode will fail.
For XI1 events, any axes following the first two that have the same mode
will be sent to clients, up to the first axis that has a different mode.
Thus, if a device has relative, then absolute, then relative mode axes,
only the first block of relative axes will be sent over XI1.
Since the XI2 protocol supports per-axis modes, all axes are sent to the
client.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
This commit introduces an abstraction API for handling masked valuators. The
intent is that drivers just allocate a mask, set the data and pass the mask
to the server. The actual storage type of the mask is hidden from the
drivers.
The new calls for drivers are:
valuator_mask_new() /* to allocate a valuator mask */
valuator_mask_zero() /* to reset a mask to zero */
valuator_mask_set() /* to set a valuator value */
The new interface to the server is
xf86PostMotionEventM()
xf86PostButtonEventM()
xf86PostKeyboardEventM()
xf86PostProximityEventM()
all taking a mask instead of the valuator array.
The ValuatorMask is currently defined for MAX_VALUATORS fixed size due to
memory allocation restrictions in SIGIO handlers.
For easier review, a lot of the code still uses separate valuator arrays.
This will be fixed in a later patch.
This patch was initially written by Chase Douglas.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
EventToCore as of the commit below won't generate core motion events if the
valuator mask for x/y isn't set. For DGA, we work around this check by
forcibly setting the mask in the event we pass down.
commit de8be07cc0
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Tue Aug 17 12:08:52 2010 +1000
dix: don't create core motion events for non-x/y valuators.
X.Org Bug 30267 <http://bugs.freedesktop.org/show_bug.cgi?id=30267>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Andrew Randrianasulu <randrik@mail.ru>
Tested-by: Andy Furniss
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
After we infer the aspect ratio for the screen, we pick the largest
mode matching that aspect ratio from the best mode pool available.
We then clamp virtual size to that mode, and run the resulting mode
list through the driver's ValidMode hook. In doing so we might filter
away our initial guess. If this happens we shrink the default mode
to the next largest mode from _any_ mode pool. This is usually wrong,
and we should instead pick the next aspect-matched mode from the best
available mode pool (as always, user then driver then default).
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
For whatever reason, some (broken) monitors will crash if you do this.
We're not actually using this information for anything, so let's just
not do it.
Originally reported as http://bugzilla.redhat.com/620333
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
This was only ever used from the glint driver, which has since lost its
DRI support.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
This was to distinguish XFree86 3.x files from XFree86 4.x files. It
never really made sense to be looking for xorg.conf-4.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Dan Nicholson <dbn.lists@gmail.com>
Reviewed-by: Jesse Adkins <jesserayadkins@gmail.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
