Mark Lybarger | 21 Jul 16:45 2014
Picon

modify application list

i'd like to modify the application list that displays when i right
click on the Xorg item on the system tray.  i want to add some more
applications to the list.  how do i modify the list?

thanks,
-mark-

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

Jon TURNEY | 21 Jul 16:21 2014
Picon

[ANNOUNCEMENT] Updated: xorg-server-1.15.1-4


The following packages have been updated in the Cygwin distribution:

*** xorg-server-*1.15.1-4

These packages contain XWin and the other X.Org X11 servers.

The following cygwin-specific changes have been made since 1.15.1-3:

* Give the window opened by "View logfile" a better title
* Fix bugs in WGL GLX which prevented pbuffers from being created with 
certain fbconfigs
* Improve the check that window position is visible to work correctly 
for non-rectangular virtual desktops
* Downgrade the "forcing window to exist" log message from error to debug
* Some compilation warning fixes
* Remove an incorrect assertion in WGL GLX, triggered by 
glXSwapBuffers() in the piglit glx_make_current test

x86:
1860dde6aac061b0dfdda6f6d8058914 *xorg-server-1.15.1-4-src.tar.xz
9d0a0d8ec0489f2c82e6b3def4c4515a *xorg-server-1.15.1-4.tar.xz
1997c143d62cc3200a50a9c3dceb6e8b *xorg-server-common-1.15.1-4.tar.xz
185301523810734629a44b14c964551a *xorg-server-debuginfo-1.15.1-4.tar.xz
a6dd1aa066b982a0c569ffda02e1a5d7 *xorg-server-devel-1.15.1-4.tar.xz
1da132c818d94b65876d6efffa2ffc1e *xorg-server-dmx-1.15.1-4.tar.xz
dbcd9b591a283d2ae94ca45c73625f20 *xorg-server-extra-1.15.1-4.tar.xz
3c03a460a456018511643f4631996ece *xwinclip-1.15.1-4.tar.xz

x86_64:
(Continue reading)

Matt D. | 21 Jul 03:06 2014

xinit hangs on XWin infinite loop when using -displayfd

The operating system is Windows XP Professional. It is a CLEAN install 
on a VMware virtual machine and is 100% patched up. Cygwin also is a 
clean install. I did try a rebaseall with no effect.

This is the first time I've encountered this. When I run "xinit -- 
-displayfd 3", xinit will hang and XWin takes up 100% of the cpu.

I've confirmed that file descriptors are working:

$ exec 3>a
$ echo "test" >&3
$ cat a
test
$ exec 3>&-

I can confirm that ports are available and that both xinit and XWin work 
without this argument by running:

$ xinit --

Everything else works fine but without "-displayfd" I can't record where 
the display is for this session to disk.

I've also tried copying known-working Cygwin installs into the VM and 
still have the same error. Copying the erroring install from the VM 
outside and running it on my development machine (Windows 7 x64) does 
not generate an error.

Unless something stands out here, I can provide the VMware image for 
testing (how convenient).
(Continue reading)

Michael DePaulo | 4 Jul 09:16 2014
Picon

How do fonts work when you have no font packages installed?

I tried to send this email previously, but I think it did not go
through because I was not subscribed to the list yet.
--------

Hi,

I just installed cygwin64 with only the base packages, "xorg-server",
and its dependencies installed.

The FAQ (2014-04-29) states:
3.5. My favourite font has gone! The font Emacs uses is just boxes
Only minimal fonts will be installed after the upgrade.

However, on my system, /usr/share/fonts/ is empty.

Yet I am able to XDMCP into a GNOME2 CentOS 6.5 machine and all the
fonts show up fine with the handful of apps I tested.

Can someone explain how text is being rendered? Is Cygwin Xwin using
fonts from the Windows OS? Are the fonts being rendered client-side via XRender?

Thanks in advance,
-Mike

mike <at> executor /usr
$ uname -a
CYGWIN_NT-6.3 executor 1.7.30(0.272/5/3) 2014-05-23 10:36 x86_64 Cygwin

mike <at> executor /usr
$ find . | grep fonts
(Continue reading)

Matt D. | 4 Jul 00:46 2014

Wine creating windows offscreen when "multiwindow" is used?

I have a monitor configuration with three 1920x1080 monitors aligned 
side-by-side horizontally with a fourth above the center. The primary 
monitor is the center one at the bottom. xinit generates a single screen 
5760x2160 to cover the area. The root window is hidden and all windows 
in the buffer are drawn with native Windows decorations.

When an X window is created at 0,0, it is visible on the primary 
monitor, despite 0,0 in the buffer being offscreen. This is great. 
However, when Wine creates a window at 0,0, it is aligned to 0,0 in the 
buffer (-1920x-1080 screen coordinates on Windows) and is not visible.

Is there a solution for this? This is a discrepancy between what regular 
X windows do and where Wine positions its windows.

I also noticed that when creating a window with XCreateSimpleWindow, the 
x and y coordinates are ignored. For example, I would expect a window 
created at 0,0 in the X buffer to be visible at 0,0 screen coordinates; 
but instead it's just somewhere offset slightly from the top left of the 
primary monitor. Any x/y coordinates specified do not seem to affect 
where it goes.

The behavior I would expect is for 0,0 in the buffer to be mapped to 0,0 
in screen coordinates, 1920x, 1080y in my configuration.

To clarify my use of Wine, I connected to a remote CentOS 6.5 machine 
via ssh with x forwarding for testing.

Can anyone provide some insight on this?

Matt D.
(Continue reading)

Yaakov Selkowitz | 23 Jun 21:55 2014

[ANNOUNCEMENT] Updated: xterm-308-1

The following package has been updated in the Cygwin distribution:

*** xterm-308-1

The xterm program is a terminal emulator for the X Window System. It 
provides DEC VT102 and Tektronix 4014 compatible terminals for programs 
that can't use the window system directly.

This is an update to the latest upstream release.

--

Yaakov
Cygwin/X

CYGWIN-XFREE-ANNOUNCE UNSUBSCRIBE INFO
======================================

If you want to unsubscribe from the cygwin-xfree-announce mailing list,
please use the automated form at:

http://cygwin.com/lists.html#subscribe-unsubscribe

If this does not work, then look at the "List-Unsubscribe: " tag in the
email header of this message.  Send email to the address specified
there.  It will be in the format:

cygwin-xfree-announce-unsubscribe-you=yourdomain.com <at> cygwin.com

If you need more information on unsubscribing, start reading here:
(Continue reading)

Yaakov Selkowitz | 23 Jun 21:55 2014

[ANNOUNCEMENT] Updated: qt3-3.3.8b-14

The following packages have been updated for Cygwin 1.7:

*** libqt3-3.3.8b-14
*** libqt3-devel-3.3.8b-14
*** qt3-devel-tools-3.3.8b-14
*** qt3-doc-3.3.8b-14
*** qt3-qtconfig-3.3.8b-14

This is the old 3.x version of the Qt C++ application framework, for the 
benefit of those programs which have yet to be ported to the currently 
supported versions of Qt.

This release includes patches for CVE-2013-4549 and CVE-2014-0190.  A 
full debuginfo package is now available.

Yaakov
Cygwin/X

CYGWIN-XFREE-ANNOUNCE UNSUBSCRIBE INFO
======================================

If you want to unsubscribe from the cygwin-xfree-announce mailing list, 
please use the automated form at:

http://cygwin.com/lists.html#subscribe-unsubscribe

If this does not work, then look at the "List-Unsubscribe: " tag in the
email header of this message.  Send email to the address specified
there.  It will be in the format:

(Continue reading)

Jon TURNEY | 19 Jun 23:19 2014
Picon

[ANNOUNCEMENT] Updated: xorg-server-1.15.1-3


The following packages have been updated in the Cygwin distribution:

*** xorg-server-*1.15.1-3

These packages contain XWin and the other X.Org X11 servers.

The following cygwin-specific changes have been made since 1.15.1-2:

* A cosmetic fix to version reporting on x86_64
* Improve visual matching with a remote libGL by not reporting pbuffer 
size limits
* Log counts of WGL pixel formats which couldn't be used for various reasons
* Correctly interpret WM_HINTS, WM_NORMAL_HINTS properties on x86_64
* Ignore any WM_NORMAL_HINTS PPosition if it specifies the origin
* Fix building with khronos-opengl-registry since 2013-08-16 by limiting 
the considered features for shim generation to GL version <=1.2

x86:
f7857118deebe18a89fa6093f3f03837 *xorg-server-1.15.1-3-src.tar.xz
22f4a00a84ad9f48d0ee78a6a2974f1f *xorg-server-1.15.1-3.tar.xz
a34e20b0aa50d4ab2aea75d2e23a2691 *xorg-server-common-1.15.1-3.tar.xz
9a0a43e8a07ca545b7c6e4cdb8f38bc8 *xorg-server-debuginfo-1.15.1-3.tar.xz
ef95370bd6b61ab030798a4735cca3e0 *xorg-server-devel-1.15.1-3.tar.xz
ac17ded0743fcdb2b491e7ce80675f51 *xorg-server-dmx-1.15.1-3.tar.xz
1e84c4811bee5563e8b6d72259425d6d *xorg-server-extra-1.15.1-3.tar.xz
08b1f7971b7b4ac230258c2c9fd24145 *xwinclip-1.15.1-3.tar.xz

x86_64:
cdde770c4ca8f389f79939d0065a3293 *xorg-server-1.15.1-3-src.tar.xz
(Continue reading)

Oliver Schmidt | 19 Jun 14:22 2014
Picon
Picon

problem evaluating window resize hints under 64 bit

The current cygwin x server 1.15.1-2 under 64-bit cygwin seems to have a problem correctly evaluating the
window resize 
hints.

In hw/xwin/winmultiwindowwndproc.c the function ValidateSizing calls
winMultiWindowGetWMNormalHints and gets wrong 
values in sizeHints.width_inc and sizeHints.height_inc.

In function winMultiWindowGetWMNormalHints in file hw/xwin/winmultiwindowclass.c you can see that a
memcpy occurs from 
prop->data with sizeof(WinXSizeHints).

As it turns out, everything is correct if you modify the typedef of WinXSizeHints in
hw/xwin/winmultiwindowclass.h so 
that long type becomes int:

--- a/cygwin/hw/xwin/winmultiwindowclass.h
+++ b/cygwin/hw/xwin/winmultiwindowclass.h
 <at>  <at>  -63,7 +63,7  <at>  <at>  typedef struct {
   * used with WM_NORMAL_HINTS.
   */
  typedef struct {
-    long flags;                 /* marks which fields in this structure are defined */
+    int flags;                 /* marks which fields in this structure are defined */
      int x, y;                   /* obsolete for new window mgrs, but clients */
      int width, height;          /* should set so old wm's don't mess up */

I can only guess why this works: in the X11 message protocol all int and long types are mapped to 32 bit
integers. It 
seems that the memcpy in winMultiWindowGetWMNormalHints has source data that has memory layout as in the
(Continue reading)

Jon TURNEY | 13 Jun 00:54 2014
Picon

Re: compiling xwin 1.15.1-2

On 12/06/2014 22:49, J. Offerman wrote:
> Can you help me resolve this compile error that I'm seeing now? Thanks.

Please use the mailing list for these kinds of questions.

> ===================================================
> In file included from
> /usr/src/xorg-server-1.15.1-2/src/xserver-cygwin-1.15.1-2/hw/xwin/glx/glthunk.c:87:0:
> ./generated_gl_thunks.c: In function 'glTexturePageCommitmentEXTWrapper':
> ./generated_gl_thunks.c:10560:3: error: too many arguments to function
> 'proc'
>     RESOLVED_PROC(PFNGLTEXTUREPAGECOMMITMENTEXTPROC)( texture_, target_,
> level_, xoffset_, yoffset_, zoffset_, width_, height_, depth_, resident_ );

Thanks for drawing this to my attention.

This fails because the description of glTexturePageCommitmentEXT() in 
/usr/share/opengl/api/gl.xml from (khronos-opengl-registry) needs to 
match it's prototype in /usr/include/w32api/GL/glext.h (from w32api-headers)

There was an upstream bug where an extra 'target' parameter was 
erroneously added.  The latest w32api-headers have updated GL headers 
that have that fixed, but it seems I haven't updated khronos-opengl-registry

Until I make an updated package, you'll have to fix gl.xml yourself, 
like this:

--- gl.xml~     2013-08-08 18:07:23.000000000 +0100
+++ gl.xml      2014-05-02 17:35:52.000120700 +0100
 <at>  <at>  -22968,7 +22968,6  <at>  <at> 
(Continue reading)

Patrick Herbst | 11 Jun 22:50 2014
Picon

Re: XRaiseWindow for activating windows in multiwindow mode

On 03 Sep 2011, Jon TURNEY wrote:
>
> On 13/08/2011 19:39, Oliver Schmidt wrote:
> > as reported in
> >
> >    http://www.cygwin.com/ml/cygwin-xfree/2005-06/msg00072.html
> >
> > windows are not raised from the Cygwin X Server in multiwindow
> > mode, if a program wants to programmatically activate a window.
> >
> > I played around and figured out that the problem can be solved by
> > invoking the windows function SetForegroundWindow if a top level
> > window is to be restacked and has no previous sibling.
> >
> > I enclose the patch in this email. It works fine for me, but
> > I'm not sure if it has any side effects for other configurations
> > or usage patterns.
>
> Thanks for looking into this, and for the patch.
>
> There definitely are some problems in this area, but I'm not sure this is the
> 'correct' fix, though.
>
> The code as it stands is the product of some ... erm ... historical compromises.
>
> If I am reading the code correctly, it looks like currently no attempt is made
> to synchronize changes in the X window Z-order (e.g. made by XRaiseWindow())
> to the native Windows window Z-order, and the comment in [1] seems to bear
> this out.  The code which perhaps would do this is in the disabled branch of
> the #if/#else/#endif in winRestackWindowMultiWindow()
(Continue reading)


Gmane