The functions are already declared in xf86xv.h
Signed-off-by: Michal Suchanek <hramrach@gmail.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
If a device was enabled before the VT switch, re-enabled it. Otherwise leave
it as is, there was probably a reason why it was disabled.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Cygwin doesn't have ELF rpath capabilities, so these libraries need
to be loaded before the drivers (namely dummy and nested) which
depend on their symbols.
Signed-off-by: Yaakov Selkowitz <yselkowitz@users.sourceforge.net>
Reviewed-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
This is necessary when building Xorg and XWin simultaneously, otherwise
undefined symbol errors result in sdksyms.c.
Signed-off-by: Yaakov Selkowitz <yselkowitz@users.sourceforge.net>
Reviewed-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
This is strictly the application of the script 'x-indent-all.sh'
from util/modular. Compared to the patch that Daniel posted in
January, I've added a few indent flags:
-bap
-psl
-T PrivatePtr
-T pmWait
-T _XFUNCPROTOBEGIN
-T _XFUNCPROTOEND
-T _X_EXPORT
The typedefs were needed to make the output of sdksyms.sh match the
previous output, otherwise, the code is formatted badly enough that
sdksyms.sh generates incorrect output.
The generated code was compared with the previous version and found to
be essentially identical -- "assert" line numbers and BUILD_TIME were
the only differences found.
The comparison was done with this script:
dir1=$1
dir2=$2
for dir in $dir1 $dir2; do
(cd $dir && find . -name '*.o' | while read file; do
dir=`dirname $file`
base=`basename $file .o`
dump=$dir/$base.dump
objdump -d $file > $dump
done)
done
find $dir1 -name '*.dump' | while read dump; do
otherdump=`echo $dump | sed "s;$dir1;$dir2;"`
diff -u $dump $otherdump
done
Signed-off-by: Keith Packard <keithp@keithp.com>
Acked-by: Daniel Stone <daniel@fooishbar.org>
Acked-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Rename functions/macros from list_* to xorg_list_*
Rename struct from struct list to struct xorg_list.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
In-sed-I-trust: Peter Hutterer <peter.hutterer@who-t.net>
Check for identifier first and bail if it's missing (also remove the current
identifier check after we've already bailed due to missing identifiers)
If a driver is missing, warn but also say that we may have added this device
already. I see too many bugreports with incorrectly shortened log files.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Cyril Brulebois <kibi@debian.org>
Side effect of aa0bfb0f133481c57762012e8e30c05ffa151423:
| CCLD Xorg
| sdksyms.o:(.data.rel+0x27d8): undefined reference to `outl'
| collect2: ld returned 1 exit status
Since the linux/ia64 domain I/O support code got removed in that
commit, there's no reason to keep on declaring those functions
(inb, inl, inw, outb, outl, outw).
Bugzilla: https://bugs.freedesktop.org/43985
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Signed-off-by: Cyril Brulebois <kibi@debian.org>
New additions to the API:
- InitTouchClassDeviceStruct
- xf86PostTouchEvent
Changes to the ABI:
- DeviceIntRec now contains a TouchClassPtr
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
xf86PostTouchEvent is the driver API to submit touch events to the server.
This API doesn't do anything yet though but now we can at least bump the
API.
For valuators, drivers should use the existing xf86InitValuatorAxisStruct
function.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
This allows us to run the server as a normal user whilst still
being able to use the -modulepath, -logfile and -config switches
We define a xf86PrivsElevated which will do the checks and cache
the result in case it is called more than once.
Also renamed the paths #defines to match their new meaning.
Original discussion which led to this patch can be found here:
http://lists.freedesktop.org/archives/xorg-devel/2011-September/025853.html
Signed-off-by: Antoine Martin <antoine@nagafix.co.uk>
Tested-by: Michal Suchanek <hramrach at centrum.cz>
Reviewed-by: Jamey Sharp <jamey at minilop.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Both functions call exit() at the end and have no other return path.
Also correct comment/heading to reflect commit 6450f6ca7e moving
DoShowOptions into xf86Configure.c.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Since all we do with the option list is walk down the list printing
the names, there's no need to cast away its constness.
Clears gcc warning:
xf86Configure.c: In function 'DoShowOptions':
xf86Configure.c:781:4: warning: cast discards qualifiers from pointer target type
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
If we didn't go into the if (!autoconfig) { } block, the filename,
dirname, and sysdirname pointers were never initialized, but we
freed them outside the block, leading to potential memory corruption.
Move the frees inside the block where they're initialized to avoid this.
To avoid similar problems, move the declarations of the variables that
are only used in this block inside the block.
Regression introduced by commit 3d635fe84d
Found by gcc warning:
xf86Config.c: In function 'xf86HandleConfigFile':
xf86Config.c:2303:11: warning: 'filename' may be used uninitialized in this function
xf86Config.c:2303:22: warning: 'dirname' may be used uninitialized in this function
xf86Config.c:2303:32: warning: 'sysdirname' may be used uninitialized in this function
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
It will never return NULL, so don't try to handle a NULL condition,
since that just confuses programmers and static analyzers.
It uses calloc, so all the allocated memory is cleared, so there's
no point looping over the memory to manually initialize it NULL.
And just because it's annoying, it doesn't need to be the only
place in this file to do if (NULL==...) instead of if (... == NULL).
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Avoids the dummy-event dance if we have an event type and need to get the
matching XI2 type.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
We call xf86penConfigDirFiles twice, so we overwrite the configDirPath
variable, losing the pointer. If we move the pointer management to the
upper layer (the function callers), they will be able to call these
functions as many times as they want, but they'll have to free those
returned values.
v2: don't leak inside XWin
4,097 bytes in 1 blocks are definitely lost in loss record 625 of 632
at 0x4C2779D: malloc (in vgpreload_memcheck-amd64-linux.so)
by 0x4D7899: DoSubstitution (scan.c:615)
by 0x4D87B0: OpenConfigDir (scan.c:845)
by 0x4D8A2D: xf86openConfigDirFiles (scan.c:955)
by 0x49031F: xf86HandleConfigFile (xf86Config.c:2327)
by 0x49A9BF: InitOutput (xf86Init.c:365)
by 0x425A7A: main (main.c:204)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Dan Nicholson <dbn.lists@gmail.com>
This batch is the straightforward set - others are more complex and
need more analysis to determine right size to pass.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Found no calls from current driver modules
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Gets rid of duplicate static copy of optionTypeToString by putting
both callers of that helper function in the same source file.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
When we want to print a string, it's okay to just print it.
We don't need to first allocate a buffer 2 bytes bigger than the
string, copy the entire string unmodified to the buffer, print the
buffer, and then leak the buffer (though we AbortDDX 8 lines later,
and then just in case we survived that, call exit as well, so the
leak is short lived, just oh so pointless).
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
As long as we're carrying around a compatibility copy in os/strl*.c,
might as well use them.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
We don't ship either one, so don't waste time and make confusing log
entries trying to load them.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Wherever it's obvious which device we need (keyboard or pointer), use
GetMaster() instead of GetPairedDevice(). It is more reliable in actually
getting the device type we want.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
xorg.conf devices had the name and driver set in the DDX's InputInfoPtr list
but not in the option list for those devices. That information was lost when
passing the options into NewInputDeviceRequest. NIDR then refused to start
the devices.
Introduced in xorg-server-1.11.0-250-ge4cd24e
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: James Cloos <cloos@jhcloos.com>
Add nouveau as the first driver on linux for NVIDIA hardware when
driver autoconfiguration is done, as it is more capable than nv.
nv is also kept in the list as it is more widely supported and because
some old cards are not supported by nouveau.
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Cyril Brulebois <kibi@debian.org>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Only use one init path for input devices - through NIDR.
This requires that inp_driver and inp_identifier from the
XF86ConfInputRec are copied over into the options for NIDR to see them.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
The former strdups for us. If the strdup fails we miss out on the
CorePointer option (default on anyway) and we're likely to fall over soon
anyway, so let's pretend this is the same behaviour.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Use the same struct for both InputOption and XF86OptionRec so we don't need
to convert to and fro the two in the config backends.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dan Nicholson <dbn.lists@gmail.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Bug introduced by 9dca441670
xfree86: add a hook to replace the new console handler.
console_handler was not being set, making the server eat up CPU spinning
in WaitForSomething selecting consoleFd over and over again, every time
trying to unregister drain_console without success due to
console_handler being NULL.
Let's just fix the unregistration in xf86SetConsoleHandler() and use that.
But wait, there could be a catch: If some driver replaced the handler using
xf86SetConsoleHandler(), the unregistration in xf86CloseConsole will unregister
that one. I don't understand Xorg well enough to know whether this poses a
problem (could mess up driver deinit somehow or something like that). As it is,
xf86SetConsoleHandler() doesn't offer any way to prevent this (i.e. check which
handler is currently registered).
I had been using it for two days on my machine that previously hit 100% CPU
several times a day. That has now gone away without any new problems appearing.
Signed-off-by: Tomas Trnka <tomastrnka@gmx.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
