$ gcc --version
gcc (Gentoo 4.4.3-r2 p1.2) 4.4.3
/jhbuild/checkout/xorg/xserver/os/log.c: In function ‘LogInit’:
/jhbuild/checkout/xorg/xserver/os/log.c:199: error: #pragma GCC diagnostic not allowed inside functions
/jhbuild/checkout/xorg/xserver/os/log.c:201: warning: format not a string literal, argument types not checked
/jhbuild/checkout/xorg/xserver/os/log.c:212: error: #pragma GCC diagnostic not allowed inside functions
/jhbuild/checkout/xorg/xserver/os/log.c:214: warning: format not a string literal, argument types not checked
etc.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Since the sparse stuff is gone none of these variables get used for
anything, they're just dead side-effect-less execution.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
pciaccess does this for us, and none of our internal hooks really
remain. This does remove a cleanup pass from the BSD code, but the case
it's covering (a previous server leaving MTRRs around) can't happen
anymore.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
If the linux vm86 backend changes look somewhat horrifying to you,
that's because you have taste.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
The only driver even pretending to check the result is mach64 anyway.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
This API sucks. Fortunately it's mostly unused at this point. geode,
sis, and xgi need minor patches to use the corresponding pciaccess code,
neomagic will (more explicitly) lose its non-PCI support, and newport
will need to be ported to /dev/mem or the platform bus or something.
This should also make it pretty clear that alpha's sparse memory support
was basically not a thing anymore, very few tears shed.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
I ported these to pciaccess in:
commit 858fbbb40d
Author: Adam Jackson <ajax@redhat.com>
Date: Fri Sep 16 13:33:04 2011 -0400
pci: Port xf86MapLegacyIO to pciaccess
As of yet there are still no drivers using them, and there's not a lot
of value in having the wrappers when they just trivially call pciaccess
anyway. Nuke 'em.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Non-barrier-emitting MMIO writes. They appear to be utterly unused,
burn it all down.
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
OdevAttributes are a fixed set of values with known types; instead of
storing them in a linked list and requiring accessor/settor functions,
replace the list header, struct OdevAttributes, with a struct that
directly contains the values. This provides for compile-time
typechecking of the values, eliminates a significant amount of code
and generally simplifies using this datatype.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
While at it also replace a tab by four spaces for consistency.
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Tested-By: Aaron Plattner <aplattner@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Tested-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
When opening a DRM device, query the version and store the driver name
as a new attribute for future reference.
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Tested-By: Aaron Plattner <aplattner@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Tested-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Xorg server could be built for and run on Synopsys DesignWare ARC cores.
These changes are required for successful building and execution of the server.
Both little-endian and big-endian flavors of ARC cores are supported.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Acked-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Egbert Eich <eich@freedesktop.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
We can only request one fd per device from systemd-logind. If a fd is re-used
by the same device, releasing the fd from one device doesn't mean we can close
it. The systemd code knows when it's really released, so let it close the fd.
Test case: xorg.conf section for an input device with hotplugging enabled.
evdev detects the duplicate and closes the hotplugged device, which closes the
fd. The other instance of evdev thinks the fd is still valid so now you're
playing a double lottery. First, which client(s) will get the evdev fd?
Second, which requests will be picked up by evdev and which ones will be
picked up by the client? You'll never know, but the fun is in finding out.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
When we're using server managed-fds through systemd-logind, systemd-logind
*must* keep running while we are using it, as it does things like drmSetMaster
and drmDropMaster for us on vt-switch.
On a systemd-logind restart, we cannot simply re-connect since we will then
get a different fd for the /dev/dri/card# node, and we've tied a lot of
state to the old fd. I've discussed this with the systemd people, and in the
future there may be a restart mechanism were systemd-logind passed fds from
the old logind to the new logind. But for now there answer is simply:
"Don't restart systemd-logind", and there never really is a good reason to
restart it.
So to ensure unpleasentness if people do decide to restart systemd-logind
anyways (or when it crashes), monitor logind going away and make this a fatal
error. This avoids getting a hard-hung machine on the next vt-switch and will
hopefully quickly educate users to not restart systemd-logind while they have
an X session using it active.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
InputDevices may share a single device-node, this happens ie with Wacom
tablets.
This patch makes take_fd and release_fd properly deal with this, together
with the earlier patch for updating the fd in all matching xf86InputDevs
on pause / resume this completes support for such shared device-nodes.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
And use it where appropriate.
Setting the fd for all matching InputDevices is necessary when we've
multiple InputDevices sharing a single device-node, such as happens with
Wacom tablets.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
This is a preparation patch for adding support for server managed fds
for InputDevices where multiple input devices share the same device node (and
thus also their major and minor).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Modify systemd_logind_find_info_ptr_by_devnum to take a start argument, so
that it can be used to find all occurences of a devnum in an InputInfo list,
rather then just the first.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Note that there are more callers but those were already not doing any
error checking.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
If there is only a single non kms video device (tested with the vesa driver),
then we will never get a resume signal for a drm node, so also call vtenter
when we get a resume for an input device.
Notes:
1) vtenter checks if it is ok to do the vtenter, so if there are kms video
devices the calls for input device resumes are a nop
2) This assumes that there will always be at least one server event fd
supporting input device. Since all non legacy input-drivers will be patched
to supported server fds this seems a safe assumption.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Try to get a server managed fd from the Options before trying to open the
device node ourselves.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
With systemd-logind we cannot probe input devices while switched away, so
if we're switched away, put the pInfo on a list, and probe everything on
that list on VT-Enter.
This is using an array grown by re-alloc, rather than a xorg_list since
creating a new data-type to store a pInfo + list-entry just for this seems
overkill.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
This commits makes the changes necessary outside of the systemd-logind core
to make the server use systemd-logind managed fds for input devices and drm
nodes.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
This commits add the bulk of the systemd-logind integration code, but does
not hook it up yet other then calling its init and fini functions, which
don't do that much.
Note the configure bits check for udev since systemd-logind use will only be
supported in combination with udev. Besides that it only checks for dbus
since all communication with systemd-logind is happening over dbus, so
no further libs are needed.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
The OdevAttributes struct should just be a head of the attributes list, and
not contain various unrelated flags. Instead add a flags field to
struct xf86_platform_device and use that.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Add a config_odev_get_attribute helper, and replace the diy looping over all
the attributes done in various places with calls to this helper.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Detaching from our controlling tty makes little sense when it is the same
as the vt we're asked to run on. So automatically assume -keeptty in this case.
This is useful to do because when not running as root the server can only make
various VT related ioctls when it does not detach from the tty.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
There is no reason why keeptty cannot be used without root-rights.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
asm/mtrr.h makes this an unsigned long on 32, but a u64 on 64. Cast
it to a long to win.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
These are generated in code which uses sprintf as a convenient way to
construct strings from various pieces.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
This lets us stop using the 'pointer' typedef in Xdefs.h as 'pointer'
is used throughout the X server for other things, and having duplicate
names generates compiler warnings.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Having this function be static generates a compiler warning.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This gets the easy warnings, mostly constant string problems.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Andreas Schwab <schwab@suse.de>
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
newer automake gets quite noisy about this.
hw/xfree86/ddc/Makefile.am:7: warning:
'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
and many more of these.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
* __FreeBSD_kernel_version doesn't exist anymore
* The removed check was for FreeBSD versions from before September 2000
which are no longer supported anyway
* Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=66045
Signed-off-by: François Tigeot <ftigeot@wolfpond.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
