Re: [PATCH xserver] os: Call FlushClient() before sending FD-passing messages

On Tue, Apr 10, 2018 at 5:14 AM, Keith Packard wrote: >> libxcb stores received file descriptors in the buffer of size 16 >> (XCB_MAX_PASS_FD). >> Whether it's possible that the X server will send more than 16 fds in a >> single reply >> and overflow the libxcb's buffer? > > It

Re: [PATCH xserver] os: Call FlushClient() before sending FD-passing messages

Alexander Volkov writes: > libxcb stores received file descriptors in the buffer of size 16 > (XCB_MAX_PASS_FD). > Whether it's possible that the X server will send more than 16 fds in a > single reply > and overflow the libxcb's buffer? It wouldn't be if the X server

Re: [PATCH xserver] dix: always send focus event on grab change

On Mon, Apr 09, 2018 at 02:35:30PM +0200, Samuel Thibault wrote: > Focus events are useless when 'from' and 'to' are the same. But when > this is the result of a (Un)GrabKeyboard request, we should always send > them, including when the window manager had previously used XSetInputFocus > to

Re: [PATCH xserver] hw/xwin/glx: Allocate fbconfigs correctly

On Tue, 2018-04-03 at 16:54 +0100, Jon Turney wrote: > 4b0a3cba fixed leaking of GLX fbconfigs, so now xwin needs to allocate them > correctly (individually, rather than all at once), so they can be freed > successfully. > > Signed-off-by: Jon Turney > Reviewed-by:

Re: [PATCH xserver] GLX: Fix a use after free error with the GLVND vendor handle.

On Fri, 2018-04-06 at 12:42 -0600, Kyle Brenneman wrote: > The GLVND layer will destroy all of the vendor handles at the end of each > server generation, but the GLX module then tries to re-use the same > (now-freed) > handle in xorgGlxServerInit at the start of the next generation. > > In

Re: [PATCH xserver] os: Call FlushClient() before sending FD-passing messages

03.04.2018 21:57, Keith Packard пишет: Alexander Volkov writes: Yes, it would be easier to fix this in libxcb, but I believe that it would be more correct to do this in the X server. At least I want to try to fix the X server. Hrm. The problem is that there are two

[PATCH xserver] dix: always send focus event on grab change

Focus events are useless when 'from' and 'to' are the same. But when this is the result of a (Un)GrabKeyboard request, we should always send them, including when the window manager had previously used XSetInputFocus to specify the focus on a window which happens to be now taking a grab. This is

Re: NotifyGrab

Hello, I have kept the story below for the record and attached the testcase again in case it could be useful. So the issue is that DoFocusEvents does not send focus events if from == to, which happens here because the focus-grab.c is calling XSetInputFocus to set the input focus (as expected for

Re: [PATCH app/xdpyinfo v2] Use XRANDR 1.2 extension for reporting dimensions and resolution per output

On Sun, Apr 8, 2018 at 8:25 PM, Pali Rohár wrote: > On Sunday 08 April 2018 19:22:28 Giuseppe Bilotta wrote: >> The values reported by xdpyinfo aren't bogus, they are what the core >> protocol is providing. > > For users as human readable output from xdpyinfo, those values

Re: Bug 105851 Xserver 1.20 RC2+ issues with Kwin + Present 1.2

Switching between egl and glx can only be done these days by editing the kwinrc file (egl however is used by default on wayland I believe), egl was still enabled from years ago when switching was easy I've attached some coredumps on the bug, though I don't have any debugging compiled into the

Re: Bug 105851 Xserver 1.20 RC2+ issues with Kwin + Present 1.2

On Sat, Apr 7, 2018 at 9:56 AM, Mike Lothian wrote: > Switching to glx from egl gets things started for me Do you mean switching from egl to glx as in switching the compositing backend? And it did not work with egl backend but with glx? The egl backend on X in KWin isn't

Re: [PATCH] revolve possible null pointer dereference issue found by cppcheck

thank you. sorry for false positive 2018-04-09 12:43 GMT+05:00 Michal Srb : > On pondělí 9. dubna 2018 9:31:54 CEST Ilya Shipitsin wrote: > > [dix/inpututils.c:909] -> [dix/inpututils.c:905]: (warning) Either the > > condition 'if(list)' is redundant or there is possible null

Re: [PATCH] revolve possible null pointer dereference issue found by cppcheck

On pondělí 9. dubna 2018 9:31:54 CEST Ilya Shipitsin wrote: > [dix/inpututils.c:909] -> [dix/inpututils.c:905]: (warning) Either the > condition 'if(list)' is redundant or there is possible null pointer > dereference: list. I think this is a false positive by cppcheck. It looks like it

[PATCH] revolve possible null pointer dereference issue found by cppcheck

[dix/inpututils.c:909] -> [dix/inpututils.c:905]: (warning) Either the condition 'if(list)' is redundant or there is possible null pointer dereference: list. Signed-off-by: Ilya Shipitsin --- dix/inpututils.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff