[Xtrans] Interrupted function call for ioctl not handled

[Joerg . Vehlow]

Hi,

I just stumbled upon a bug in Xtrans socket transport on QNX 6.5:
At least on QNX 6.5 the syscall ioctl (FIONREAD) can be interrupted by a 
signal leading to a return value of -1 and errno set to EINTR.

The QNX documentation doesn't mention the error, but it maps the ioctl to 
a devctl, where the behavior is documented. In the POSIX specification 
EINTR is also documented.
I think this is a bug even in current implementations of Xtrans, because 
POSIX allows the EINTR and it for read and write it is handled, but not 
for the ioctl.

Maybe someone should look into fixing it in the future.

Regards Jörg___
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 xts] xts5: Fix clang warning - non-void function DoLayout should return a value

[Eric Anholt]

Echelon9  writes:

> From: Rhys Kidd 
>
> Box.c:245:7: error: non-void function 'DoLayout' should return a value
>   [-Wreturn-type]
> return;
> ^
> Box.c:285:6: error: non-void function 'DoLayout' should return a value
>   [-Wreturn-type]
> return;
> ^
>
> Signed-off-by: Rhys Kidd 

Applied.  Thanks!
___
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 rendercheck] Report results on a per-test basis

[Eric Anholt]

Martin Peres  writes:

> On 21/10/16 19:18, Eric Anholt wrote:
>> Martin Peres  writes:
>>
>>> This allows a runner such as EzBench to track each test individually
>>> and not limit the resolution to groups.
>>>
>>> This feature can be triggered by using the -r parameter.
>>
>> I don't really see the point of this -- you need an external runner to
>> be choosing a specific test subset to run per rendercheck call, since
>> the full matrix of composite tests is too long.  Once you have an
>> external runner calling rendercheck per test group, all you would be
>> able to do using this patch would be save a few spawns of the process,
>> which doesn't seem worth it.
>
> Just to be sure, are you suggesting I do something like this instead?
>
> for format in "a8r8g8b8 x8r8g8b8 ... more formats"; do
>   ./rendercheck -f $format
>   # parse the successful groups and store them, prefixed by $format so as 
> I can identify regressions per format?
> done

You should probably look at piglit for subsetting of the tests.
Actually, I'd say you should probably just use piglit.  Given that
piglit is what X developers are going to be using, if we're going to
lock rendercheck into specific output formats I'd like to see the piglit
patches included with it.
___
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

[PULL] Small fix for 1.19

[Jon Turney]

The following changes since commit 5cb328338684d8e5b03913c47475bfcd7acffec4:

  inputthread: On Linux leave the main thread's name as-is (2016-10-27 09:53:01 
+1000)

are available in the git repository at:

  git://people.freedesktop.org/~jturney/xserver 

for you to fetch changes up to 03d99ef729178dd99268f185fb45320a29382091:

  glx/dri2: Don't build DRI loader if DRI2 isn't enabled (2016-10-27 14:25:42 
+0100)


Jon Turney (1):
  glx/dri2: Don't build DRI loader if DRI2 isn't enabled

 glx/Makefile.am| 11 ---
 hw/xfree86/dixmods/Makefile.am |  2 ++
 2 files changed, 10 insertions(+), 3 deletions(-)
___
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] configure.ac: bump epoxy requirement to 1.2

[Emil Velikov]

On 26 October 2016 at 17:13, Adam Jackson  wrote:
> On Wed, 2016-10-26 at 11:29 +0100, Emil Velikov wrote:
>
>> Maybe coffee hasn't kicked in, but it does seem to matter.
>
> I did not misspeak, I promise.
>
Eek, you're right. Me runs off to find a brown paper bag.

Thanks
Emil
___
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 libxi 2/2] Check that allocating a buffer succeeded

[walter harms]

looks good to me.

Signed-off-by: wha...@bfs.de


Am 25.10.2016 21:31, schrieb Emilio Pozuelo Monfort:
> Since we are going to write into the buffer, we should make sure the
> allocation didn't fail.
> 
> Reported-by: Julien Cristau 
> Signed-off-by: Emilio Pozuelo Monfort 
> ---
>  src/XIQueryDevice.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/src/XIQueryDevice.c b/src/XIQueryDevice.c
> index e3b0c9f..a877d78 100644
> --- a/src/XIQueryDevice.c
> +++ b/src/XIQueryDevice.c
> @@ -66,17 +66,18 @@ XIQueryDevice(Display *dpy, int deviceid, int 
> *ndevices_return)
>  {
>   *ndevices_return = reply.num_devices;
>   info = Xmalloc((reply.num_devices + 1) * sizeof(XIDeviceInfo));
> + buf = Xmalloc(reply.length * 4);
>  }
>  else
>  {
>   *ndevices_return = 0;
>   info = NULL;
> + buf = NULL;
>  }
>  
> -if (!info)
> +if (!info || !buf)
>  goto error;
>  
> -buf = Xmalloc(reply.length * 4);
>  _XRead(dpy, buf, reply.length * 4);
>  ptr = buf;
>  end = buf + reply.length * 4;
> @@ -135,9 +136,9 @@ error_loop:
>  Xfree(info[i].name);
>  Xfree(info[i].classes);
>  }
> +error:
>  Xfree(info);
>  Xfree(buf);
> -error:
>  UnlockDisplay(dpy);
>  error_unlocked:
>  SyncHandle();
___
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: [xserver PULL for 1.19 ] Various small fixes for 1.19

[Hans de Goede]

Hi,

On 26-10-16 12:26, Hans de Goede wrote:

Hi Adam, Keith,

Here is a pull-req with various small fixes
(all with at least 1 Reviewed-by) which I've collected
for merging into 1.19:


I just realized I forgot to add this one:

https://patchwork.freedesktop.org/patch/117894/

It would be good to merge that patch too IMO.

Regards,

Hans






The following changes since commit d13cb974426f7f1110b0bdb08c4ebb46ff8975f7:

  ddx: add new call to purge input devices that weren't added (2016-10-26 
15:35:07 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~jwrdegoede/xserver for-server-1.19

for you to fetch changes up to 7b135f5e7d79622c0b922de8ee827a2556504d8f:

  xwayland: Transform pointer enter event coordinates (2016-10-26 11:51:38 
+0200)


Hans de Goede (1):
  xfree86: Xorg.wrap: Do not require root rights for cards with 0 outputs

Michel Dänzer (1):
  DRI2: Sync radeonsi_pci_ids.h from Mesa

Mihail Konev (2):
  xwin: make glx optional again
  modesetting: fix glamor ifdef

Nikhil Mahale (1):
  modesetting: unifdef MODESETTING_OUTPUT_SLAVE_SUPPORT

Rui Matos (1):
  xwayland: Transform pointer enter event coordinates

 configure.ac |  4 ++--
 hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h   | 12 
 hw/xfree86/drivers/modesetting/driver.c  |  2 ++
 hw/xfree86/drivers/modesetting/drmmode_display.c |  2 --
 hw/xfree86/xorg-wrapper.c|  2 +-
 hw/xwayland/xwayland-input.c |  5 -
 6 files changed, 21 insertions(+), 6 deletions(-)

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: [PATCH xserver] configure.ac: bump epoxy requirement to 1.2

[Adam Jackson]

On Mon, 2016-10-24 at 12:19 -0700, Matt Turner wrote:
> On Mon, Oct 24, 2016 at 2:39 AM, Emil Velikov  
> wrote:
> > > > From: Emil Velikov 
> > 
> > As pointed out in the ABI tracker[1], epoxy has gone through a few
> > non-backwards compatible ABI changes, yet preserved the DSO name.

I don't particularly object to bumping the required version, but...

> > Most noticeable of which, from xserver POV, in epoxy_has_egl_extension()
> > - s/EGLDisplay */EGLDisplay/.

This happens not to matter. If you read the corresponding commit you'll
see that the parameter was always treated as an opaque pointer anyway:

https://github.com/anholt/libepoxy/commit/e20b3ce6c7895f355fd1bad81b45341d98b5ee76

> > Eric, iirc Dave had some ideas about moving libepoxy to fd.o [+ making
> > it the canonical/upstream source] and was looking for your blessing.
> > 
> > How is that going ? The state of the github repo looks tragic.
> 
> ajax and anholt were talking about epoxy's status at XDC. Cc'ing ajax.

I'm honestly on anholt's side here about leaving upstream on github.
fdo is lovely and all but the contribution model for people not already
in posession of an fdo account is terrible. Moving epoxy to fdo would
be a step backwards, and we should continue to hold out on that front
until fdo grows better collaborative hosting.

The more serious issue to me is that epoxy needs a release, and that
release should involve merging up the various forks on github. (This is
an argument _in favor_ of github: not only was it easy for people to
create their forks, but we can track them all down easily.) I'm sure
epoxy isn't Eric's first priority (which is entirely reasonable) so
it's kind of up to him how to proceed here.

- ajax
___
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: Null pointer deref in FlushAllOutput with 1.19-rc1 ?

[Olivier Fourdan]

Hi

> > Multiple Fedora 25 users running 1.19-rc1 are reporting a backtrace
> > related to an InitFonts -> SendErrorToClient -> FlushAllOutput
> > call chain.
> > 
> > Since there is no trivial reproducer this is somewhat hard to debug,
> > hence this mail. Anyone have a clue / hint ?  See:
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1382444
> 
> Actually, I think we cannot really trust the symbols from Xorg's own
> generated backtrace, however, looking at the addresses, the sequence makes
> some more sense:
> 
>   FlushAllOutput() in /usr/src/debug/xorg-server-20160929/os/io.c:612
>   Dispatch() in /usr/src/debug/xorg-server-20160929/dix/dispatch.c:3491
>   dix_main() in /usr/src/debug/xorg-server-20160929/dix/main.c:296
> 
> with /usr/src/debug/xorg-server-20160929/os/io.c:612
> 
>  612 xorg_list_for_each_entry_safe(client, tmp, _pending_clients,
>  output_pending) {
>  613 if (client->clientGone)
>  614 continue;
>  615 if (!client_is_ready(client)) {
>  616 oc = (OsCommPtr) client->osPrivate;
>  617 (void) FlushClient(client, oc, (char *) NULL, 0);
>  618 } else
>  619 NewOutputPending = TRUE;
>  620 }
> 
> So it could be that output_pending_clients list got corrupted somehow.
> 
> Not sure I can go much further than that with so little data, but if that
> rings a bell with someone else...

Some more reports all pointing to FlushAllOutput() with different backtraces, 
e.g.:

 #6 FlushClient at io.c:938
 #7 WriteToClient at io.c:768
 #8 WriteEventsToClient at events.c:6000
 #9 present_send_complete_notify at present_event.c:172
 #10 present_vblank_notify at present.c:213
 #11 present_execute at present.c:771
 #12 present_pixmap at present.c:963
 #13 present_notify_msc at present.c:1014
 #14 proc_present_notify_msc at present_request.c:174
 #15 Dispatch at dispatch.c:469

or 

 #6 FlushClient at io.c:938
 #7 WriteToClient at io.c:768
 #8 ProcGetScreenSaver at dispatch.c:3163
 #9 Dispatch at dispatch.c:469
 #10 dix_main at main.c:287

with 

 792 int
 793 FlushClient(ClientPtr who, OsCommPtr oc, const void *__extraBuf, int 
extraCount)
 794 {
 ...

 936 
 937 if (oco->size > BUFWATERMARK) {
 938 free(oco->buf);  <== here
 939 free(oco);
 940 }
 941 else {
 942 oco->next = FreeOutputs;
 943 FreeOutputs = oco;
 944 }

The most important change I see affecting this code is the "Switch server to 
poll" series, I am not sure how this can be related though.

Also, I don't see any change between xorg-server-20160929 and current git 
master, so chances are this is still affecting current git code.

Cheers,
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