Xext/xf86bigfont.c contains three non-static functions which are called
elsewhere in the server. This creates a new header containing these
declarations in order to fix several warnings:
xf86bigfont.c:285: warning: no previous prototype for `XF86BigfontFreeFontShm'
dixfonts.c:502: warning: implicit declaration of function `XF86BigfontFreeFontS$
dixfonts.c:502: warning: nested extern declaration of `XF86BigfontFreeFontShm'
log.c:436: warning: implicit declaration of function `XF86BigfontCleanup'
log.c:436: warning: nested extern declaration of `XF86BigfontCleanup'
Signed-off-by: Yaakov Selkowitz <yselkowitz@users.sourceforge.net>
Reviewed-by: Julien Cristau <jcristau@debian.org>
If make relink fails in a subdirectory, we need to catch the error
otherwise make will continue iterating the 'for' loop.
Signed-off-by: Yaakov Selkowitz <yselkowitz@users.sourceforge.net>
Reviewed-by: Dan Nicholson <dbn.lists@gmail.com>
Add $(AM_V_GEN) for sed-based rules so they appear as expected with
automake silent rules, and $(AM_V_at) to completely hide cp/ln/rm
commands which are not prone to fail.
Signed-off-by: Yaakov Selkowitz <yselkowitz@users.sourceforge.net>
Reviewed-by: Alan Coopersmith <alan.coopersmith@sun.com>
Reviewed-by: Julien Cristau <jcristau@debian.org>
We now use libtool, which calls AC_PROG_SED and sets SED as the path to
a fully-functional 'sed' (which may also be called 'gsed' if GNU sed is
installed alongside a proprietary version). Therefore we should respect
the value of SED so we are sure to use the correct one.
Signed-off-by: Yaakov Selkowitz <yselkowitz@users.sourceforge.net>
Reviewed-by: Alan Coopersmith <alan.coopersmith@sun.com>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Add $(AM_V_at) to all relink make targets to silence them when automake
silent rules are in use.
Signed-off-by: Yaakov Selkowitz <yselkowitz@users.sourceforge.net>
Reviewed-by: Alan Coopersmith <alan.coopersmith@sun.com>
Reviewed-by: Julien Cristau <jcristau@debian.org>
On Cygwin and MinGW, executables use the .exe suffix. Autoconf and
automake set EXEEXT on these platforms, and leave it empty on others
where no suffix is used. $(EXEEXT) must be appended to executable names
in custom rules for portability:
http://www.gnu.org/software/automake/manual/html_node/EXEEXT.html
Signed-off-by: Yaakov Selkowitz <yselkowitz@users.sourceforge.net>
Reviewed-by: Alan Coopersmith <alan.coopersmith@sun.com>
Reviewed-by: Julien Cristau <jcristau@debian.org>
The linker flag required for exporting symbols in executables varies
by platform. libtool handles this with a single -export-dynamic
flag (not to be confused with the similarly-named ELF linker flag)
which tells it to use the correct platform-specific flag at link time.
Signed-off-by: Yaakov Selkowitz <yselkowitz@users.sourceforge.net>
Reviewed-by: Dan Nicholson <dbn.lists@gmail.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
The DMX Xdmx server and xdmx client cannot both be installed on
case-insensitive file systems. The client is undocumented and
so renaming it is the best option.
Signed-off-by: Yaakov Selkowitz <yselkowitz@users.sourceforge.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Yaakov Selkowitz <yselkowitz@users.sourceforge.net>
Acked-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
I'm not quite sure why this was necessary, but DDXRingBell is being called
from CoreKeyboardBell, so we don't need a separate bellProc which would
result in multiple rings.
This reverts commit 9071b0d697.
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
A client requesting a GrabModeSync button grab, owner-events true, with only
the ButtonRelease mask set would never receive the press event even if the
grab window had the ButtonPress mask set.
The protocol requires that if owner-events is true, then the delivery mask
is the combination of the grab mask + the window event mask.
X.Org Bug 25400 <http://bugs.freedesktop.org/show_bug.cgi?id=25400>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Jim Ramsay <i.am@jimramsay.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
buffer_alloc: Called allocating function "realloc" which allocated memory dictated by parameter "len + strlen(displaySize_string)"
alloc_strlen: Allocated memory does not have space for the terminating NUL of the string
var_assign: Assigned "ptr->mon_comment" to storage allocated by "realloc(ptr->mon_comment, len + strlen(displaySize_string))"
Signed-off-by: Oliver McFadden <oliver.mcfadden@nokia.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Oliver McFadden <oliver.mcfadden@nokia.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Oliver McFadden <oliver.mcfadden@nokia.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Allow the default log location to be configurable (e.g. /var/log),
and use separate logs for each display instance (e.g. XWin.0.log).
Make the type of g_pszLogFile const char*, per os/log.c:LogInit().
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
Fix warnings due to prototypes not specifying function arguments
Fix warning with RegQueryValueEx()
Tidy up an include
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Remove some dead code, mostly code made obsolete by mandatory XKB
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Tidy up some cosmetic issues in log strings:
- Add missing '\n'
- Fix some strings starting with '\n'
- Remove '\f' from some log strings
These all just look daft in a log with timestamps.
Also clarify log message about screen origin coordinates
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
Fix a thinko in mount option checking.
Use symbolic names for values assigned to binary flag for clarity.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
It can be quite an expensive operation, so we're better off not doing
it unless it's totally required.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Borrowed from i830.h, except for list_for_each_entry().
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Executed from the ConfigureWindow request, right before sending
ConfigureNotify to the clients.
This commit breaks the ScreenRec ABI.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
The problem is that the xf86_use_hw_cursor(_argb) functions may get this
correctly now, some drivers will replace these generic versions with their
own functions. It is pretty insane to expect them to do reference counting
of the cursor (as an example, look at driver/xf86-video-vmware to see how
that looks like as a workaround). There are even places in xserver itself
which replace these two functions.
The segfaults if no reference counting is done are caused because the
reference count of the cursor reached zero, hence the cursor was freed,
however xf86CursorEnableDisableFBAccess() brought it back to life from
the dead (from the SavedCursor).
This patch hence adds reference counting in xf86CursorSetCursor. As per Michel
Daenzer's suggestion, also free the cursor upon xf86CursorCloseScreen.
In theory with this it should be possible to remove the reference
counting in the UseHwCursor functions I think, though it should also be
safe to keep them.
Signed-off-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Michel Dänzer <michel@daenzer.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
This is the same fix as was done in
fcdc1d78cc for xf86_use_hw_cursor_argb.
Signed-off-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Michel Dänzer <michel@daenzer.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
This is a variable local to configure.ac which is not AC_SUBST()
It is undefined in any generated Makefile.
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Signed-off-by: Keith Packard <keithp@keithp.com>
Although the DDX should be linked to the necessary libraries, we may
also need to pull them in directly to the module to ensure the symbols
are resolved at runtime. Should fix this bug with XSELINUX:
/usr/bin/X: symbol lookup error:
/usr/lib64/xorg/modules/extensions/libextmod.so: undefined symbol:
is_selinux_enabled
-v2: use _LIBADD instead of _LIBS; remove SELINUX_LIBS from
XSERVER_SYS_LIBS as it should only be needed in extmod.
Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
Signed-off-by: Eamon Walsh <ewalsh@tycho.nsa.gov>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reintroduce a check which used to be there in the old
ProcessKeyboardEvent/ProcessPointerEvent codepath, which avoids us
recording events subject to a grab twice: once when it's first processed
in EnqueueEvent, and then again when it's thawed and being replayed.
This required a tiny amount of code motion to expose syncEvents.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Several users have pointed out that this commit introduces regressions, most
notably perhaps fluxbox which essentially stops working after a few clicks.
This reverts commit cf72b5437d.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
xf86Config.c: In function 'configInputDevices':
xf86Config.c:1514: error: request for member 'lay_identifier' in something
not a structure or union
make[5]: *** [xf86Config.lo] Error 1
Introduced with e1165632bd.
X.Org Bug 26971 <http://bugs.freedesktop.org/show_bug.cgi?id=26971>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Dan Nicholson <dbn.lists@gmail.com>
In the vast majority of cases there is no xorg.conf that specifies a core
pointer/keyboard. Skip this warning, since we'll get another notification
about how the server relies on the config backend for input devices anyway.
Leave the warning in for the error case (AEI off).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Fernando Carrijo <fcarrijo@yahoo.com.br>
Reviewed-by: Dan Nicholson <dbn.lists@gmail.com>
There doesn't seem to be anything that defines it and given that the
counterpart (the X internal malloc) was removed in
01cfba7522 it's unlikely to work anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
An absolute device in relative mode may provide valuators outside of the
axis range. Clipping back into the range prevents screen crossings in a
multi-screen (Xinerama) setup as the required screen edge for crossing is
never met: miPointerSetPosition crosses the screen conditional to the X
coordinate being equal to the screen width or _less than_ 0. While the
former can be met when clipping into the coordinate range and scaling, the
latter cannot, resulting in a mouse pointer that gets stuck on the rightmost
screen.
This patch only applies axis clipping for valuators in mode Absolute. If
relative, we allow the values to get above/below the axis ranges. Doesn't
matter, miPointerSetPosition will reset the values to the allowed range even
if no screen was crossed.
This leads to interesting values provided to clients, the valuator range of
the device resets once a screen is crossed and essentially reflects
the position of the cursor on the screen - scaled into the valuator range.
The values themselves are valid given the range though.
In theory, the XI1 specs require that a relative device has a min/max range
of 0/0. This doesn't really go well with devices that actually can switch
mode between relative and absolute since they would have to reset their axis
range when switching. If multiple XI clients are in use, we have no method
of notifying them about the changes, so other clients may continue to use
the wrong axis ranges (note: XI1 wasn't really designed to have multiple
clients use a device). Expecting all relative devices to have this min/max
of 0 is unrealistic at this point.
So pick what is possibly the lesser of all evils, pass the beer and despair.
X.Org Bug 26543 <http://bugs.freedesktop.org/show_bug.cgi?id=26543>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
