The multi-crtc cursor code in hw/xfree86/modes holds a reference to the
current cursor. This reference must be correctly ref counted so the cursor
is not freed out from underneath this code.
This is where they should have been in the first place. All the rest of
the code in the server defines such things in the source files, not the
headers.
A bunch of CFLAGS had gone missing, so the build failed with errors like:
../../../../../hw/xfree86/os-support/linux/lnx_ev56.c:7:19: error: input.h: No such file or directory
../../../../../hw/xfree86/os-support/linux/lnx_ev56.c:8:24: error: scrnintstr.h: No such file or directory
As a result, we can remove the quirks that existed to flip the bits back around
for us. This is not confirmed in all cases due to lack of bugs containing EDID
blocks associated with the quirks, but is likely true.
I exported the evdev driver to Xephyr server. I'm running it using something
like:
$ ./hw/kdrive/ephyr/Xephyr :1 -mouse evdev,,device=/dev/input/event4 -keybd \
evdev,,device=/dev/input/event1,xkbmodel=abnt2,xkblayout=br
It also closes /#5668.
and the Xephyr virtual mouse keeps alive. With this patch the semantic changes
turning '-pointer' && 'Xephyr virtual mouse' always false.
Now we can open a device pointer and pass its options in Xephyr's command line
without having other pointer unused.
The outport is most likely unnecessary on any currently used hardware,
the byte copy is necessary from what I know on IA64 and friends so leave it.
Add a new API entry point which lets a driver select the old behaviour if
such a needs is ever found.
This gives me ~20% speed up on startup on 945 hardware.
If NoAutoAddDevices is given as a server flag, then no devices will be added
from HAL events at all. If NoAutoEnableDevices is given, then the devices will
be added (and the DevicePresenceNotify sent), but not enabled, thus leaving
policy up to the client.
Make sure the font path is always 'built-ins' when we use built-in fonts,
rather than having it as a fixed path for a while, then clobbering it
halfway through startup.
Set the new randr crtc of the output before the output change notification is
delivered to the clients.
Remove RROutputSetCrtc as it is not really necessary. All we have to do is set
the output's crtc on RRCrtcNotify
When the PreferredMode option is selected in the config file, remove the
M_T_PREFERRED bit from all other preferred modes to force the config file
mode to be selected.
Code that disabled mode detection on disabled outputs would confuse
applications by listing said outputs as connected but without any modes.
This makes the disabled state in the config file affect only the initial
configuration and not subsequent modifications by RandR.
The DDX code was ignoring pending properties for computing when mode setting
was required. This meant that configurations differing only in property
values would not cause the mode to be set.
If your loader is as bad as elfloader, then it makes sense for the
server to have some stubs for you to assign to / break on. However it
is no longer 1996.
I made a mistake in some new code using MakeAtom, passing the size of the
string instead of the length of the string. Figuring there might be other
such mistakes, I reviewed the server code and found four bugs of the same
form.
The previous scheme didn't work when the client didn't create the core drawable,
e.g. the root or composite overlay window. Use refcounting via special client
resources to fix that.
Print debug messages only when the appropriate debug bit is set in the
8086 state vector, so you can focus in on the call you're actually
interested in.
This is to avoid issues with redirected windows which are located partly or
fully outside of a screen edge, resulting in unusual cliprects which the 3D
drivers generally can't handle. The symptoms in such cases would be incorrect
rendering or even crashes or hangs.
at server startup, and not against the virtual X/Y parameters
as they can change.
This fixes an issue when canGrow is TRUE and modes get dropped
when using the virtual X/Y parameters.
Xprt links libfb, which now uses pixman. Update configure.ac to
require module $PIXMAN for XPRINT.
Also, use $(top_builddir) to reference libfb.la and other local
libraries, rather than using the relative reference ../..
Major stylistic cleanups, greatly expanded cross-reference ("SEE ALSO")
section and some typo fixes.
This patch by Branden Robinson. Forward-ported by Fabio M. Di Nitto.
When the root window changed size, xf86XVFillKeyHelper would not revalidate
the GC, leaving the clip at the old size causing lossage (and possibly
memory corruption if the screen and frame buffer shrank).
Fixed by just using a scratch GC; saving memory, eliminating bugs and
shrinking the code.
To be used by AIGLX for GLX_EXT_texture_from_pixmap without several data copies.
The texOffsetStart hook must make sure that the given pixmap is accessible by
the GPU for texturing and return an 'offset' that can be used by the 3D
driver for that purpose.
The texOffsetFinish hook is called when the pixmap is no longer being used for
texturing.
DRI uses a non-screen block/wakeup handler which will be executed after the
screen block handler finishes. To ensure that the rotation block handler is
executed under the DRI lock, dynamically wrap the screen block handler for
rotation.
Leaving devices enabled during server startup can cause problems during the
initial mode setting in the server, especially when they are used for
different purposes by the X server than by the BIOS. Disabling all of them
before any mode setting is attempted provides a stable base upon which the
remaining mode setting operations can be built.
The code in hw/xfree86/os-support/bus/sparcPci.c:simbaCheckBus()
is trying to mimmick VGA routing by disabling I/O space responses
behind the Simba PCI-PCI controller.
Unfortunately, doing this also happens to disable access to the
IDE controller I/O space registers, thus crashing the system. The
granularity of the I/O disabling in the Simba controller is not
fine enough to disable VGA without also disabling the IDE controller
registers.
When the modules section is parsed, if a module is set to be loaded by
default, this will be logged. If it is redundantly specified in xorg.conf,
this will also be noted. None of this logging will happen if the xorg.conf
lacks a modules section.
This provides a new option, UseDefaultFontPath. This option is enabled by
default, and causes the X server to always append the default font path
(defined at compile time) to the font path for the server. This will allow
people to specify additional font paths if they want without breaking
their font path, thus hopefully avoiding ye olde "fixed front" problem.
Because this option is a ServerFlag option, the ServerFlags need to be
processed before the files section of the config file, so swap the order
that they are processed.
Provide default modules that may be overrided easily. Previously the
server would load a set of default modules, but only if none were
specified in the xorg.conf, or if you didn't have a xorg.conf at all. This
patch provides a default set and you can add only the "Load" instructions
to xorg.conf that you want without losing the defaults. Similarly, if you
don't want to load a module that's loaded by default, you can add "Disable
modulename" to your xorg.conf (see man xorg.conf in this release for
details). This allows for a minimal "Modules" section, where the user only
need specify what they want to be different. See bug #10541 for more.
The list of default modules is taken from the set loaded by default when
there was a xorg.conf containing no "Modules" section.
A potential problem for some users is that some users disable a module,
most notably DRI, by commenting out the "Load" line in their xorg.conf.
This needs to be changed to an uncommented "Disable" line, as DRI is
loaded by default.
Formerly we sized an array with a compile time constant, then initialized
its size to the same constant, but the Linux PCI init code would increase
that "constant". So if you happened to have more than 128 PCI devices,
you'd happily scribble into whatever variables happened to be in .bss
after that array.
Only really fixed for Linux atm. Other OSes will simply (still) fail to
work on video devices above the 128th PCI device.
SourceValidate is used exclusively by the software cursor code to pull the
cursor off of the screen before using the screen as a source operand. This
eliminates the software cursor from the frame buffer while painting the
rotated image though. Disabling this function by temporarily setting the
screen function pointer to NULL causes the cursor image to be captured.
(cherry picked from commit 05e1c45ade9c558820685bfd2541617a2e8de816)
Setting a mode on an unrotated CRTC was causing all of the rotation updates
to be disabled; the loop looking for active rotation wasn't actually looking
at each crtc, it was looking at the modified crtc many times.
(cherry picked from commit 8b217dee3a6c46b13fc9571a4a9a95bc55686cdb)
I've managed to solve my own bug (#10545) by applying the following
patch to the xserver.
Please apply.
<Conspiracy mode on>
This monitor is "Vista Certified". I wonder if this is a pure coincidence...
<Conspiracy mode off>
With kind regards
Erik Andrén
(cherry picked from commit a63704f14a1d97b9a00fef6fa290e74e51b9732b)
Option "Enable" "True" will force the server to enable an output at startup
time, even if the output is not connected. This also causes the default
modes to be added for this output, allowing even sync ranges to be used to
pick out standard modes.
(cherry picked from commit a3d73ba2cb7e13a6d129cd88d6a7f7d756e2ced2)
By default, use the screen monitor section for output 0, however, a driver
can change which output gets the screen monitor by calling
xf86OutputUseScreenMonitor.
(cherry picked from commit f4a8e54caf6b9431711383a39f55a18e7fd654f4)
The entity (device) has a locking SAREA and a master file descriptor
that optionally isn't closed between server generation.
The locking SAREA contains the device hardware lock.
Each DRI screen creates an new SAREA containing the drawable lock,
drawable-and private info, the drawable SAREA.
The first screen optionally shares its drawable SAREA with the
device SAREA.
Default is to close the master descriptor between server generations,
and to share the drawable SAREA of the first screen with the device locking
SAREA. Thus we should (hopefully) have full backwards compatibility.
Mesa changes to support single-device multiple screens are pending.
This Acer monitor reports support for 75hz refresh via EDID, and yet when
that rate is delivered, the monitor does not sync and reports out of range.
Use the existing 60hz quirk for this monitor.
(cherry picked from commit 1328a288e9030a472a915077160f090d1afd4126)
By the time CloseScreen gets called, we can't call ProcessInputEvents, as
the event queue will get unhappy. So just unregister our hooks instantly,
and hope that they don't get called.
xf86SetSingleMode tries to resize all crtcs to match the selected mode. When
a CRTC has no matching mode, it now disables the CRTC (instead of crashing).
Also, poke the RandR extension when xf86SetSingleMode is done so that
appropriate events can be delivered, and so that future RandR queries return
correct information.
(cherry picked from commit dc6c4f6989f87149d8605604f4514f5cbf11de67)
/sys/devices reflects the bus topology, and we don't care that much.
Easier (and more reliable) to just look in /sys/bus/pci/devices, which
is a flat view.
When we see an evdev or vmmouse section, assume that it's a mouse, and
don't add a default mouse device. This will break users who have an
evdev keyboard section but no mouse, and want the mouse to get added
by default.
Now, fbcmap_mi.c contains the fb functions which just wrap mi functions.
Previously, these were in fbcmap.c and compiled when XFree86Server was defined.
Now, clients of fbcmap should either use fbcmap.c or fbcmap_mi.c and not worry
about setting the XFree86Server symbol.
Erasing this variable causes some outputs (SDVO on intel) to fail
to be correctly reset at server reset time.
(cherry picked from commit 56262a4ee943f328d089a8eb4aa70b9a4bd5d135)
It seems that the changes to X input exposed a problem that wasn't detected
before. The axis clipping code in GetPointerEvents() uses those limits to
constrain the pointer's coordinate range. The max was zero so the pointer
couldn't move.
Use new dmxCoreMotion2() function which enqueues motion events with
GetPointerEvents()/mieqEnqueue().
The clipAxis() code in GetPointerEvents() is causing some grief. The
limits seem to have always been (0,0) according to the original calls
to InitValuatorAxisStruct() in dmxinputinit.c.
Terrible hack for now: Call InitValuatorAxisStruct() with hard-coded max
values of 1280 (my screen width).
Keith Packard
Alex Deucher
David Nusinow
Julien Cristau
Blair Sadewitz
Jeremy C. Reed
Dave Jones
Alan Coopersmith
Samuel Thibault
Eric Anholt
Gustavo Pichorim Boiko
Tiago Vignatti
Roland "Test-tools" Bär
Dave Airlie
Arkadiusz Miskiewicz
Daniel Stone
Daniel Drake
Adam Jackson
Kristian Høgsberg
Aaron Plattner
Brice Goglin
Michel Dänzer
Keith Packard
Tiago Vignatti
Jonathan Lim
Gero Mudersbach
Peter Hutterer
Ian Romanick
Lennart Buytenhek
Zephaniah E. Hull
Clark Rawlins
Daniel Ciocea
Henry Zhao
Alan Hourihane
Matthieu Herrb
Drew Parsons
Bastian Blank
Branden Robinson
Keith Packard
Luo Jie
Matthias Drochner
Colin Harrison
Matthias Hopf
Colin Guthrie
Brian
Thomas Hellstrom
Erik Andrén
Remigiusz Marcinkiewicz
Magnus Vigerlöf
Jared D. McNeill
Stefan Huehner
Keith Packard
Alberto Mardegan