- Sep 24, 2011
-
-
Jeremy Huddleston Sequoia authored
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
-
- Sep 21, 2011
-
-
These symbols were not renamed when they were added to libfb: # nm -D libwfb.so | grep ' fb' 0000000000028d00 T fbTrapezoids 0000000000028d60 T fbTriangles This causes corruption and/or crashes on wfb-ful drivers like nvidia: Program received signal SIGABRT, Aborted. 0x00007fd67f3a0405 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. in ../nptl/sysdeps/unix/sysv/linux/raise.c (gdb) bt #0 0x00007fd67f3a0405 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007fd67f3a3680 in *__GI_abort () at abort.c:92 #2 0x00007fd67f3995b1 in *__GI___assert_fail (assertion=0x7fd679ecb804 "key->initialized", file=<optimized out>, line=116, function=0x7fd679ecbbc0 "dixGetPrivateAddr") at assert.c:81 #3 0x00007fd679ec55b6 in ?? () from /usr/lib/xorg/modules/libfb.so #4 0x00007fd679eca9ef in ?? () from /usr/lib/xorg/modules/libfb.so #5 0x00007fd679ecae20 in fbTriangles () from /usr/lib/xorg/modules/libfb.so #6 0x00007fd67a58fc55 in ?? () from /usr/lib/xorg/modules/drivers/nvidia_drv.so #7 0x00000000004f38d1 in ?? () #8 0x0000000000437ae9 in ?? () #9 0x0000000000426eaa in ?? () #10 0x00007fd67f38cead in __libc_start_main (main=<optimized out>, argc=<optimized out>, ubp_av=<optimized out>, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff99860d78) at libc-start.c:228 #11 0x000000000042719d in _start () Signed-off-by: Aaron Plattner <aplattner@nvidia.com> Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com> Signed-off-by: Keith Packard <keithp@keithp.com> (cherry picked from commit 03d03299)
-
The video driver ABI was bumped to 11.0 in commit 0de7cec9 because of a change to the size of ATOM in commit 51f353d0. This also affects extension modules, so the extension ABI version should have been bumped too. Signed-off-by: Aaron Plattner <aplattner@nvidia.com> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Keith Packard <keithp@keithp.com>
-
- Aug 26, 2011
-
-
Keith Packard authored
Signed-off-by: Keith Packard <keithp@keithp.com>
-
- Aug 15, 2011
-
-
The memcpy fast path implicitly assumes that the copy walks left-to-right. That's not something memcpy guarantees, and newer glibc on some processors will indeed break that assumption. Since we walk a line at a time, check the source and destination against the width of the blit to determine whether we can be sloppy enough to allow memcpy. (Having done this, we can remove the check for !reverse as well.) On an Intel Core i7-2630QM with an NVIDIA GeForce GTX 460M running in NoAccel, the broken code and various fixes for -copywinwin{10,100,500} gives (edited to fit in 80 columns): 1: Disable the fastpath entirely 2: Replace memcpy with memmove 3: This fix 4: The code before this fix 1 2 3 4 Operation ------ --------------- --------------- --------------- ------------ 258000 269000 ( 1.04) 544000 ( 2.11) 552000 ( 2.14) Copy 10x10 21300 23000 ( 1.08) 43700 ( 2.05) 47100 ( 2.21) Copy 100x100 960 962 ( 1.00) 1990 ( 2.09) 1990 ( 2.07) Copy 500x500 So it's a modest performance hit, but correctness demands it, and it's probably worth keeping the 2x speedup from having the fast path in the first place. Signed-off-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Keith Packard <keithp@keithp.com>
-
This fixes a regression introduced by: 633b81e8 http://xquartz.macosforge.org/trac/ticket/498 Signed-off-by: Pelle Johansson <pelle@morth.org> Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
-
- Aug 10, 2011
-
-
Otherwise sys_pitch will be stale when a system memory copy is allocated. Fixes https://bugs.freedesktop.org/show_bug.cgi?id=38322 and a crash when unlocking the screen with xscreensaver, reported by Janne Huttunen. Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Tested-by: Janne Huttunen <jahuttun@gmail.com> Tested-by: Jan Kriho <Erbureth@gmail.com> Signed-off-by: Keith Packard <keithp@keithp.com>
-
- Aug 09, 2011
-
-
Fixes assertion failure when calling dixSetPrivate Debian bug#632549 <http://bugs.debian.org/632549 > Reported-and-tested-by: Mohammed Sameer <msameer@foolab.org> Signed-off-by: Julien Cristau <jcristau@debian.org> Reviewed-by: Daniel Stone <daniel@fooishbar.org> Signed-off-by: Keith Packard <keithp@keithp.com>
-
- Aug 04, 2011
-
-
Keith Packard authored
At the close of the 1.11 non-critical fixes window. Signed-off-by: Keith Packard <keithp@keithp.com>
-
The composite extension spec says that window background painting should be inhibited when the subwindow redirection mode is set to manual. This eliminates the ugly flashing effect when compiz unredirects a fullscreen window. Signed-off-by: Ville Syrjälä <ville.syrjala@nokia.com> Reviewed-by: Owen Taylor <otaylor@fishsoup.net> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
-
This reverts commit db884060. It was an optimization for the resize case, but 193ecc8b made it so that no backfilling takes place on resize if left in. Signed-off-by: Pierre-Loup A. Griffais <pgriffais@nvidia.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Conflicts: composite/compalloc.c Signed-off-by: Keith Packard <keithp@keithp.com>
-
- Jul 31, 2011
-
-
Signed-off-by: Julien Cristau <jcristau@debian.org> Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
-
Jeremy Huddleston Sequoia authored
We added the FatalError in 5d1d9d9a but it caused a regression http://xquartz.macosforge.org/trac/ticket/482 Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
-
Jeremy Huddleston Sequoia authored
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
-
- Jul 29, 2011
-
-
RRPostPendingProperties tries to compare the pending and current property values to decide whether they're actually changing. However, it does this using a memcmp that passes in pending_value->size as the number of bytes. This is actually the number of elements, where each element is (pending_value->format / 8) bytes long. This causes the pending value to not be propagated if the first pending_value->size bytes are the same and only the end of it is changing. Fix this by computing the total number of bytes to compare in the memcmp. Signed-off-by: Aaron Plattner <aplattner@nvidia.com> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
-
Keith Packard authored
-
- Jul 26, 2011
-
-
Peter Hutterer authored
Instead of just closing the log when everything is done, put one more message in stating that we're actually terminating. Users or scripts that look at the Xorg.log will then know that a) the server has terminated properly and b) why the server terminated (to some degree, given that most real-world errors will be caused by AbortServer()). Acked-by: Gaetan Nadon <memsize@videotron.ca> Reviewed-by: Daniel Stone <daniel@fooishbar.org> Tested-by: Jeremy Huddleston <jeremyhu@apple.com> Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com> Tested-by: Jon TURNEY <jon.turney@dronecode.org.uk> Reviewed-by: Jon TURNEY <jon.turney@dronecode.org.uk> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
If config/udev was enabled, this would default to base, which means that after regen the devices would get the wrong rules, and hilarity would ensue. It's probably safe to default to evdev unconditionally on Linux by now. Reported-by: Bastian Blank <waldi@debian.org> Signed-off-by: Julien Cristau <jcristau@debian.org> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
For hotplugged devices, xf86AllocateInput does that for us but the xorg.conf path is different. Since not all drivers reset the fd during PreInit but may still call close(pInfo->fd) in all cases, this can terminate the logging early. Reproducible: add a wacom driver InputDevice section with no Option Device. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Daniel Stone <daniel@fooishbar.org>
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Daniel Stone <daniel@fooishbar.org>
-
Peter Hutterer authored
xf86ConfigLayout.inputs contains the information from the xorg.conf file. Passing this into xf86NewInputDevice means the device will get cleaned up on exit and the pointers in xf86ConfigLayout.inputs are left dangling. In the second server generation, this results in a server crash. Also, rename pDev to pInfo. pDev is pretty much reserved for DeviceIntPtr types. Reproducible: AutoAddDevices off and xorg.conf input sections, trigger server regeneration. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Daniel Stone <daniel@fooishbar.org>
-
Peter Hutterer authored
Devices that succeeded during PreInit and DEVICE_INIT but failed in DEVICE_ON would be deleted through xf86DeleteInput but not removed from the list of input devices (and not turned off). The result was a double free on server shutdown. Fix this by calling RemoveDevice if EnableDevice fails. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Daniel Stone <daniel@fooishbar.org>
-
The nature of hotplug is that a device we enumerated might already be gone by the time we look at it, so don't assume otherwise. Signed-off-by: Lennart Poettering <lennart@poettering.net> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Don't enumerate/monitor all devices of the system (since that can be quite a few), but limit our search to devices from the "input" subsystem, as well as the "tty" subsystem (to cover Wacom tablets). This should make X start up a bit faster and reduce the number of unnecessary wake-ups of the X server. Signed-off-by: Lennart Poettering <lennart@poettering.net> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
udev gives no guarantee that before each "changed" event for a device there's an "add" event, or that before each "remove" is an "add", or that before each "add" there was no "add" already and so on. Users can trigger these events at any time with "udevadm trigger", and netlink is a lossy transport, hence the events can come in unexpected ordering. With other words: regardless which event is generated, the X server must not choke on it and make the best of it, hence make sure that if we get an "add" event for an existing device we don't add the device a second time. Signed-off-by: Lennart Poettering <lennart@poettering.net> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Jon Turney authored
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk> Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
-
- Jul 20, 2011
-
-
Jeremy Huddleston Sequoia authored
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
-
Jeremy Huddleston Sequoia authored
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
-
Jeremy Huddleston Sequoia authored
Also cleaned up the wording for fullscreen_menu. Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
-
Jeremy Huddleston Sequoia authored
This preference allows users to override the related option in Mac OS X's Mouse/Trackpad preferences. This effectively lets the user determine which "context" all of X11 fits into for context-based scrolling until such API exists within X11 itself to pass along to X11 clients. This is applicable to Mav OS X 10.7+ Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
-
This occurred to me in hindsight after the last commit. If the original developer had done this, we would have noticed the problem sooner. (cherry picked from commit aa0a5799)
-
xp_destroy_surface was called with a surface id of 0, due to some premature cleanup that set it to 0. This means the surfaces weren't being destroyed until the window was. The code that did that was: pDRIDrawablePriv->sid = 0; In long running applications this leak may or may not have been harmful. With the old libGL the surfaces weren't destroyed until the context was destroyed or a new context created. In the new libGL they are reference counted, and released much sooner, so we ran into a resource leak more noticeably with some tests. Make the Apple DRI code dispatch events to the client(s) for destroyed surfaces, when a resource is destroyed. This seems to work in my tests, however this clearly wasn't working for a while, so bugs may result in the future if it enables some new (unexpected) side effects. Also add a few helpful comments to aid in understanding the code in the future. Tested with the test suite, Pymol, and various Mesa demos. (cherry picked from commit bede83eb)
-
Jeremy Huddleston Sequoia authored
Also add some comments that weren't merged in from server-1.4-apple's 99babae1 Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
-
- Jul 19, 2011
-
-
Jeremy Huddleston Sequoia authored
This way we'll print an error and still mostly work rather than crashing if someone installs XQuartz.app incorrectly or tries running the server within the build system rather than the installed system. Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
-
- Jul 15, 2011
-
-
Jeremy Huddleston Sequoia authored
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
-
Bugfix for broken xkbcomp: if we encounter an XFree86Private action with Any+AnyOfOrNone(All), then we skip the interp as broken. Versions of xkbcomp below 1.2.2 had a bug where they would interpret a symbol that couldn't be found in an interpret as Any. So, an XF86LogWindowTree+AnyOfOrNone(All) interp that triggered the PrWins action would make every key without an action trigger PrWins if libX11 didn't yet know about the XF86LogWindowTree keysym. None too useful. We only do this for XFree86 actions, as the current XKB dataset relies on Any+AnyOfOrNone(All) -> SetMods for Ctrl in particular. See xkbcomp commits 2a473b906943ffd807ad81960c47530ee7ae9a60 and 3caab5aa37decb7b5dc1642a0452efc3e1f5100e for more details. Signed-off-by: Daniel Stone <daniel@fooishbar.org> Acked-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
The previous patch accidentally introduced a hard dependency on Composite. Sorry, OS X. Signed-off-by: Daniel Stone <daniel@fooishbar.org> Reported-by: Jeremy Huddleston <jeremyhu@apple.com> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Jul 13, 2011
-
-
Keith Packard authored
-
Reviewed-by: Cyril Brulebois <kibi@debian.org> Signed-off-by: Gaetan Nadon <memsize@videotron.ca> Signed-off-by: Keith Packard <keithp@keithp.com>
-
- Jul 07, 2011
-
-
Reviewed-by: Cyril Brulebois <kibi@debian.org> Signed-off-by: Gaetan Nadon <memsize@videotron.ca> Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
-