Re: [PATCH xserver] test: Fix stray Makefile reference to removed os test

2016-11-18 Thread Peter Hutterer 
On Sat, Nov 19, 2016 at 04:11:28AM +, Rhys Kidd wrote:
> On Fri, Oct 28, 2016 at 8:27 PM Keith Packard  wrote:
> 
> > Rhys Kidd  writes:
> >
> > > Fixes the following warning:
> > >
> > > test/Makefile.am:69: warning: variable 'os_LDADD' is defined but no
> > program or
> > > test/Makefile.am:69: library has 'os' as canonical name (possible typo)
> > >
> > > Introduced upon the removal of test/os in:
> > >
> > > commit 6a5a4e60373c1386b311b2a8bb666c32d68a9d99
> > > Author: Keith Packard 
> > > Date:   Tue Dec 8 14:39:46 2015 -0800
> > >
> > > Remove SIGIO support for input [v5]
> > >
> > > This removes all of the SIGIO handling support used for input
> > > throughout the X server, preparing the way for using threads for
> > input
> > > handling instead.
> > >
> > > Places calling OsBlockSIGIO and OsReleaseSIGIO are marked with calls
> > > to stub functions input_lock/input_unlock so that we don't lose this
> > > information.
> > >
> > > xfree86 SIGIO support is reworked to use internal versions of
> > > OsBlockSIGIO and OsReleaseSIGIO.
> > >
> > > v2: Don't change locking order (Peter Hutterer)
> > > v3: Comment weird && FALSE in xf86Helper.c
> > > Leave errno save/restore in xf86ReadInput
> > > Squash with stub adding patch (Peter Hutterer)
> > > v4: Leave UseSIGIO config parameter so that
> > > existing config files don't break (Peter Hutterer)
> > > v5: Split a couple of independent patch bits out
> > > of kinput.c (Peter Hutterer)
> > >
> > > Signed-off-by: Keith Packard 
> > > Reviewed-by: Peter Hutterer 
> > >
> > > Signed-off-by: Rhys Kidd 
> >
> > Reviewed-by: Keith Packard 
> >
> > (we'll wait until after 1.19 to merge this to master)
> >
> > --
> > -keith
> >
> 
> Gentle ping now that 1.19 is out.

pushed, thanks for the ping

   f0f8d5b..cf88607  master -> master

Cheers,
   Peter
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] test: Fix stray Makefile reference to removed os test

2016-11-18 Thread Rhys Kidd 
On Fri, Oct 28, 2016 at 8:27 PM Keith Packard  wrote:

> Rhys Kidd  writes:
>
> > Fixes the following warning:
> >
> > test/Makefile.am:69: warning: variable 'os_LDADD' is defined but no
> program or
> > test/Makefile.am:69: library has 'os' as canonical name (possible typo)
> >
> > Introduced upon the removal of test/os in:
> >
> > commit 6a5a4e60373c1386b311b2a8bb666c32d68a9d99
> > Author: Keith Packard 
> > Date:   Tue Dec 8 14:39:46 2015 -0800
> >
> > Remove SIGIO support for input [v5]
> >
> > This removes all of the SIGIO handling support used for input
> > throughout the X server, preparing the way for using threads for
> input
> > handling instead.
> >
> > Places calling OsBlockSIGIO and OsReleaseSIGIO are marked with calls
> > to stub functions input_lock/input_unlock so that we don't lose this
> > information.
> >
> > xfree86 SIGIO support is reworked to use internal versions of
> > OsBlockSIGIO and OsReleaseSIGIO.
> >
> > v2: Don't change locking order (Peter Hutterer)
> > v3: Comment weird && FALSE in xf86Helper.c
> > Leave errno save/restore in xf86ReadInput
> > Squash with stub adding patch (Peter Hutterer)
> > v4: Leave UseSIGIO config parameter so that
> > existing config files don't break (Peter Hutterer)
> > v5: Split a couple of independent patch bits out
> > of kinput.c (Peter Hutterer)
> >
> > Signed-off-by: Keith Packard 
> > Reviewed-by: Peter Hutterer 
> >
> > Signed-off-by: Rhys Kidd 
>
> Reviewed-by: Keith Packard 
>
> (we'll wait until after 1.19 to merge this to master)
>
> --
> -keith
>

Gentle ping now that 1.19 is out.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] xwayland: Fix use after free of cursors

2016-11-18 Thread Olivier Fourdan 
> Sometimes, Xwayland will try to use a cursor that has just been freed,
> leading to a crash when trying to access that cursor data either in
> miPointerUpdateSprite() or elsewhere.
> [...]

Right, I think I have to withdraw this patch, because it probably doesn't fix 
the issue...

I still believe the problem finds its root in xwl_xy_to_window() but I still 
haven't found an appropriate fix.

Sorry about that,
Olivier

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [Spice-devel] [PATCH xf86-video-qxl] Adjust xspice_wakeup_handler() prototype for building xspice with server 1.19

2016-11-18 Thread Hans de Goede 

Hi,

On 18-11-16 14:04, Timo Aaltonen wrote:

On 04.10.2016 14:41, Hans de Goede wrote:

Hi,

On 03-10-16 12:04, Christophe Fergeau wrote:



On Thu, Sep 29, 2016 at 01:03:01PM +0200, Hans de Goede wrote:

Signed-off-by: Hans de Goede 
---
 src/spiceqxl_main_loop.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/spiceqxl_main_loop.c b/src/spiceqxl_main_loop.c
index db89b6d..0ac1f3e 100644
--- a/src/spiceqxl_main_loop.c
+++ b/src/spiceqxl_main_loop.c
@@ -330,7 +330,11 @@ static int no_write_watches(Ring *w)
 return 1;
 }

+#if ABI_VIDEODRV_VERSION >= SET_ABI_VERSION(23, 0)


We have an occurrence of
#if GET_ABI_MAJOR(ABI_VIDEODRV_VERSION) < 6
I'd use this here too to stay consistent (I assume they are equivalent
here).

Acked-by: Christophe Fergeau 


Sorry, but this patch turns out to be incomplete, self NACK.

I just saw that spiceqxl_main_loop also uses a BlockHandler
(xspice_block_handler) and expects to be able to add
fds to watch for read activity through the xserver mainloop
by treating the 3th argument as a FD_SET.

This is no longer supported as of xserver 1.19, instead
the new NotifyFD functionality should be used. The advantage
of this is that it can also properly watch fds for them
becoming ready for writing.

For an example patch of how to use the new NotifyFD
functionality see the recent tigervnc patch to make
tigervnc work with 1.19:

https://lists.x.org/archives/xorg-devel/2016-October/051482.html


Any update here?


Nope, sorry.


Looks like you still have the original patch in Fedora ;)


Yes, because it fixes the build. Xspice is not widely used,
so no-one has noticed it is broken yet...

Regards,

Hans
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [Mesa-dev] UDL & Modeset with Mesa 13.0.1 - Segmentation fault

2016-11-18 Thread Emil Velikov 
On 17 November 2016 at 20:15, poma  wrote:
>
> Airlie solved everything concerning the kernel,
> so it seems, now it's user space turn.
>
> = mesa-libgbm-12.0.3 - works OK
> ...
> [   714.429] (II) Loading sub module "glamoregl"
> [   714.429] (II) LoadModule: "glamoregl"
> [   714.430] (II) Loading /usr/lib64/xorg/modules/libglamoregl.so
> [   714.480] (II) Module glamoregl: vendor="X.Org Foundation"
> [   714.481]compiled for 1.19.0, module version = 1.0.0
> [   714.481]ABI class: X.Org ANSI C Emulation, version 0.4
> ...
> [   714.481] (II) glamor: OpenGL accelerated X.org driver based.
> [   714.633] (II) glamor: EGL version 1.4 (DRI2):
> [   714.633] EGL_MESA_drm_image required.
> [   714.634] (EE) modeset(0): glamor initialization failed
> [   714.634] (II) modeset(0): ShadowFB: preferred NO, enabled NO
> ...
> [   714.643] (==) Depth 24 pixmap format is 32 bpp
> [   714.645] (==) modeset(0): Backing store enabled
> [   714.645] (==) modeset(0): Silken mouse enabled
> [   714.645] (II) modeset(0): RandR 1.2 enabled, ignore the following RandR 
> disabled message.
> [   714.646] (==) modeset(0): DPMS enabled
> [   714.646] (--) RandR disabled
> [   714.669] (II) AIGLX: Screen 0 is not DRI2 capable
> [   714.669] (EE) AIGLX: reverting to software rendering
> [   714.683] (II) IGLX: enabled GLX_MESA_copy_sub_buffer
> [   714.686] (II) IGLX: Loaded and initialized swrast
> [   714.686] (II) GLX: Initialized DRISWRAST GL provider for screen 0
> [   714.691] (II) modeset(0): Damage tracking initialized
> ...
>
> = mesa-libgbm-13.0.1 - not quite
> ...
> [  2324.953] (II) Loading sub module "glamoregl"
> [  2324.953] (II) LoadModule: "glamoregl"
> [  2324.953] (II) Loading /usr/lib64/xorg/modules/libglamoregl.so
> [  2325.000] (II) Module glamoregl: vendor="X.Org Foundation"
> [  2325.000]compiled for 1.19.0, module version = 1.0.0
> [  2325.000]ABI class: X.Org ANSI C Emulation, version 0.4
> ...
> [  2325.001] (II) glamor: OpenGL accelerated X.org driver based.
> [  2325.002] (EE)
> [  2325.002] (EE) Backtrace:
> [  2325.006] (EE) 0: /usr/libexec/Xorg (OsLookupColor+0x139) [0x59e389]
> [  2325.008] (EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0) 
> [0x7f69d836ac2f]
> [  2325.009] (EE) 2: /lib64/libgbm.so.1 (gbm_surface_has_free_buffers+0x1505) 
> [0x7f69d2b64685]
> [  2325.010] (EE) 3: /lib64/libgbm.so.1 (gbm_surface_has_free_buffers+0x1b98) 
> [0x7f69d2b653b8]
> [  2325.011] (EE) 4: /lib64/libgbm.so.1 (gbm_surface_has_free_buffers+0x1498) 
> [0x7f69d2b644c8]
> [  2325.012] (EE) 5: /lib64/libgbm.so.1 (gbm_create_device+0x4c) 
> [0x7f69d2b61a4c]
> [  2325.014] (EE) 6: /usr/lib64/xorg/modules/libglamoregl.so 
> (glamor_egl_init+0x83) [0x7f69d2d73fb3]
> [  2325.015] (EE) 7: /usr/lib64/xorg/modules/drivers/modesetting_drv.so 
> (_init+0x4d21) [0x7f69d2facfd1]
> [  2325.016] (EE) 8: /usr/libexec/Xorg (InitOutput+0xa82) [0x47d6c2]
> [  2325.017] (EE) 9: /usr/libexec/Xorg (InitFonts+0x216) [0x43ae36]
> [  2325.020] (EE) 10: /lib64/libc.so.6 (__libc_start_main+0xf1) 
> [0x7f69d7fb8731]
> [  2325.022] (EE) 11: /usr/libexec/Xorg (_start+0x29) [0x424d29]
> [  2325.024] (EE) 12: ? (?+0x29) [0x29]
> [  2325.025] (EE)
> [  2325.025] (EE) Segmentation fault at address 0xc
> [  2325.025] (EE)
> Fatal server error:
> [  2325.025] (EE) Caught signal 11 (Segmentation fault). Server aborting
> [  2325.026] (EE)
> [  2325.026] (EE)
> ...
> [  2325.027] (EE) Server terminated with error (1). Closing log file.
>
>
> A call to not load the module(s) is not at all useful:
> Section "Module"
> Disable  "glx"
> Disable  "glamoregl"
> EndSection
>
> ...
> (WW) "glx" will not be loaded unless you've specified it to be loaded 
> elsewhere.
> (WW) "glamoregl" will not be loaded unless you've specified it to be loaded 
> elsewhere.
> (II) "glx" will be loaded even though the default is to disable it.
> ...
> (II) Loading sub module "glamoregl"
> (II) LoadModule: "glamoregl"
> (II) Loading /usr/lib64/xorg/modules/libglamoregl.so
> (II) Module glamoregl: vendor="X.Org Foundation"
> compiled for 1.19.0, module version = 1.0.0
> ABI class: X.Org ANSI C Emulation, version 0.4
> (II) glamor: OpenGL accelerated X.org driver based.
> (EE)
> (EE) Backtrace:
> ...
>
> Therefore, until the issue resolved, there remain two workarounds:
> downgrade mesa to 12.0.3, what works
> OR
> leave mesa 13.0.1 and:
> # rm /usr/lib64/xorg/modules/libglamoregl.so
>
Is that with libdrm 2.4.72 or later ? Older ones are known to be
broken with non-pci devices.
Additionally ensure that your pthread-stubs package does _not_ have
the following commit/patch [1].

Thanks
Emil

[1] 
https://cgit.freedesktop.org/xcb/pthread-stubs/commit/?id=fa6db2f9c018c54a47e94c0175450303d700aa92
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [Spice-devel] [PATCH xf86-video-qxl] Adjust xspice_wakeup_handler() prototype for building xspice with server 1.19

2016-11-18 Thread Timo Aaltonen 
On 04.10.2016 14:41, Hans de Goede wrote:
> Hi,
> 
> On 03-10-16 12:04, Christophe Fergeau wrote:
>>
>>
>> On Thu, Sep 29, 2016 at 01:03:01PM +0200, Hans de Goede wrote:
>>> Signed-off-by: Hans de Goede 
>>> ---
>>>  src/spiceqxl_main_loop.c | 4 
>>>  1 file changed, 4 insertions(+)
>>>
>>> diff --git a/src/spiceqxl_main_loop.c b/src/spiceqxl_main_loop.c
>>> index db89b6d..0ac1f3e 100644
>>> --- a/src/spiceqxl_main_loop.c
>>> +++ b/src/spiceqxl_main_loop.c
>>> @@ -330,7 +330,11 @@ static int no_write_watches(Ring *w)
>>>  return 1;
>>>  }
>>>
>>> +#if ABI_VIDEODRV_VERSION >= SET_ABI_VERSION(23, 0)
>>
>> We have an occurrence of
>> #if GET_ABI_MAJOR(ABI_VIDEODRV_VERSION) < 6
>> I'd use this here too to stay consistent (I assume they are equivalent
>> here).
>>
>> Acked-by: Christophe Fergeau 
> 
> Sorry, but this patch turns out to be incomplete, self NACK.
> 
> I just saw that spiceqxl_main_loop also uses a BlockHandler
> (xspice_block_handler) and expects to be able to add
> fds to watch for read activity through the xserver mainloop
> by treating the 3th argument as a FD_SET.
> 
> This is no longer supported as of xserver 1.19, instead
> the new NotifyFD functionality should be used. The advantage
> of this is that it can also properly watch fds for them
> becoming ready for writing.
> 
> For an example patch of how to use the new NotifyFD
> functionality see the recent tigervnc patch to make
> tigervnc work with 1.19:
> 
> https://lists.x.org/archives/xorg-devel/2016-October/051482.html

Any update here? Looks like you still have the original patch in Fedora ;)

A new release with this fixed would be great.


-- 
t
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xf86-input-libinput] If the parent libinput_device is unavailable, create a new one

2016-11-18 Thread Hans de Goede 

Hi,

On 18-11-16 07:47, Peter Hutterer wrote:

On Tue, Nov 15, 2016 at 10:35:31AM +0100, Hans de Goede wrote:

Hi,

On 15-11-16 05:37, Peter Hutterer wrote:

The parent device ref's the libinput device during pre_init and unref's it
during DEVICE_INIT, so the copy is lost. During DEVICE_ON, the libinput device
is re-added and ref'd, this one stays around now. But the takeaway is: unless
the device is enabled, no libinput device reference is available.

If a device is a mixed pointer + keyboard device, a subdevice is created
during a WorkProc. The subdevice relied on the parent's libinput_device being
available and didn't even check for it. This WorkProc usually runs after
the parent's DEVICE_ON, so in most cases all is well.

But when running without logind and the server is vt-switched away, the parent
device only runs PreInit and DEVICE_INIT but never DEVICE_ON, causing the
subdevice to burn, crash, and generally fail horribly when it dereferences the
parent's libinput device.

Fix this because we have global warming already and don't need to burn more
things and also because it's considered bad user experience to have the
server crash. The simple fix is to check the parent device first and if it is
unavailable, create a new one because it will end up disabled as well anyway,
so the ref goes away as well. The use-case where the parent somehow gets
disabled but the subdevice doesn't is a bit too niche to worry about.

This doesn't happen with logind because in that case we don't get a usable fd
while VT-switched away, so we can't even run PreInit and never get this far
(see the paused fd handling in the xfree86 code for that). It can be
reproduced by setting AutoEnableDevices off, but why would you do that,
seriously.

https://bugs.freedesktop.org/show_bug.cgi?id=97117

Signed-off-by: Peter Hutterer 


Hmm, so what happens if the parent device later does get DEVICE_ON, after
the subdevice has created its own libinputdevice ?


we don't differ between parent and subdevices during DEVICE_ON, whichever
one is the first adds the device and the rest just refcounts it. so we
should be good here.


Ok, in that case, the original patch looks good to me and is:

Reviewed-by: Hans de Goede 

Regards,

Hans
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [ANNOUNCE] xorg-server 1.19.0

2016-11-18 Thread Thomas Klausner 
On Thu, Nov 17, 2016 at 09:55:01AM +1000, Peter Hutterer wrote:
> On Wed, Nov 16, 2016 at 02:18:29PM +0100, Thomas Klausner wrote:
> > The release breaks most currently existing graphics driver releases
> > and two input driver releases (details below).
> 
> yes, a driver released for an older X server is not guaranteed to work with
> a newer x server. that's usually expected, we have to wait for a server
> release before we can release the drivers (yes, pre-releases are possible,
> but these are not the most interesting drivers).

I agree for most of these, but wonder about the intel and qxl ones,
which do have quite a bit of activity in git.

> now that we have a server release, we can start releasing the drivers. I'll
> be doing the input ones ove the next couple of days.

Thank you for the releases!
 Thomas
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel