Commit 9de0e31746 changed the signature
of __GLXScreen's createDrawable method.
Update the glxWinCreateDrawable() function in XWin's GLX provider
appropriately.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Tested-by: Colin Harrison <colin.harrison@virgin.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
Recursive alpha maps (where one picture's alpha map is set to a
picture with an external alpha map) would be all fine and dandy,
except for the case where the client constructs a loop. Detecting this
case when setting the alpha map values would be difficult as any time
an alpha map is set, the server would have to check for the looping
case.
Instead, a far simpler fix is to simply disallow recursive alpha maps
in the rendering code, the Render spec is ambiguous in this area and
allows us to to ignore the recursive case.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
IsFramedWindow() is called from miPaintWindow() if the server has
been built with ROOTLESS defined, irrespective of if RootlessInit()
has ever been called, or not.
Add a check to IsFramedWindow() to check if rootlessWindowPrivateKey
has been registered (as a proxy for checking if the rootless extension
has been initialized) so we don't go on to try to use that key,
triggering an assert.
This bug exposes what appears to be a difference in opinion about
the rootless extension between XQuartz and XWin. XQuartz always
initializes the rootless extension, whereas XWin offers several modes
of operation, and the rootless extension is only used for one of them
That probably means that the all code under compile time guard for
ROOTLESS should be carefully checked that it doesn't also need to be
under a run-time guard
(I've reviewed the other ROOTLESS blocks in dix/events.c and
dix/window.c and they look ok -- keithp)
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
When doing Xinerama, we'll dispatch font ops across all backend screens.
If using a font server (such that some operations can sleep), we'll put
the client to sleep once for each screen, but only wake up once, because
we're trying to keep track of the sleep count in _each_ screen's
closure.
Instead, just ask the core whether the client is already asleep.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
The dtrace doc was recently added in commit
9c171d4aee
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Change the damage extension reporter to queue up events after we chain
to the wrapped functions. Damage events are typically sent out after
the rendering happens anyway, since we submit batch buffers from the
flush callback chain and then flush client io buffers. Compositing
managers relie on this order, and there is no way we could reliably
provide damage events to clients before the rendering happens anyway.
By queueing up the damage events before the rendering happens, there's
a risk that the client io buffer may overflow and send the damage
events to the client before the driver has even seen the rendering
request. Reporting damage events after the rendering fixes this
corner case and better corresponds with how we expect this to work.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
We were missing the callback in a couple of places. Drivers may use
the flush callback to submit batched up rendering before events (for
example, damage events) are sent out, to ensure that the rendering
has been queued when the client receives the event.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Mark argument to DDC_checksum as const too.
Signed-off-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
We were incorrectly NULLing out pDraw in __GLXDrawable instead of ours in
__GLXAquaDrawable. (we should refactor to eliminate this redundancy later)
This was causing http://xquartz.macosforge.org/trac/ticket/426
This was benign until commit f0006aa58f
The root cause of this change was fed7ccc481ad1caaa518cafe944c2327a5d0b6c65
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
Mostly pulled together from posts to my blog and the docs posted
at http://people.freedesktop.org/~alanc/dtrace/ and converted to
DocBook.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Patrick E. Kane <pekane52@gmail.com>
Reflects API change made in commit 895f40792a during Xorg 1.8 development
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Patrick E. Kane <pekane52@gmail.com>
Bumps minimum xorg-macros requirement from 1.6 to 1.10
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Patrick E. Kane <pekane52@gmail.com>
Devices that are both pointers and keyboards are not affected by keyboard
changes as their master device is a master pointer, not a master keyboard.
Use GetMaster() instead to ensure devices that are attached to the paired
master pointer device will still be update.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
The current core enter/leave does not cater for device grabs during
enter/leave events. If a window W contains a pointer P1 and a client grabs a
pointer P2, this pointer will not generate enter/leave events inside this
window.
Hack around this by forcing grabbed devices to always send enter/leave
events.
X.Org Bug 27804 <http://bugs.freedesktop.org/show_bug.cgi?id=27804>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
If the native root window isn't resized as well, we will likely crash the
next time we draw to the root. On OS X, this can be seen by:
1) Put the display preferences in the menu bar and set X11's preferences so you
can access the menu bar in fullscreen mode
2) Set the resolution of your screen lower than normal.
3) Start X11 in fullscreen mode. The root window will cover the screen as
expected.
4) Use the menu bar to increase the resolution of the display. The root
window will now cover the old area and not the full screen, but
'xwininfo -root' will report the full width.
5) Run 'xsetroot -solid red', and we have the crash you mention above.
Leaving/entering fullscreen after #4 will fix the problem. This is because the
WINREC is erased when we leave fullscreen mode and it is recreated upon
re-entry:
RootlessUpdateRooted(FALSE)
RootlessDisableRoot(screenInfo.screens[0])
RootlessDestroyFrame (pRoot, winRec);
RootlessUpdateRooted(TRUE)
RootlessEnableRoot(screenInfo.screens[0])
RootlessEnsureFrame(screenInfo.screens[0]->pRoot)
creates a new WINREC...
Signed-off-by: Jan Hauffa <hauffa@in.tum.de>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Acked-By: Jon TURNEY <jon.turney@dronecode.org.uk>
Tested-by: Jeremy Huddleston <jeremyhu@apple.com>
Previously we assumed every pixmap destroyed during a software fallback was
also created during a software fallback and had access prepared, but that's
not always true.
Fixes a server abort
Reported-by: 邓逸昕 <bupt.dengyixin@gmail.com>
Signed-off-by: Michel Dänzer <daenzer@vmware.com>
Acked-by: Maarten Maathuis <madman2003@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Because some EnterVT code needs to remove it self from the
call chain, we need to fix all of the wrappers to correctly
unwrap/rewrap during the call chain. This is a follow-on to the fix
for bug 27114 in commit 68a9ee8370.
Signed-off-by: Keith Packard <keithp@keithp.com>
Tested-by: Jesse Barnes <jesse.barnes@intel.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Tiago Vignatti <tiago.vignatti@nokia.com>
If a pixmap header is modified or the drawable serial changes, some
aspects of the drawable are likely to have changed so we should
re-allocate the corresponding DRI2 drawable in that case. This is one
way of catching when the root window pixmap changes through xrandr.
Fixes bug https://bugs.freedesktop.org/show_bug.cgi?id=28365.
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
We should update the serial number even if we just change a single field.
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
Same as the matching key functions. Buttons, like keys, can have two states
for down/up - one posted, one processed. Posted is set during event
generation (usually in the signal handler). Processed is set during event
processing when the event queue is emptied and events are being delivered to
the client.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Having miPointerMove and miPointerMoved is confusing, especially since both
do the same thing bar the event delivery. Also, miPointerMove calls
miPointerMoved which indicates some confusion in the temporal alignment of
cause and effect.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Support for the blend mode operators was added in
0ce42adbf4
and the requirement was bumped but when things were split off into
include/protocol-versions.h it defined it to 10. render uses
the lower of the client and server advertised versions so it's not
using the new blend mode operators.
Signed-off-by: Robert Hooker <sarvatt@ubuntu.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
miDbeInit pre-allocates space in each DBE window private private for a
MiDbeWindowPrivPrivRec. miDbeAllocBackBufferName used the
pre-allocated space correctly (simply fetching it instead of
allocating a new piece of memory). However, it then called
dixSetPrivate anyways, which isn't necessary, and (in the new
dixPrivate world) causes an assert failure.
Signed-off-by: Keith Packard <keithp@keithp.com>
Tested-by: Magnus Kessler <Magnus.Kessler@gmx.net>
Reviewed-by: Magnus Kessler <Magnus.Kessler@gmx.net>
MiDbeScreenPrivPrivRec is not used in the server. Remove it, along
with the MI_DBE_SCREEN_PRIV_PRIV macro that tried to use it.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Magnus.Kessler <Magnus.Kessler@gmx.net>
Fix for OpenSolaris bug 6949755: Mouse Keys are ununusable
and possibly https://bugs.freedesktop.org/show_bug.cgi?id=24856
Ensures waitForUpdate is False before calling SetCursorPosition.
Normally waitForUpdate is False when SilkenMouse is active, True
when it's not. When it's True, the mouse cursor position on
screen is not updated immediately.
This is more critical on Solaris, since we disabled SigIO, thus in turn
disable SilkenMouse, due to the SSE2 vs. signal handler issues described in
Sun bugs 6849925, 6859428, and 6879897.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When this privates.h is included in C++ builds, the compiler
complains about implicitly casting void* to void**. This small
patch fixes that up.
Signed-off-by: James Jones <jajones@nvidia.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
If a button release event is posted for the MD pointer, post a release event
through the matching XTEST device. This way, a client who posts a button
press through the XTEST extension cannot inadvertedly lock the button.
This behaviour is required for historical reasons, until server 1.7 the core
pointer would release a button press on physical events, regardless of the
XTEST state. Clients seem to rely on this behaviour, causing seemingly stuck
grabs.
The merged behaviour is kept for multiple keyboard PointerKey events, if two
physical keyboards hold the button down as a result of PointerKey actions,
the button is not released until the last keyboard releases the button.
X.Org Bug 28808 <http://bugs.freedesktop.org/show_bug.cgi?id=28808>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Although vendor and board naming are used to create the configure file, the
server doesn't actually use it when fetching such file and probing devices.
Reported-by: Richard Barnette <jrbarnette@chromium.org>
Signed-off-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Reviewed-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Tested-by: Richard Barnette <jrbarnette@chromium.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
