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.
GNU/kFreeBSD defines __FreeBSD_kernel__, but not __FreeBSD__.
Unify preprocessor conditionals between variable declaration and use.
Debian bug #482550.
During GetPointerEvents (and others), we need to access the last coordinates
posted for this device from the driver (not as posted to the client!). Lastx/y
is ok if we only have two axes, but with more complex devices we also need to
transition between all other axes.
ABI break, recompile your input drivers.
This copies over the files generated from mesa/src/mesa/glapi. There's
a corresponding mesa commit that makes it easy to generate the glapi files
straight into the xserver tree when the XML definitions change.
The only few files that are copied from mesa but aren't generated are
glapi.[ch] and glthread.[ch]. Everything in there is technically DRI
driver API and the whole setup is still a bit fragile, but it's not a new
problem.
The --with-mesa-source configure option is still around since other
parts of the server (XGL and DMX - grep for MESA_SOURCE) need that,
but for common case of building with GLX and AIGLX support, that
option is no longer needed.
Conflicts:
Xext/xprint.c (removed in master)
config/hal.c
dix/main.c
hw/kdrive/ati/ati_cursor.c (removed in master)
hw/kdrive/i810/i810_cursor.c (removed in master)
hw/xprint/ddxInit.c (removed in master)
xkb/ddxLoad.c
If the monitor isn't reduced-blanking (either through EDID logic, or
config file setting), then remove RB modes from the default pool. Any
RB modes from the driver and config file pools will stick around though;
you asked for them, you got them.
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 first guess used to be "is the preferred mode for one output the
preferred mode on all outputs". Instead, do "find the largest mode that's
preferred for at least one output and available on all outputs".
Old logic was just the first one that happened to have an associated
CRTC. The new logic tries to find one that's definitely connected, has
probed modes, and has the largest candidate mode.
It was removed and simplified some conditionals. We don't need test for
pDev->isMaster inside xf86CursorSetCursor() because only MD enters there.
In the last chunk, ScreenPriv fields were being assigned without need, so
that code was wrapped inside the conditional to avoid it.
I also tried to make the identation more sane in some parts that I touched.
Signed-off-by: Tiago Vignatti <vignatti@c3sl.ufpr.br>
Minor modification, part of the original patch led to cursors not being
updated properly when controlled through XTest.
Signed-off-by: Peter Hutterer <peter@cs.unisa.edu.au>
The only function that cat set SWCursor before xf86DeviceCursorInitialize()
is xf86InitCursor() when VCP and is created.
Signed-off-by: Tiago Vignatti <vignatti@c3sl.ufpr.br>
Signed-off-by: Peter Hutterer <peter@cs.unisa.edu.au>
Missing parameter caused event processing to go nuts when checking valuators.
X.Org Bug 15936 <http://bugs.freedesktop.org/show_bug.cgi?id=15936>
Signed-off-by: Peter Hutterer <peter@cs.unisa.edu.au>
Since glyphs are stored in pixmaps now, they can make their way into VRAM,
which invalidates a bunch of fast-path assumptions in the XAA code. Thus
you end up doing color-expands or WriteBitmap from la-la land and your
aliased glyphs go all funny.
Since XAA isn't ever growing the ability to do sane glyph accel, just force
glyph pixmaps into host memory by catching them at CreatePixmap time.
We need a manual call to SetCursor when we switch from SW to HW rendering and
the other way round. This way we display the new cursor after removing the old
one.
In addition, we only update the internal state for the VCP's sprite. This way,
when we switch back to HW rendering the state is up-to-date and wasn't
overwritten with the other sprite's state.
The second part is a hack. It would be better to keep a state for each sprite,
but then again we don't have hardware that can render multiple cursors so we
might as well do with the hack.
Switches back to HW cursors when sprites other than the VCP are removed.
The current state requires the cursor to change shape once before it updates
to SW / HW rendering (whatever is appropriate), e.g. by moving into a
different window. Until this is done, the cursor is invisible.
This patch only creates a Files section if required, so if no entries are
added, an empty Files section will not be created.
Signed-off-by: Peter Hutterer <peter@cs.unisa.edu.au>
LeaveVT/EnterVT cycles will free/realloc shadow frame buffers. Because of
this, the presense/absence of that data is insufficient to know whether
the screen function wrappers are necessary. Instead, the 'transform_in_use'
flag should be used.
This patch also adds 'xf86RotateFreeShadow' for drivers to use at LeaveVT
time to free the rotation data; it will be reallocated on EnterVT.
In DeleteInputDeviceRequest, leave the conf_idev (which is shared with
xf86ConfigLayout.input) alone for devices that were specified in the
ServerLayout section of the config file. This way, in the next server
generation we are left with what was the original config and can thus re-init
the devices.
This is an addon to 6d22a9615a, an attempt to
fix Bug 14418.
X.Org Bug 15645 <https://bugs.freedesktop.org/show_bug.cgi?id=15645>
X.Org Bug 14418 <https://bugs.freedesktop.org/show_bug.cgi?id=15645>
The previous check works in the master-branch, but doesn't work with MPX. We
actually copy the SD's information into the MDs public.devicePrivate, so we
need to explicitly check whether a device is a MD before freeing the module.
Use __libmansuffix__ instead of __oslibmansuffix__ which isn't getting
replaced, and rewrap some text to get __xservername__ replaced in the
description of Option "Accel" (cpp doesn't like the preceding quote).
This extension provided bug-compatibility with pre-X11R6, but has been
stubbed out in our server since 2006 to return BadRequest when you actually
asked for it.
The DDX (xfree86 anyway) maintains its own device list in addition to the one
in the DIX. CloseDevice will only remove it from the DIX, not the DDX. If the
server then restarts (last client disconnects), the DDX devices are still
there, will be re-initialised, then the hal devices come in and are added too.
This repeats until we run out of device ids.
This also requires us to strdup() the default pointer/keyboard in
checkCoreInputDevices.
X.Org Bug 14418 <http://bugs.freedesktop.org/show_bug.cgi?id=14418>
Some pointer devices send key events [1], blindly getting the paired device
crashes the server. So let's check if the device is a pointer before we try to
get the paired device.
[1] The MS Wireless Optical Desktop 2000's multimedia keys are sent through
the pointer device, not through the keyboard device.
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.
Get rid of glcontextmodes.[ch] from build, rename __GlcontextModes to
__GLXcontext. Drop all #includes of glcontextmodes.h and glcore.h.
Drop the DRI context modes extension.
Add protocol code to DRI2 module and load DRI2 extension by default.
Since there's no way to safely know how many blocks xf86DoEDID_DDC2 would
return, add a new xf86DoEEDID entrypoint to do that, and implement the
one in terms of the other.
The latter doesn't give you the option's value, it just tells you if
it's present in the configuration. So using Option "EXANoComposite" "false"
disabled composite acceleration.
This patch (and not setting HARDWARE_CURSOR_BIT_ORDER_MSBFIRST on big endian
platforms) fixes it for me with the radeon driver and doesn't break intel.
Correct patch this time :)
Should have done this in the first place. Since we're checking for the absence
of the get_crtc callback in the first place, we'll short circuit the later call
and disable the output, so the ugly "continue" block is unnecesary.
By adding a new output callback, ->get_crtc, xf86SetDesiredModes is able to
avoid turning off outputs & CRTCs if the current output<->CRTC mappings are the
same as the desired configuration. This helps avoid flickering displays at
startup time, which speeds things up a little and looks better.
Unless we check for vtSema before calling into the CRTC and output callbacks,
we may end up trying to access video memory that no longer exists, leading to a
crash. So if we don't have vtSema, return FALSE to the caller, indicating that
we didn't do anything.
Fixes#14444.
Actually more like in the mainline case, where the ideal mode happens to
be the very first aspect match on the first monitor. But let's not
split hairs.
The address written to 0xcf8 contains the PCI slot address to send the
config cycle to. However, we would ignore that and always send the
cycle to the device whose BIOS we were running. This breaks some
integrated graphics platforms that have explicit knowledge about the
system's host bridge, for example.
While the ScreenRec's notion of size in millimeters would get updates,
the RANDR 1.1 notion wouldn't, so your screen would appear to be square
and probably at some ludicrous DPI.
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.
i.e., don't check for the end of the list by ->name == NULL, since that
won't work now. Fix the consumers of xf86DefaultModes to use the new
explicit size as well.
In order to report accurate values to users of the RandR property interface,
it's sometimes necessary to ask the driver to update the value (for example
when backlight brightness changes without the server's knowledge, due to hotkey
events or direct sysfs banging).
This patch wires up the core server code with a new xf86CrtcFuncs callback,
get_property, to allow for this.
The new code is available under the RANDR_13_INTERFACE define, which in turn
depends on the RANDR_12_INTERFACE code.
Old heuristic was to find the first monitor that expressed a preference,
then attempt to get all other monitors to agree. This doesn't work
particularly well when the two sets of modes don't precisely intersect,
you get overlapping-but-not-identical output geometry and things go wrong.
New heuristic is:
- Exact user preference, if given
- Exact output preference, if the same for all outputs
- Best (largest) mode of modes common to all outputs:
- with the same aspect ratio as all outputs (may be NULL)
- with 4:3 aspect ratio
- Then the old heuristic to try to get something lit
Note that it is simply not doable to have a reliable initial output guess if
you insist on trying to clone all outputs together. It's far too easy to
end up with displays that simply don't have modes in common. We need to
switch to right-of placement someday, once we're not limited to CRTC size
limits and we have working multi-GPU in RANDR.
If you don't do this, then Modes "800x600" in the Display subsection will
be dutifully ignored and the driver will start at whatever resolution it
feels like.