Re: [PATCH xim] modules/im/ximcp: Send display and screen number to XIM server

[Takao Fujiwara]

Hi,

Would you integrate the patch?

Fujiwara

On 02/18/17 12:22, Takao Fujiwara-san wrote:

Enables that client application sends its screen number to XIM server.
In ZaphodHeads environment, XIM server needs to know the screen
number to launch the lookup window in the right screen.
I think this way keeps the back compatibility.

Signed-off-by: Takao Fujiwara 
---
 modules/im/ximcp/imDefIm.c | 32 
 src/xlibi18n/XimProto.h|  2 +-
 2 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/modules/im/ximcp/imDefIm.c b/modules/im/ximcp/imDefIm.c
index 9e877c0..d0b8368 100644
--- a/modules/im/ximcp/imDefIm.c
+++ b/modules/im/ximcp/imDefIm.c
@@ -794,6 +794,35 @@ _XimOpenCheck(
 return False;
 }

+static INT16
+_XimSetDisplayNumber(
+Xim im,
+CARD8  *buf_b,
+INT16   len)
+{
+const char *display_string =  DisplayString(im->core.display);
+buf_b[len] = 0;
+buf_b[len+1] = 0;
+
+if (display_string && (display_string = strchr(display_string, ':')) != 
NULL) {
+   display_string++;
+   if (*display_string != '\0') {
+   int number = atoi(display_string);
+   buf_b[len] = (number < 0) ? 0 : (number % 256);
+   display_string++;
+   if ((display_string = strchr(display_string, '.')) != NULL) {
+   display_string++;
+   if (*display_string != '\0') {
+   number = atoi(display_string);
+   buf_b[len+1] = (number < 0) ? 0 : (number % 256);
+   }
+   }
+   }
+}
+
+return sizeof(CARD8) * 2;
+}
+
 static Bool
 _XimOpen(
 Xim im)
@@ -803,6 +832,7 @@ _XimOpen(
 CARD8  *buf_b = [XIM_HEADER_SIZE];
 CARD16 *buf_s;
 INT16   len;
+INT16   version_len;
 CARD32  reply32[BUFSIZE/4];
 char   *reply = (char *)reply32;
 XPointerpreply;
@@ -816,6 +846,8 @@ _XimOpen(
 (void)strcpy((char *)_b[1], locale_name);  /* locale name */
 len += sizeof(BYTE);  /* sizeof length */
 XIM_SET_PAD(buf_b, len);  /* pad */
+version_len = _XimSetDisplayNumber(im, buf_b, len);
+len += (version_len + XIM_PAD(version_len));

 _XimSetHeader((XPointer)buf, XIM_OPEN, 0, );
 if (!(_XimWrite(im, len, (XPointer)buf)))
diff --git a/src/xlibi18n/XimProto.h b/src/xlibi18n/XimProto.h
index 6b0096d..881f975 100644
--- a/src/xlibi18n/XimProto.h
+++ b/src/xlibi18n/XimProto.h
@@ -47,7 +47,7 @@ PERFORMANCE OF THIS SOFTWARE.
  * Xim implementation revision
  */
 #define PROTOCOLMAJORVERSION   1
-#define PROTOCOLMINORVERSION   0
+#define PROTOCOLMINORVERSION   1

 /*
  * Major Protocol number



___
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: xorg-server-1.18.x and xorg-server-1.19.x: xf86Config.c / auto_gpu_device=1 failed to configure my Radeon 280X (commit: 69e4b8e602ecc7b69c75988a447ec5b509b22402)

[Michel Dänzer]

On 13/03/17 09:48 PM, wal...@free.fr wrote:
> Here is below the test Xorg configuration (tst.conf). I just checked
> that removing sections related to other devices, and using only the
> sections related to the target device as a simple 'skeleton' fixes
> the issue too. But this last method is not what we want (I hope so).

Is there any particular issue with that? (Don't expect me to look
through that configuration in detail :) If so, does adding

Option  "AutoAddGPU""off"

to Section "ServerFlags" help?


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
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] render: Fix out of boundary heap access

[Adam Jackson]

On Mon, 2017-03-13 at 19:13 +0100, Tobias Stoeckmann wrote:
> ProcRenderCreateRadialGradient and ProcRenderCreateConicalGradient must
> be protected against an integer overflow during length check. This is
> already included in ProcRenderCreateLinearGradient since the fix for
> CVE-2008-2362.
> 
> This can only be successfully exploited on a 32 bit system for an
> out of boundary read later on. Validated by using ASAN.

remote: I: patch #143811 updated using rev 
ac15d4cecca377c5c31ab852c39bbd554ca48fe2.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   0c1574d..ac15d4c  master -> master

- 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

[PATCH libXaw] NULL pointer dereference in XawAsciiSinkInitialize

[Tobias Stoeckmann]

The function XawAsciiSinkInitialize is prone to a NULL pointer
dereference if no font is available.

Even though a specific check for a NULL font exists, it is called
after GetGC(), which in turn would trigger the NPE in such a case.

Spotted by calling xmessage on a system with an incomplete x font setup:

$ xmessage -b text
Warning: Unable to load any usable ISO8859 font
Segmentation fault
$ _

Signed-off-by: Tobias Stoeckmann 
---
 src/AsciiSink.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/AsciiSink.c b/src/AsciiSink.c
index d776895..1cccb1c 100644
--- a/src/AsciiSink.c
+++ b/src/AsciiSink.c
@@ -1704,10 +1704,10 @@ XawAsciiSinkInitialize(Widget request, Widget cnew,
 {
 AsciiSinkObject sink = (AsciiSinkObject)cnew;
 
-GetGC(sink);
-
 if (!sink->ascii_sink.font) XtError("Aborting: no font found\n");
 
+GetGC(sink);
+
 sink->ascii_sink.cursor_position = 0;
 sink->ascii_sink.laststate = XawisOff;
 sink->ascii_sink.cursor_x = sink->ascii_sink.cursor_y = 0;
-- 
2.12.0

___
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

[PATCH] render: Fix out of boundary heap access

[Tobias Stoeckmann]

ProcRenderCreateRadialGradient and ProcRenderCreateConicalGradient must
be protected against an integer overflow during length check. This is
already included in ProcRenderCreateLinearGradient since the fix for
CVE-2008-2362.

This can only be successfully exploited on a 32 bit system for an
out of boundary read later on. Validated by using ASAN.
---
 render/render.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/render/render.c b/render/render.c
index 8dc1f3425..ccae49a41 100644
--- a/render/render.c
+++ b/render/render.c
@@ -1908,6 +1908,8 @@ ProcRenderCreateRadialGradient(ClientPtr client)
 LEGAL_NEW_RESOURCE(stuff->pid, client);
 
 len = (client->req_len << 2) - sizeof(xRenderCreateRadialGradientReq);
+if (stuff->nStops > UINT32_MAX / (sizeof(xFixed) + sizeof(xRenderColor)))
+return BadLength;
 if (len != stuff->nStops * (sizeof(xFixed) + sizeof(xRenderColor)))
 return BadLength;
 
@@ -1946,6 +1948,8 @@ ProcRenderCreateConicalGradient(ClientPtr client)
 LEGAL_NEW_RESOURCE(stuff->pid, client);
 
 len = (client->req_len << 2) - sizeof(xRenderCreateConicalGradientReq);
+if (stuff->nStops > UINT32_MAX / (sizeof(xFixed) + sizeof(xRenderColor)))
+return BadLength;
 if (len != stuff->nStops * (sizeof(xFixed) + sizeof(xRenderColor)))
 return BadLength;
 
-- 
2.12.0

___
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] sdksyms: Tighten up the symbols we add to the magic table

[Adam Jackson]

On Fri, 2017-03-10 at 23:23 +, Emil Velikov wrote:
> > On 10 March 2017 at 16:32, Adam Jackson  wrote:
> > I neither expect nor want this to happen. dummy might have some minor
> > utility, but the nested driver I think is a mistake, and I would not
> > consider its availability as a reason to drop Xnest or Xephyr.
> > 
> 
> Pardon the silly question, but going through the discussions did now help 
> much.
> Do we have a list of features/bugs for/against each suggestion ?

I don't know what you mean by "each suggestion".

> I mean if there is somethings clearly defined, divide and conquer is the way.
> Atm everything seems quite magical, unless one has extensive prior
> experience with the DDXen and respective drivers.

I don't know what you mean by "everything".

- 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: xorg-server-1.18.x and xorg-server-1.19.x: xf86Config.c / auto_gpu_device=1 failed to configure my Radeon 280X (commit: 69e4b8e602ecc7b69c75988a447ec5b509b22402)

[wallak]

Here is below the test Xorg configuration (tst.conf). I just checked that 
removing sections related to other devices, and using only the sections related 
to the target device as a simple 'skeleton' fixes the issue too. But this last 
method is not what we want (I hope so). The logs with or without the patch are 
given too.

tst.conf: http://pastebin.com/SXptHZCh
unpatched.log: http://pastebin.com/kEm1LJ8Z
patched.log: http://pastebin.com/wtWc4Ymx

Wallak.



- Mail original -
De: "Michel Dänzer" 
À: wal...@free.fr
Cc: xorg-devel@lists.x.org
Envoyé: Lundi 13 Mars 2017 03:24:16
Objet: Re: xorg-server-1.18.x and xorg-server-1.19.x: xf86Config.c / 
auto_gpu_device=1 failed to configure my Radeon 280X (commit: 
69e4b8e602ecc7b69c75988a447ec5b509b22402)

On 13/03/17 07:50 AM, wal...@free.fr wrote:
> My radeon 280X was working properly while I was using
> xorg-server-1.17.x. I was unable to get this board working with
> xorg-server-1.18.x and xorg-server-1.19.x. Using the last xorg-server
> release the software was trying to configure a non connected video
> port (displayport) and failed; xorg.conf was configured to discard
> the non-connected video ports. This was necessary for the OpenGL
> layer to work on the main screen.

That's a bit vague.

Please provide the Xorg log and xorg.conf files corresponding to any
issues you're hitting.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
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

[PATCH xdriinfo] Fix xdriinfo not working with glvnd

[Hans de Goede]

For glx calls to work on libglvnd as glx provider we must first call
glXGetClientString. This also means that we can no longer take the
shortcut to not open the Display when a driver name is past to options.

Signed-off-by: Hans de Goede 
---
 xdriinfo.c | 29 -
 1 file changed, 12 insertions(+), 17 deletions(-)

diff --git a/xdriinfo.c b/xdriinfo.c
index c23cfa1..c7e7482 100644
--- a/xdriinfo.c
+++ b/xdriinfo.c
@@ -112,23 +112,9 @@ int main (int argc, char *argv[]) {
return 1;
}
 }
-  /* if the argument to the options command is a driver name, we can handle
-   * it without opening an X connection */
-if (func == OPTIONS && screenNum == -1) {
-   const char *options = (*GetDriverConfig) (funcArg);
-   if (!options) {
-   fprintf (stderr,
-"Driver \"%s\" is not installed or does not support 
configuration.\n",
-funcArg);
-   return 1;
-   }
-   printf ("%s", options);
-   if (isatty (STDOUT_FILENO))
-   printf ("\n");
-   return 0;
-} 
+
   /* driver command needs a valid screen number */
-else if (func == DRIVER && screenNum == -1) {
+if (func == DRIVER && screenNum == -1) {
fprintf (stderr, "Invalid screen number \"%s\".\n", funcArg);
return 1;
 }
@@ -146,6 +132,9 @@ int main (int argc, char *argv[]) {
return 1;
 }
 
+   /* Call glXGetClientString to load vendor libs on glvnd enabled systems */
+glXGetClientString (dpy, GLX_EXTENSIONS);
+
 switch (func) {
   case NSCREENS:
printf ("%d", nScreens);
@@ -165,7 +154,13 @@ int main (int argc, char *argv[]) {
  break;
   }
   case OPTIONS: {
- const char *name = (*GetScreenDriver) (dpy, screenNum), *options;
+ const char *name, *options;
+ 
+ if (screenNum == -1) {
+ name = funcArg;
+ } else {
+ name = (*GetScreenDriver) (dpy, screenNum);
+ }
  if (!name) {
  fprintf (stderr, "Screen \"%d\" is not direct rendering 
capable.\n",
   screenNum);
-- 
2.9.3

___
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

xwayland pull request for 1.19 branch

[Olivier Fourdan]

Hi,

I have cherry-picked a couple of fixes for Xwayland for the server-1.19-branch.

_Important_: I squashed two commits from upstream for 1.19, namely:

  64ca14b xwayland: make sure client is not gone in sync callback
  937527f xwayland: Monitor client states to destroy callbacks

I used "cherry-pick -x" and kept the original commit from the the best fix in 
the squash commit message, i.e. 937527f.

I hope this is OK (I reckon it makes sense for the stable branch to get the 
right code in one go).

Anyway, *if* this is OK, here follows a pull request:

The following changes since commit db1326cd6625747e4036e6cdc75bc7a0e1b0426b:

  present: disable page flip only when a slave crtc is active (2017-03-10 
11:05:36 -0500)

are available in the git repository at:

  git://people.freedesktop.org/~ofourdan/xserver xwayland-1.19-branch

for you to fetch changes up to 18fcb66688057f5676952e2535d4bb9942371199:

  xwayland: Monitor client states to destroy callbacks (2017-03-13 09:56:24 
+0100)


Olivier Fourdan (2):
  xwayland: clear cursor frame callback
  xwayland: Monitor client states to destroy callbacks

 hw/xwayland/xwayland-cursor.c | 14 --
 hw/xwayland/xwayland-glamor.c | 60 

 2 files changed, 64 insertions(+), 10 deletions(-)

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

[PATCH xf86-input-libinput] Support for rel+abs composite devices on the same node

[Gergely Nagy]

Largely based on work by Peter Hutterer, this patch makes composite relative +
absolute devices work with the driver. Such devices are anything that presents
itself as both a mouse, and - for example - a touch screen, like the Keyboardio
Model 01 (or anything that uses Nico Hood's HID library for Arduino).

If a device has both capabilities present, we split them into two separate
devices for X (see xf86libinput_pre_init()), like we do with the composite
keyboard + mouse devices. Then, we route absolute events to the absolute
subdevice (see xf86libinput_pick_device()). The rest of the patch is mostly
small updates to support the newly introduced CAP_POINTER_ABSOLUTE flag.

There's one missing thing, however: event routing for buttons. At the moment,
button routing is simply not done, but in practice, this does not seem to have
any ill side effects.

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

Signed-off-by: Gergely Nagy 
---
 src/xf86libinput.c | 81 ++
 1 file changed, 58 insertions(+), 23 deletions(-)

diff --git a/src/xf86libinput.c b/src/xf86libinput.c
index 888c8f2..a099c5b 100644
--- a/src/xf86libinput.c
+++ b/src/xf86libinput.c
@@ -87,6 +87,7 @@
 #define CAP_TABLET 0x8
 #define CAP_TABLET_TOOL0x10
 #define CAP_TABLET_PAD 0x20
+#define CAP_POINTER_ABSOLUTE   0x40
 
 struct xf86libinput_driver {
struct libinput *libinput;
@@ -805,6 +806,20 @@ xf86libinput_init_pointer_absolute(InputInfoPtr pInfo)
Atom btnlabels[MAX_BUTTONS];
Atom axislabels[TOUCHPAD_NUM_AXES];
 
+   /* We always initialize rel as parent on absrel devices */
+   if (xf86libinput_is_subdevice(pInfo)) {
+   /*
+* FIXME: well, we can't really know which buttons belong to
+* which device here, but adding it to both doesn't make
+* sense either. Options are: assume LMR is on rel, BTN_0
+* and friends on absolute. That's not always correct but
+* that's as best as we can do.
+*
+* FIXME: event routing for buttons isn't set up correctly
+* yet.
+*/
+   }
+
for (i = BTN_BACK; i >= BTN_SIDE; i--) {
if (libinput_device_pointer_has_button(device, i)) {
nbuttons += i - BTN_SIDE + 1;
@@ -1179,13 +1194,10 @@ xf86libinput_init(DeviceIntPtr dev)
 
if (driver_data->capabilities & CAP_KEYBOARD)
xf86libinput_init_keyboard(pInfo);
-   if (driver_data->capabilities & CAP_POINTER) {
-   if (libinput_device_config_calibration_has_matrix(device) &&
-   !libinput_device_config_accel_is_available(device))
-   xf86libinput_init_pointer_absolute(pInfo);
-   else
-   xf86libinput_init_pointer(pInfo);
-   }
+   if (driver_data->capabilities & CAP_POINTER)
+   xf86libinput_init_pointer(pInfo);
+   if (driver_data->capabilities & CAP_POINTER_ABSOLUTE)
+   xf86libinput_init_pointer_absolute(pInfo);
if (driver_data->capabilities & CAP_TOUCH)
xf86libinput_init_touch(pInfo);
if (driver_data->capabilities & CAP_TABLET_TOOL)
@@ -1347,7 +1359,7 @@ xf86libinput_handle_absmotion(InputInfoPtr pInfo, struct 
libinput_event_pointer
return;
}
 
-   if ((driver_data->capabilities & CAP_POINTER) == 0)
+   if ((driver_data->capabilities & CAP_POINTER_ABSOLUTE) == 0)
return;
 
x = libinput_event_pointer_get_absolute_x_transformed(event, 
TOUCH_AXIS_MAX);
@@ -1368,7 +1380,7 @@ xf86libinput_handle_button(InputInfoPtr pInfo, struct 
libinput_event_pointer *ev
int button;
int is_press;
 
-   if ((driver_data->capabilities & CAP_POINTER) == 0)
+   if ((driver_data->capabilities & (CAP_POINTER|CAP_POINTER_ABSOLUTE)) == 
0)
return;
 
button = btn_linux2xorg(libinput_event_pointer_get_button(event));
@@ -1493,7 +1505,7 @@ xf86libinput_handle_axis(InputInfoPtr pInfo, struct 
libinput_event_pointer *even
double value;
enum libinput_pointer_axis_source source;
 
-   if ((driver_data->capabilities & CAP_POINTER) == 0)
+   if ((driver_data->capabilities & (CAP_POINTER|CAP_POINTER_ABSOLUTE)) == 
0)
return;
 
valuator_mask_zero(mask);
@@ -1600,6 +1612,9 @@ xf86libinput_pick_device(struct xf86libinput_device 
*shared_device,
case LIBINPUT_EVENT_TABLET_TOOL_TIP:
needed_cap = CAP_TABLET_TOOL;
break;
+   case LIBINPUT_EVENT_POINTER_MOTION_ABSOLUTE:
+   needed_cap = CAP_POINTER_ABSOLUTE;
+   break;
default:
needed_cap = ~CAP_KEYBOARD;
break;
@@ -2940,7 +2955,7 @@ xf86libinput_get_type_name(struct libinput_device *device,
/* now