Maybe one day I stop doing stupid patches like
a3a7c12fcf.
So, if X < low, reset to low, and _not_ to high.
If X > high, reset to high, and _not_ to low.
This consists of two parts:
In the implicit server layout, ignore those drivers when looking for a core
device.
And after finishing the server layout, run through the list of devices and
remove any that use mouse or kbd.
AEI is mutually exclusive with the kbd and mouse drivers, so pick either - or.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
The precedence of == is higher than that of &, so that code was
probably buggy.
xf86Init.c: In function 'DoModalias':
xf86Init.c:300: warning: suggest parentheses around comparison in operand of &
xf86Init.c:304: warning: suggest parentheses around comparison in operand of &
xf86Init.c:308: warning: suggest parentheses around comparison in operand of &
xf86Init.c:136: warning: function declaration isn't a prototype
xf86Init.c:243: warning: function declaration isn't a prototype
xf86Init.c:249: warning: function declaration isn't a prototype
Add missing includes to fix the following warnings:
xf86DGA.c: In function 'DGAProcessKeyboardEvent':
xf86DGA.c:1050: warning: implicit declaration of function 'UpdateDeviceState'
xf86DGA.c:1050: warning: nested extern declaration of 'UpdateDeviceState'
xf86Xinput.c: In function 'xf86ActivateDevice':
xf86Xinput.c:303: warning: implicit declaration of function 'AssignTypeAndName'
xf86Xinput.c:303: warning: nested extern declaration of 'AssignTypeAndName'
xf86Xinput.c:311: warning: implicit declaration of function 'DeviceIsPointerType'
xf86Xinput.c:311: warning: nested extern declaration of 'DeviceIsPointerType'
xf86Xinput.c:324: warning: implicit declaration of function 'XkbSetExtension'
xf86Xinput.c:324: warning: nested extern declaration of 'XkbSetExtension'
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>
Also set AutoAddDevices and AutoEnableDevices to their defaults.
And in doing so, switch the rest of the defaults over to named intializers.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
NIDR should be used to create a new SD from e.g. within a driver.
DIDR should be used to remove a device from the server.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
If you need to bail out the server, use Ctrl-Alt-Fx, or enable zapping
if it bothers you that much. If Ctrl-Alt-Fx is broken, nag me until
it's permanently fixed.
The nvidia driver currently uses these hooks to work around problems where RAC
will disable access to the hardware at unexpected times. This change restores
these hooks until we can come up with a better API for working around RAC.
This reverts commit c1df4fbede.
The nvidia driver currently uses these callbacks to work around problems where
RAC will disable access to the hardware at unexpected times. This change
restores these hooks until we can come up with a better API for working around
RAC.
This reverts commit d7c0ba2e9e.
Conflicts:
hw/xfree86/loader/xf86sym.c
If anyone can come up with an example of a bus where:
- both i/o and memory resources are addressable
- access to them can be controlled
- but they can't be controlled independently
then by all means, reinstate this logic.
No point warning about missing driver hooks, that just means the person
who gave you the driver is inept. Might as well just crash. Also,
just name anonymous screens as screen%d instead of failing after the 36th
screen. Bonus points if you can figure out what the failure mode would
be on the 36th screen, and what the effective screen limit was.
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.
the defaults from InitVelocityData() or hypothetic driver-side changes
are now respected, not overridden.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If the device doesn't have any BARs then it's just a stub for some
lame operating systems that need one PCI device per output for
multihead. No point in warning about it.
It's all a bit wonky since both sis(4) and xgi(4) claim to support the
Volari Z7 and V5/8 (0x0020 and 0x0040), so let's side with xgi(4), why
not. Note that the V3 (not V3XT) identifies itself as a trident chip.
Put out a warning if xorg.conf has InputDevice sections, but these aren't
referenced in the used ServerLayout. This is only performed if AllowEmptyInput
is enabled.
The reason behind this is that the server used to auto-add the first
mouse/keyboard sections if none where referenced. Now, with HAL and AEI
enabled by default, setups that relied on this auto-adding break and are left
without input devices. The least we can do is warn them.
- Use a single common function to compute reducedness.
- Call it from both the old-school and new-school mode validation paths.
- Define monitor reduced-blanking support in accord with EDID 1.4.
- Attempt to filter RB DMT modes away from the "standard" EDID pool if
the monitor doesn't claim RB support.
OsInitColors always just returned TRUE, so just remove calls to it and
insane special-case logic. Remove unused kcolor.c implementation, and
merge oscolor.h into oscolor.c since it was the only user. Remove
open-coded strncasecmp in oscolor.c.
Since we no longer need to call OsInitColors after reading the config
file, just call PostConfigInit() from one place, and move PM handling to
one place so we can install the signal handlers earlier.
If devices are prepended to the list, their wake-up order on resume is not the
same as the original initialisation order. Hot-plugged devices, originally
inited last, are re-enabled before the xorg.conf devices and in some cases may
steal the device files. Result: we have different devices before and after
suspend/resume.
RedHat Bug 439386 <https://bugzilla.redhat.com/show_bug.cgi?id=439386>
