<http://bugs.opensolaris.org/view_bug.do?bug_id=6685465>
This bug is caused by Xephyr not handling the RGB byte order correctly
of the server where Xephyr is displaying on. The previous code just
assumed that the order was RGB and did not take into account that
Xservers may use different order (such as BGR).
The fix is to add a function to calculate the byte order and bits
to shift based on the visual mask and the visual bits_per_rgb (which
is usually 8, but could be server dependent). Since the shifts won't
change once the display connection has been made, I can cache these
values so that Xephyr doesn't have to keep recalculating them everytime
it tries to translate the Xephyr colormap entries for Xephyr clients to
the actual server colormap entries (i.e. calling the function
hostx_set_cmap_entry() repeatedly for every colormap entry).
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.
This code hasn't been updated with anything even resembling what anyone is
shipping in nearly thirty months. It hasn't built out of the box since
7.1. Most of its features over AIGLX are accomplished with DRI2 and
friends.
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.
Modelled after the xfree86 code. Call miDCInitialize to init the SW rendering
engine, then take the pointers, store it in a xnest-local variable, and put
the xnest-specific sprite funcs in place. In the xnest sprite funcs, call
through to the mi sprite funcs after doing xnest-specific stuff.
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>
With the MD/SD device hierarchy we need control over the generation of the
motion history as well as the conversion later before posting it to the
client. So let's not let the drivers change it.
No x.org driver currently uses it anyway, linuxwacom doesn't either so dumping
it seems safe enough.
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.