[ANNOUNCE] xkbcomp 1.3.0

[Peter Hutterer]

In what is almost an olympic release schedule, here's a new version of
xkbcomp. Over the last two-and-a-bit years a number of patches have
accumulated, the most interesting one is support for multiple keysyms per
level (#25025).  I say "parsing support" for a reason, the symbol becomes a
NoSymbol, which is arguably still more useful than a parsing error. Plus,
multi-sym per key won't work in X anyway.

Other than that, misc fixes and changes all over the place. UNIXOS2 support
was dropped. Sorry guys, no multi-keysym parsing for you. I'll get a
bucket ready for the tears.

Adam Jackson (1):
  configure: Drop AM_MAINTAINER_MODE

Alan Coopersmith (10):
  unifdef -U__UNIXOS2__
  config: Add missing AC_CONFIG_SRCDIR
  Remove unused function entry/exit tracking framework
  Remove unused uASSERT macro
  Convert remaining sprintf calls to snprintf
  Fix many const char * warnings from gcc
  Remove useless checks for NULL before free in OverlayKeyCreate()
  Don't dereference the pointer whose allocation failed
  Remove useless assignment to 'outline' variable
  Initialize nMatch even if WIN32 is defined

Benno Schulenberg (1):
  Making sure that a copied string is always null-terminated (#66345).

Colin Walters (1):
  autogen.sh: Honor NOCONFIGURE=1

Daniel Stone (2):
  Add parsing support for multiple keysyms per level
  Reset scan state when opening a new file

Laura (1):
  Add #include  to xkbscan.c

Peter Hutterer (7):
  Use DEBUG, not DEBUG_ON to determine whether debugging is enabled
  man: document -help/-?, -em1, -emp, -eml
  Always terminate the scanBuf string (#66345)
  Parse -w1 flag correctly (#66344)
  compat: don't warn about redefinition when nothing is defined yet
  man: replace default include directory with the one from configure
  xkbcomp 1.3.0

Ryan Pavlik (1):
  Include Xwindows.h rather than windows.h

Thomas Klausner (1):
  Protect config.h like usual.

Vincent Lefevre (1):
  xkbcomp: Improved -w option parsing

git tag: xkbcomp-1.3.0

http://xorg.freedesktop.org/archive/individual/app/xkbcomp-1.3.0.tar.bz2
MD5:  0012a8e3092cddf7f87b250f96bb38c5  xkbcomp-1.3.0.tar.bz2
SHA1: 113c93679c9245141b5899240f59fcc8227d8dc1  xkbcomp-1.3.0.tar.bz2
SHA256: cfac973778fabf5216121ad60b7af8ab74ce7513af0f9260cf8c5309e1622b2a  
xkbcomp-1.3.0.tar.bz2
PGP:  
http://xorg.freedesktop.org/archive/individual/app/xkbcomp-1.3.0.tar.bz2.sig

http://xorg.freedesktop.org/archive/individual/app/xkbcomp-1.3.0.tar.gz
MD5:  f8da094e266e2f99316696fab4922d70  xkbcomp-1.3.0.tar.gz
SHA1: 32fffd47086a6d204ac842668a598af74d9c172a  xkbcomp-1.3.0.tar.gz
SHA256: 91d052c895a47ab2930aa1e150bfe7559fdaeb959d035634d5ba259300a3353f  
xkbcomp-1.3.0.tar.gz
PGP:  
http://xorg.freedesktop.org/archive/individual/app/xkbcomp-1.3.0.tar.gz.sig



pgpwk1inJpOv7.pgp
Description: PGP signature
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Graphics speed depends on user profile

[Glynn Clements]

Juan Pablo de la Cruz wrote:

> We have an library which directly uses the Xlib API to do graphics.
> 
> We are observing the following effect: when two different users log
> in the same machine, use the same window manager, and run the very same
> program, the graphics are slower (much) for one of the users.
> 
> Concretely, the user for which the drawing is slower, logs himself in,
> and the other user executes su $USER on the terminal.
> 
> Both use the exact same libraries (same PATH and LD_LIBRARY_PATH).
> Both use the same window manager.
> 
> What other settings/factors could explain this behaviour?

What are their $DISPLAY settings?

If $DISPLAY is ":0" then the client will connect to the X server via
the Unix-domain socket at /tmp/.X11-unix/X0. Whereas if $DISPLAY is
"localhost:0", it will connect to the X server via TCP port 6000.

The latter will result in the data stream being chopped up into
packets and passed through the kernel's TCP/IP stack: routing,
firewall rules, etc.

It may also prevent the use of features such as direct rendering, as
the client and server are likely to be deemed to reside on different
systems.

-- 
Glynn Clements 
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Graphics speed depends on user profile

[Juan Pablo de la Cruz]

Hello everyone,

We have an library which directly uses the Xlib API to do graphics.

We are observing the following effect: when two different users log
in the same machine, use the same window manager, and run the very same
program, the graphics are slower (much) for one of the users.

Concretely, the user for which the drawing is slower, logs himself in,
and the other user executes su $USER on the terminal.

Both use the exact same libraries (same PATH and LD_LIBRARY_PATH).
Both use the same window manager.

What other settings/factors could explain this behaviour?
Could you point me to some source/guide providing some helpful information?

Currently I am out of ideas.

Thanks and greetings,
Juan Pablo

-- 
Juan Pablo de la Cruz Gutierrez   c...@mvtec.com
MVTec Software GmbH | Neherstr. 1 | 81675 München  | Germany
www.mvtec.com | Tel: +49 89 457695-0 | Fax: +49 89 457695-55
Geschäftsführer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
Amtsgericht München HRB 114695
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

[PATCH] Xi/exevents : fix a issue that window can't be closed by touch the close window button

[Haibo Chen]

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

When matchbox-window-manger(Version 1.2) create a window, there is a
close window button on the top-right of this new window which seems
like "X". If we use a mouse, and click this "X" close window button,
the window can be closed. But when we use multi-touch screen, and
touch this "X" close window button, this window can't be closed, and
nothing changed on the screen. By the way, multi-touch can work normal
when we touch the window's other place except the "X" close button.
And both single touch and mouse can work normal, they can close the
window by touch/click the "X" close window button.

In Xorg(Version 1.16.1), mouse click event, single touch event, and
multi-touch event all call the below function to deliver the coming
event to the target window.

int
DeliverDeviceEvents(WindowPtr pWin, InternalEvent *event, GrabPtr grab,
WindowPtr stopAt, DeviceIntPtr dev)

If we use mouse or single touch to click/touch the "X" close window
button, function ProcessDeviceEvent() call the above function. When the
event->any.type=ET_ButtonPress, the pWin point to the "X" close window
button. The pWin is got by function GetSpriteWindow().

But if we use multi-touch to touch the "X" close window button, function
DeliverTouchEmulatedEvent() call DeliverDeviceEvents(). When the
event->any.type=ET_ButtonPress, the pWin does not point to the "X" close
window button, it actually point to the "X" close window button's parent
window. So in function DeliverDeviceEvents(), when call function
DeliverOneEvent(), the value child is zero, rather than the target window.

This patch use function GetSpriteWindow() to get the pWin in function
DeliverTouchEmulatedEvent() when call DeliverDeviceEvents().

With this patch, mouse, single touch, multi-touch all can work well, including
click/touch the "X" close window button.

Signed-off-by: Haibo Chen 
---
 Xi/exevents.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Xi/exevents.c b/Xi/exevents.c
index b0bc47e..e1c523e 100644
--- a/Xi/exevents.c
+++ b/Xi/exevents.c
@@ -1430,7 +1430,7 @@ DeliverTouchEmulatedEvent(DeviceIntPtr dev, 
TouchPointInfoPtr ti,
 else {
 GrabPtr devgrab = dev->deviceGrab.grab;
 
-DeliverDeviceEvents(win, ptrev, grab, win, dev);
+DeliverDeviceEvents(GetSpriteWindow(dev), ptrev, grab, win, dev);
 /* FIXME: bad hack
  * Implicit passive grab activated in response to this event. Store
  * the event.
-- 
1.9.1

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s