When the linux kernel sets the NX bit vm86 segfaults when it tries to execute
code in memory that is not marked EXEC. Such code gets called whenever
we return from a VBIOS call to signal the calling program that the call
is actually finished and that we are not trapping for other reasons (like
IO accesses).
Use mprotect(2) to set these memory ranges PROT_EXEC.
Works around a silly bug in the kernel that causes wakeup storms after
too many keypresses. Should fix the kernel bug too, but this at least
keeps the idle wakeup count below 1000/sec.
Also merge sun_bios.c into sun_vid.c and upstream Solaris patch to
keep aperture device open, to allow mappings to occur after X server
has given up uid 0.
Add automatic detection of the graphic driver to load for sbus devices.
This allows xorg to work on those devices without a "Device" section.
Debian bug#483942.
Signed-off-by: Julien Cristau <jcristau@debian.org>
Usually, the console is set to RAW in the kbd driver. If we hotplug all input
devices (i.e. the evdev driver for keyboards) and the console is left as-is.
As a result, the evdev driver must put an EVIOCGRAB on the device to avoid
characters leaking onto the console. This again breaks many things, amongst
them lirc, in-kernel mouse button emulation and HAL.
This patch sets the console to RAW if AllowEmptyInput is on.
Use-cases:
1. AEI is off
1.1. Only kbd driver is used - behaviour as-is.
1.2. kbd and evdev driver is used: if evdev does not grab the device,
duplicate events are generated.
2. AEI is on
2.1. Only evdev driver is used - behaviour as-is, but evdev does not need
to grab the device anymore.
2.2. evdev and kbd are used: duplicate key events are generated if evdev
does not grab the device.
1.2 is a marginal use-case that can be fixed by adding a "grab" option to the
evdev driver (update of xorg.conf is needed).
2.2 is an issue. If we have no ServerLayout section, AEI is on, but devices
specified in the xorg.conf are still added [1], resulting in duplicate events.
This is a common configuration and needs sorting out.
[1] 2eaed4a10f
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
There is no way this code can have been building for anyone since pciaccess
was merged. BSD and Linux were already using OS code on sparc, the only
people who could want this are Solaris, who should be using pciaccess
anyway.
This code was effectively only used in ix86Pci.c to select PCI config
access type. Nobody should be using that path anymore, in the glorious
pciaccess world; kernel services should get it right for you.
Spiritual revert of 1fa4de80fc. Intel's C
compiler claims to be gcc-compatible; if they're not defining the same
macros as gcc then that's their bug, not ours. Even if we were to do
this aliasing we should do it once and for all in servermd.h.
GNU/kFreeBSD defines __FreeBSD_kernel__, but not __FreeBSD__.
Unify preprocessor conditionals between variable declaration and use.
Debian bug #482550.
Seeing as this code seems to be specific to OpenBSD I don't think
__x86_64__ should have been added there at all. It appears to have
been added wherever __amd64__ existed before which is wrong. I
think that part of the commit should be reverted but also all four of
the checks should be __OpenBSD__ && __amd64__ instead of two one
direction and two flipped.
The jstk code for Joysticks is not used by any module, was never actually compiled and uses an API
that is deprecated these days.
No reason to keep it.
xserver and libpciaccess both need to open /dev/xf86, which can only
be opened once. I implemented pci_system_init_dev_mem() like Ian
suggested. This requires some minor changes to the BSD-specific
os-support code. Since pci_system_init_dev_mem() is a no-op on
FreeBSD this should be no problem.
