Commits on Source (29)
-
Adam Jackson authored
We're not wrapping all the ways a cursor can be destroyed, so this array ends up with stale data. Rather than try harder to wrap more code paths, just look up the cursor when we need it. Signed-off-by:
Adam Jackson <ajax@redhat.com> (cherry picked from commit aa6651f8)
-
Nikolay Martynov authored
It looks like offsets calculated during image censoring are wrong. This results in black (empty) images returns. This fix is very similar to 6c6f09aa that was applied to XGetImage Visually this fixes chromium/firefox window sharing in multiscreen configurations - without this patch most of the windows on 'secodnary' screens are black. This also should fix https://bugs.freedesktop.org/show_bug.cgi?id=101730 . Signed-off-by:
Nikolay Martynov <mar.kolya@gmail.com> Reviewed-by:
-
Alex Goins authored
Similar to change cba5a10f, xf86ScreenSetCursor() would dereference ScreenPriv without NULL checking it. If Option "SWCursor" is specified, ScreenPriv == NULL. Without this fix, it is observed that setting Option "SWCursor" "on" on the modesetting driver in a PRIME configuration will segfault the server. It is important to return success rather than failure in the instance that ScreenPriv == NULL and pCurs == NullCursor, because otherwise xf86SetCursor() can fall into infinite recursion: xf86SetCursor(pCurs) calls xf86ScreenSetCursor(pCurs), and if FALSE, calls xf86SetCursor(NullCursor). If xf86ScreenSetCursor(NullCursor) returns FALSE, it calls xf86SetCursor(NullCursor) again and this repeats forever. Signed-off-by:
Alex Goins <agoins@nvidia.com> Reviewed-by:
Dave Airlie <airlied@redhat.com> (cherry picked from commit 68d95e75)
-
Daniel Martin authored
If one misconfigures a ZaphodHeads value (more than 20 characters without a delimiter), we get an overflow of our buffer. Use xstrtokenize() instead of writing/fixing our own tokenizer. Signed-off-by:
Daniel Martin <consume.noise@gmail.com> Reviewed-by:
Eric Engestrom <eric.engestrom@imgtec.com> (cherry picked from commit 04a30512)
-
Daniel Martin authored
input.c: In function ‘dix_event_to_core’: ../include/inputstr.h:61:55: warning: ‘*((void *)&ev+80)’ is used uninitialized in this function [-Wuninitialized] #define SetBit(ptr, bit) (((BYTE *) (ptr))[(bit)>>3] |= (1 << ((bit) & 7))) ^~ Signed-off-by: -
Daniel Martin authored
unsigned_tests[] was used to compute the amount of signed numbers to test. Signed-off-by:
-
Peter Hutterer authored
Historically we didn't need to care about this case but more devices are having invalid types set and they cannot be unset with a hwdb entry (which doesn't handle the empty string). Allow for "0" to mean "unset" because anything else would be crazy anyway. Signed-off-by:
Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 5aad8144)
-
Emma Anholt authored
I don't know how many times I've had a broken server due to a bad directory to xkbcomp, and only finding the whole path has shown me where I went wrong. Reviewed-by:
-
Giuseppe Bilotta authored
This fixes some “Conditional jump depends on uninitialized value(s)” errors spotted by valgrind. Reviewed-by:
Giuseppe Bilotta <giuseppe.bilotta@gmail.com> (cherry picked from commit b2167015)
-
Giuseppe Bilotta authored
Running Xephyr under valgrind reveals that we're sending some uninitialized memory over the wire (particularly, the leftover padding that comes from rounding extraLen to the next 32-bit multiple). Solve by calloc()ing the memory instead of malloc()ing (the alternative would be to memset just the padding, but I'm not sure it's more convenient.) Signed-off-by:
-
Adam Jackson authored
The trailing \n are just wrong here, __glXEnableExtension wants a string without them. Signed-off-by:
Michel Dänzer <michel.daenzer@amd.com> Reviewed-by:
Emil Velikov <emil.velikov@collabora.com> (cherry picked from commit fd0eafb1)
-
Hector Martin authored
The CEA extension short video descriptors contain the VIC, which starts at 1, not 0. Reviewed-by:
Hector Martin <marcan@marcan.st> (cherry picked from commit 68556d74)
-
Adam Jackson authored
If the context is direct none of the GL commands were issued by this process, the server couldn't flush them even if it wanted to. v2: Fix embarassingly obvious boolean inversion (Michel Dänzer) Signed-off-by:
-
Giuseppe Bilotta authored
Similarly to bb766ef1, ensure that the extra padding is set to 0. Reviewed-by:
-
Michel Dänzer authored
We were sending the events to all clients listening for them on the window. But clients can get confused by events from another client, and I can't imagine any case where receiving events from other clients would be required. v2: * Also restrict events sent to additional windows to the presenting client * Don't shorten line lengths Reviewed-by:
Keith Packard <keithp@keithp.com> (cherry picked from commit 559954aa)
-
Daniel Martin authored
Terminate a dead session when -once was passed. Don't restart it. Signed-off-by:
Walter Harms <wharms@bfs.de> (cherry picked from commit 918afeec)
-
Adam Jackson authored
Just never filled in, oops. Seems to have gone unnoticed because normally glXQueryContext simply returns the values filled in by the client library when the context was created. The only path by which you normally get to a GLXQueryContext request is glXImportContext, and then only if the context is already indirect. However, that's a statement about Mesa's libGL (and anything else that inherited that bit of the SGI SI more or less intact). Nothing prevents a mischeivous client from issuing that request of a direct context, and if they did we'd be in trouble because we never bothered to preserve the associated fbconfig in the context state, so we'd crash looking up GLX_VISUAL_ID_EXT. So let's fix that too. v2: Fixed missing preservation of the config in DRI2 (Eric Anholt) Signed-off-by:
Eric Anholt <eric@anholt.net> (cherry picked from commit 5d667df6)
-
Olivier Fourdan authored
From the bug: "What happens if bits->width is less than 8? :)" Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=103012 Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Daniel Stone <daniels@collabora.com> (cherry picked from commit 97ac59b1)
-
Olivier Fourdan authored
PtrCtrl really makes sense for relative pointing device only, absolute devices such as touch devices do not have any PtrCtrl set. In some cases, if the client issues a XGetPointerControl() immediatlely after a ChangeMasterDeviceClasses() copied the touch device to the VCP, a NULL pointer dereference will occur leading to a crash of Xwayland. Check whether the PtrCtrl is not NULL in ProcGetPointerControl() and return the default control values otherwise, to avoid the NULL pointer dereference. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1519533 Reviewed-by:
-
Tomasz Śniatowski authored
Don't reuse cmd for strtok output to ensure the proper pointer is freed afterwards. The code incorrectly assumed the pointer returned by strtok(cmd, ":") would always point to cmd. However, strtok(str, sep) != str if str begins with sep. This caused an invalid-free crash when running a program under X with a name beginning with a colon. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=104123 Signed-off-by:
Tomasz Śniatowski <kailoran@gmail.com> Reviewed-by:
-
Adam Jackson authored
This comment is above compIsAlternateVisual, which used to be the only thing determining whether implicit redirect was needed. It's not anymore due to the redirection exception list. That job is now performed by compImplicitRedirect, whose code is self-explanitory. Reviewed-by:
-
Adam Jackson authored
Reviewed-by:
-
Adam Jackson authored
As of ea483af9 we're calling this unconditionally from the GLX code so the synthetic visual is in a lower select group. If Composite has been disabled then GetCompScreen() will return NULL, and this would crash. Rather than force the caller to check first, just always return FALSE if Composite is disabled (which is correct, since none of the visuals will be synthetic in that case). Signed-off-by:
Aaron Plattner <aplattner@nvidia.com> (cherry picked from commit f8011912)
-
Adam Jackson authored
We already send this for fbconfigs. Mesa happens to implement glXChooseVisual relative to the fbconfig data, but that might not be true of NVIDIA's libGL. Reviewed-by:
-
Adam Jackson authored
Should you find yourself using a 16bpp display while also using a compositor, you poor soul, you may find that your GLX applications behave strangely; in particular, glxgears will be transparent. This is because it clears to (0,0,0,0) which is transparent if you honor alpha, and it will choose the synthetic visual because it has the most available r/g/b bits. To avoid this, bump synthetic visuals to a higher (less-preferred) select group. Unless the client explicitly asks for non-zero alpha bits, this will prefer any rgb565 visual ahead of the argb8888 visual. Reviewed-by:
-
Thomas Hellstrom authored
The swapMethod config member would typically contain an arbitrary value on older dri drivers. Fix this so that if we detect an illegal value, return GLX_SWAP_UNDEFINED_OML. Signed-off-by:
Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by:
-
Thomas Hellstrom authored
For the built in visuals, we'd typically select the "best" fbconfig without considering the swap method. If the client then requests a specific swap method, say GLX_SWAP_COPY_OML, it may well happen that the first fbconfig matching requirements would have been paired with the 32-bit compositing visual, and the client would render a potentially transparent window. Fix this so that we try to match fbconfigs with the same swap method to all built-in visuals. That would guarantee that selecting a specific swap- method would not influence the chance of getting a compositing visual. Signed-off-by:
-
Thomas Hellstrom authored
Previously, before GLX_OML_swap_method was fixed, both the X server and client ignored the swapMethod fbconfig value, which meant that, if the dri driver thought it exposed more than one swapMethod, it actually just exported a duplicated set of fbconfigs. When fixing GLX_OML_swap_method and restricting the choice for built-in visuals to a single swap method that meant we didn't have that many fbconfigs to choose from when pairing the compositing visual with an fbconfig, resulting in the fbconfig paired with the compositing visual becoming too restrictive for some applications, (at least for kwin). This problem would also happen if the dri driver only exposed a single swap method to begin with. So, to make sure the compositing visual gets a good enough fbconfig, duplicate fbconfigs that are suitable for compositing visuals and make sure these duplicated fbconfigs can be used only by compositing visuals. For duplicated fbconfigs not paired with a compositing visual, construct new compositing visuals, making compositing clients able to choose visuals / fbconfig more adapted to their needs. This is in some sense equivalent to adding a new "TRUECOLOR_COMPOSITING" GLX visualtype. Fixes: 4486d199 ("glx: Fix visual fbconfig matching with respect to swap method") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102806 Signed-off-by:
Nick Sarnie <commendsarnex@gmail.com> Tested-by:
Fredrik Höglund <fredrik@kde.org> Reviewed-by:
-
Adam Jackson authored
Signed-off-by:
