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.
Under the terms of version 1.1, "once Covered Code has been published
under a particular version of the License, Recipient may, for the
duration of the License, continue to use it under the terms of that
version, or choose to use such Covered Code under the terms of any
subsequent version published by SGI."
FreeB 2.0 license refers to "dates of first publication". They are here
taken to be 1991-2000, as noted in the original license text:
** Original Code. The Original Code is: OpenGL Sample Implementation,
** Version 1.2.1, released January 26, 2000, developed by Silicon Graphics,
** Inc. The Original Code is Copyright (c) 1991-2000 Silicon Graphics, Inc.
** Copyright in any portions created by third parties is as indicated
** elsewhere herein. All Rights Reserved.
Official FreeB 2.0 text:
http://oss.sgi.com/projects/FreeB/SGIFreeSWLicB.2.0.pdf
As always, this code has not been tested for conformance with the OpenGL
specification. OpenGL conformance testing is available from
http://khronos.org/ and is required for use of the OpenGL logo in
product advertising and promotion.
The check can fail because the output from FBIOGET_VSCREENINFO is used to set
Clock in fbdev2xfree_timing(). Then in fbdevHWSetMode(), xfree2fbdev_timing()
is called which sets the pixclock based on Clock. The resulting circle results
in slight rounding errors, causing the comparision check in fbdev_modes_equal
to fail.
- Redo damage naming for more consistency.
- Call post submission functions only where appropriate.
- EXA can now live without it's odd damage workarounds.
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.
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.
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.
Us shipping a GUI configuration utility (especially as part of the
server!) was pretty pointless. There was pretty much nothing it could
configure which wasn't already runtime adjustable: if you could get a
server up with functioning input and output, there wasn't much xorgcfg
could do for you.
Au revoir.
- 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.
On some panels you end up with all of:
- No range descriptor
- No description of physical connectivity
- Native panel size mode in standard timings list
In principle you're supposed to use the timings for that mode from the DMT
spec, but in practice the DMT spec has timings for both 1920x1200 normal
and 1920x1200RB, and the standard timing field gives you no way to
distinguish. And, of course, the non-RB timings don't fit in a single
DVI link.
A couple #if defined(Lynx) && defined(sun) had become just if defined(sun),
resulting in wrong settings for Solaris builds, so they're now just deleted.
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>
- Allow returning multiple drivers to try for a given PCI id (for instance,
try "geode" then "amd" for AMD Geode hardware)
- On Solaris, use VIS_GETIDENTIFIER ioctl as well as PCI id to choose drivers
- Use wsfb instead of fbdev as a fallback on non-Linux SPARC platforms
Remove AEI check from configImpliedLayout as the setting isn't actually parsed
at this point anyway (written by Sasha Hlusiak).
Resurrect checkInput() and check for devices there if AEI is false (this also
creates the default devices if required).
Set AllowEmptyInput to enabled by default if hotplugging is enabled.
If no Screen is specified in the ServerLayout section, either take the first
one from the config file or autogenerate a default screen.
X.Org Bug 16301 <http://bugs.freedesktop.org/show_bug.cgi?id=16301>
RandR 1.1 has a physical size for each mode. It used to be that the DIX would
remember these modes and pass them back up to the DDX when changing the screen
configuration. The DDX uses RR_GET_MODE_MM to query the driver for the physical
dimensions of the screen, allowing it to preserve the DPI.
With RandR 1.2, the physical dimensions are stored as part of the output, rather
than per mode. The DIX only uses the sizes passed in from the DDX to select the
mode pool for the "default" output, and forgets the physical sizes. Then, when
reconfiguring the screen, it makes up a new RRScreenSizeRec using the dimensions
from the output, screwing up the DPI.
This change works around this problem by ignoring the DIX and querying the real
size from the driver.
This reverts commit 76576c87b0.
which was an incorrect revert of previous ABI bumps. Those
responsible for the accidental ABI bumps in both directions
have all been sacked.
This allows xf86-input-mouse to build again, for example.
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.
Use only %di to name the PCI register to read/write, rather than %edi.
DOS is only expecting the base PCI config space anyway, and the BIOS
might be using the high bits of %edi.
Yes, this is a 486+ instruction and thus not strictly legal in vm86
mode, but enough BIOSes use it (looking at you VIA) that we might as
well implement it.
In the single output enabled case we never enter the loop and test
never gets set and so we fail to match a good mode.
This was causing my 2560x1600 to end up at 2048x1536.
The problem happens if Monitor/Card combo doesn't provide EDID info,
and the XFree86-VidModeExtension extension is used.
Signed-off-by: Peter Hutterer <peter@cs.unisa.edu.au>
Recording damage from other operations (e.g. creating a client damage record)
may confuse the migration code resulting in corruption.
Option "EXAOptimizeMigration" appears safe now, so enable it by default. Also
remove it from the manpage, as it should only be necessary on request in the
course of bug report diagnostics anymore.