Found by parfait 1.1 memory analyser:
Memory leak of pointer 'pAdapt' allocated with malloc((88 * num_adaptors))
at line 162 of hw/xfree86/common/xf86xvmc.c in function 'xf86XvMCScreenInit'.
'pAdapt' allocated at line 158 with malloc((88 * num_adaptors)).
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Also avoids leaving invalid pointers in structures if realloc had to
move them elsewhere to make them larger.
Found by parfait 1.1 code analyzer:
Memory leak of pointer 'newCallbacks' allocated with realloc(((char*)offman->FreeBoxesUpdateCallback), (8 * (offman->NumCallbacks + 1)))
at line 328 of hw/xfree86/common/xf86fbman.c in function 'localRegisterFreeBoxCallback'.
'newCallbacks' allocated at line 320 with realloc(((char*)offman->FreeBoxesUpdateCallback), (8 * (offman->NumCallbacks + 1))).
newCallbacks leaks when newCallbacks != NULL at line 327.
Memory leak of pointer 'newPrivates' allocated with realloc(((char*)offman->devPrivates), (8 * (offman->NumCallbacks + 1)))
at line 328 of hw/xfree86/common/xf86fbman.c in function 'localRegisterFreeBoxCallback'.
'newPrivates' allocated at line 324 with realloc(((char*)offman->devPrivates), (8 * (offman->NumCallbacks + 1))).
newPrivates leaks when newCallbacks == NULL at line 327.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reported by parfait 1.1 code analyzer:
Error: Null pointer dereference (CWE 476)
Read from null pointer 'p'
at line 746 of hw/xfree86/common/xf86Option.c in function 'xf86TokenToOptName'.
Function 'xf86TokenToOptinfo' may return constant 'NULL' at line 721, called at line 745.
Null pointer introduced at line 721 in function 'xf86TokenToOptinfo'.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Our in-house parfait 1.1 code analysis tool complained that every exit
path from xf86ValidateModes() in hw/xfree86/common/xf86Mode.c leaks the
storeClockRanges allocation made at line 1501 with XNFalloc.
Investigating, it seems that this code to copy the clock range list to
the clockRanges list in the screen pointer is just plain insane, and
according to git, has been since we first imported it from XFree86.
We start at line 1495 by walking the linked list from scrp->clockRanges
until we find the end. But that was just a diversion, since we've found
the end and immediately forgotten it, and thus at 1499 we know that
storeClockRanges is NULL, but that's not a problem since we're going to
immediately overwrite that value as the first thing in the loop.
So we move on through this loop at 1499, which takes us through the
linked list from the clockRanges variable, and for every entry in
that list allocates a new structure and copies cp to it. If we've
not filled in the screen's clockRanges pointer yet, we set it to
the first storeClockRanges we copied from cp. Otherwise, as best
I can tell, we just drop it into memory and let it leak away, as
parfait warned.
And then we hit the loop action, which if we haven't hit the end of
the cp list, advances cp to the next item in the list, and then just
for the fun of it, also sets storeClockRanges to the ->next pointer it
has just copied from cp as well, even though it's going to overwrite
it as the very first instruction in the loop body.
v2: rewritten using nt_list_* macros from Xorg's list.h header
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
The changes to miPointerSetPosition interface from int->double breaks
the SIS driver build, so time to bump this.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
DGA only handles master devices but it does intercept slave device events as
well (since the event handlers are per event type, not per device).
The DGA code must thus call into UpdateDeviceState to reset the button/key
state on the slave device before it discards the remainder of the event.
Test case:
- Passive GrabModeSync on VCP
- Press button
- Enable DGA after ButtonPress
- AllowEvents(SyncPointer)
- Release button
The button release is handled by DGAProcessPointerEvent but the device state
is never updated, so the slave ends up with the button permanently down.
And since the master's button state is the union of the slave states, the
master has the button permanently down.
X.Org Bug 59100 <http://bugs.freedesktop.org/show_bug.cgi?id=59100>
Reported-by: Steven Elliott <selliott4@austin.rr.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reported-by: Steven Elliott <selliott4@austin.rr.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Instead of requiring every mode set to complete successfully, start up
as long as at least one CRTC is working. This avoids failures when one
or more CRTCs can't start due to mode setting conflicts.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
This commit regresses dri1 since it moves the drmSetServerInfo from being
called at module load time to extension init time. However DRIScreenInit
relies on this being called before it gets control.
This patches moves the call into DRIScreenInit and seems to work here.
Signed-off-by: Dave Airlie <airlied@redhat.com>
The formatter confused address operators preceded by casts with
bitwise-and expressions, placing spaces on either side of both.
That syntax isn't used by ordinary address operators, however,
so fix them for consistency.
Signed-off-by: Yaakov Selkowitz <yselkowitz@users.sourceforge.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Following commit 37d956e3ac
Author: Keith Packard <keithp@keithp.com>
Date: Mon Sep 10 11:14:20 2012 +1000
xf86: fix compat output selection for no output GPUs
headless servers can no longer startup as we no longer select a compat
output for the fake framebuffer.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56343
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
For non-PCI video devices, such as those found on many ARM embedded
systems, the X server currently requires the BusID option to specify the
full path to the DRM device's sysfs node in order to properly match it
against the probed platform devices.
In order to allow X to start up properly if either the BusID option was
omitted or no configuration is present at all, the first video device is
used by default.
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
K_OFF is a slightly broken interface, since if some other process
(cough, systemd) sets the console state to K_UNICODE then it undoes
K_OFF, and now Alt-F2 will switch terminals instead of summoning the
Gnome "run command" dialog.
KDSKBMUTE separates the "don't enqueue events" logic from the keymap, so
doesn't have this problem. Try it first, then continue falling back to
older methods.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=859485
Tested-by: Josh Boyer <jwboyer@redhat.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
These functions are already declared in <X11/fonts/fontproto.h>.
Redeclaring them just for _X_EXPORT causes tons of warnings throughout
xserver, but they need to be declared somewhere to be picked up by
sdksyms.sh. Doing so in a private header limits the warnings to
sdksyms.c; fixing those as well would require changes to fontsproto.
Signed-off-by: Yaakov Selkowitz <yselkowitz@users.sourceforge.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Recent Linux kernels reworked the linux/input.h header file, which is
now part of the "user-space API". The include guard therefore has an
additional additional _UAPI prefix.
Instead of adding another case to the #ifdef, drop any include guard
checks and instead always undefine the BUS_* definitions on Linux.
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Fix compilation of Xorg DDX without XF86VIDMODE since 6e74fdda, by putting
xf86vmode.c back under the XF86VIDMODE automake conditional it was accidentally
taken out of.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Tested-by: Yaakov Selkowitz <yselkowitz@users.sourceforge.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
This call is required for external drivers (specifically NVIDIA) that do
not share the xfree86 infrastructure to update the desktop dimensions.
Without it, the driver would update the ScreenRecs but not update the total
dimensions the input code relies on for transformation.
This call is a thin wrapper around the already-existing internal call and
should be backported to all stable series servers, with the minor ABI bump.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
CC: Andy Ritger <aritger@nvidia.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
I noticed that the build-in int10 driver always reports
"Unable to retrieve all of segment 0x0C0000."
even though the entire BIOS data is retrieved with success.
The associated code is in hw/xfree86/int10/generic.c, in the function
xf86ExtendedInitInt10():
if (pci_device_read_rom(pInt->dev, vbiosMem) < V_BIOS_SIZE) {
xf86DrvMsg(screen, X_WARNING,
"Unable to retrieve all of segment 0x0C0000.\n");
}
The function pci_device_read_rom() is from libpciaccess; its return
value is not a size but an error status code: 0 means success.
If pci_device_read_rom() returns 0 for success, the warning is generated.
The proposed patch corrects the evaluation of the return value of
pci_device_read_rom() and of the supplied BIOS size.
Debian bug#686153
Signed-off-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Commit 09e4b78f missed a case.
Signed-off-by: Jason Gerecke <killertofu@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Remove any reference to mibstore.h and miInitializeBackingStore() from
the documentation.
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Remove more backing store leftovers.
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This is a really awkward interface, since we're calling it well before
the driver knows what device it's going to drive. Drivers with both KMS
and UMS support therefore don't know whether to say they need I/O port
access or not, and have to assume they do.
With this change we now call it only to query whether port access might
be needed; we don't use that to determine whether to call a driver's
probe function or not, instead we call them unconditionally. If the
driver doesn't check whether port access was enabled, they might crash
ungracefully. To accomodate this, we move xorgHWAccess to be explicitly
intentionally exported (sigh xf86Priv.h) so that drivers can check that
before they attempt port access.
v2: Move initial xf86EnableIO() nearer the logic that determines whether
to call it, suggested by Simon Farnsworth.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Signed-off-by: Adam Jackson <ajax@redhat.com>
We load the driver list, then enable I/O, then call driver probe based
on whether I/O enable succeeded. That's bad, because the loaded
security policy might forbid port access. We happen to treat that as
fatal for some reason, which means even drivers that don't need I/O
access (like kms and fbdev) don't get the chance to run. Facepalm.
How about we just make that non-fatal instead, that sounds like a much
better plan.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Pull platform methods into their own sections for legibility, and
rewrite the ifdefs to be more concise.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Signed-off-by: Adam Jackson <ajax@redhat.com>
If we are not seat 0 the following apply:
don't probe any bus other than platform
don't probe any drivers other than platform
assume the first platform device we match on the bus is the primary GPU.
This just adds checks in the correct places to ensure this, and
with this X can now start on a secondary seat for an output device.
v2: fix Seat0 macros
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This solves a race if we are trying to dynamically power off
secondary GPUs. Its not the greatest fix ever but it probably
as good as we can do for now.
The GPU probing causes the devices to be powered up, then when
we scan the PCI bus we get the correct information from the kernel,
rather than a bunch of 0xff due to the device being powered off.
drop gratuitous '&'.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
After we share the pixmap, the backing storage may have changed,
and we need to invalidate and buffers pointing at it.
This fixes GL compositors and prime windows lacking contents initially.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Otherwise we can't do fast user switch properly for multiple GPUs.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is set by pre_init not screen init, so if we free it here
and then recycle the server, we lose all the providers.
I think we need to wrap FreeScreen here to do this properly,
will investigate for 1.14 most likely, safer to just leak this
on server exit for now.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Commit 9d457f9c55 added an array of
DevPrivateSetRec structures in the middle of the ScreenRec, which throws off
extension modules trying to call things like pScreen->DestroyPixmap.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
The core RandR screen cleanup now involves cleaning up any GPU screen
associations, and those call down into DDX to clean up the driver. If
the pointers from the xf86 structures back to the core randr
structures are set to NULL at that point, bad things happen.
This patch "knows" that the core RandR close screen is underneath the
xf86 randr close screen function, and so makes sure it gets called
first.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
These are two minor changes, one to reset the pointer to NULL,
after freeing the pixmaps, one to make sure we use the right API for
the master pixmap, though I doubt it'll ever really matter.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
When the drawable disappears we need to free the prime master/slave combos.
This fixes a leak after a prime app is run.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
The indenter seems to have gotten confused by initializing arrays of
structs with the struct defined inline - for predefined structs it did
a better job, so match that.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Alan Coopersmith
Keith Packard
Peter Hutterer
Dave Airlie
Dave Airlie
Yaakov Selkowitz
Chris Wilson
Thierry Reding
Daniel Stone
Adam Jackson
Jon TURNEY
Stephan Schreiber
Jason Gerecke
Daniel Martin
Aaron Plattner