Re: xterm crashing when trying to access Ctrl- menu items

[Nem W Schlecht]

Thanks for the reply, Jon!  I'm happy you were able to reproduce the
issue - I assumed I had screwed something up in my environment. :)

Your attempted fix with rebase worked perfectly - all of my menus are
now working correctly.  If you'd like me to do any additional testing
in the future, don't hesitate to ask.

On Mon, May 12, 2014 at 5:34 AM, Jon TURNEY  wrote:
> On 05/05/2014 19:39, Nem W Schlecht wrote:
>>
>> For over a month now I've been having issues with my xterms in Cygwin.
>>   If I try to access *any* menu item under the Ctrl- menu
>> items (change font, turn on/off scrollbar, redraw window, etc.), my
>> xterm crashes the moment I un-press my mouse button.  I don't access
>> them all that often, so I don't know how long the issue has been
>> around, but it's been a couple of months now.
>>
>> I've tried launching it with an empty .Xdefaults file (home dir) and
>> by moving my .bashrc/.bash_profile files out of the way - still the
>> same result.  I've also gone out and downloaded the latest XTerm code
>> and have a version compiled with debugging, but my C skills are really
>> rusty and I'm not seeing anything terribly useful in gdb (I set my
>> CYGWIN env var to "error_start=dumper -d %1 %2" so I would get core
>> dumps).  I compiled a version with a different "DEFCLASS" set so that
>> I *know* it's not a bad resource or resource file.
>>
>> I'm running 64 bit on Windows 7.  More details in the attached
>> cygcheck.out.
>>
>> Anybody else on 64bit Cygwin / Win 7 having the same issues?
>
>
> Thanks for reporting this issue.  I can reproduce it.
>
> This appears to be an issue with Xt, as a Cygwin-specific patch does not
> work correctly on x86_64 when another DLL which is using Xt is loaded >2GB
> away from it.
>
> Until we have a fix, you *might* be able to work around this by rebasing the
> DLLs, e.g. in the specific case of xterm, which uses Xaw:
>
> cd /usr/bin
> rebase -v -b 0x4 cygXt-6.dll
> rebase -v -b 0x41000 cygXaw-7.dll
>
> --
> Jon TURNEY
> Volunteer Cygwin/X X Server maintainer



-- 
Nem W Schlecht   n...@emptec.com
Empyreal Technologieshttp://www.emptec.com/
 "Perl did the magic.  I just waved the wand."

--
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/

Re: xterm crashing when trying to access Ctrl- menu items

[Jon TURNEY]

On 05/05/2014 19:39, Nem W Schlecht wrote:

For over a month now I've been having issues with my xterms in Cygwin.
  If I try to access *any* menu item under the Ctrl- menu
items (change font, turn on/off scrollbar, redraw window, etc.), my
xterm crashes the moment I un-press my mouse button.  I don't access
them all that often, so I don't know how long the issue has been
around, but it's been a couple of months now.

I've tried launching it with an empty .Xdefaults file (home dir) and
by moving my .bashrc/.bash_profile files out of the way - still the
same result.  I've also gone out and downloaded the latest XTerm code
and have a version compiled with debugging, but my C skills are really
rusty and I'm not seeing anything terribly useful in gdb (I set my
CYGWIN env var to "error_start=dumper -d %1 %2" so I would get core
dumps).  I compiled a version with a different "DEFCLASS" set so that
I *know* it's not a bad resource or resource file.

I'm running 64 bit on Windows 7.  More details in the attached cygcheck.out.

Anybody else on 64bit Cygwin / Win 7 having the same issues?


Thanks for reporting this issue.  I can reproduce it.

This appears to be an issue with Xt, as a Cygwin-specific patch does not 
work correctly on x86_64 when another DLL which is using Xt is loaded 
>2GB away from it.


Until we have a fix, you *might* be able to work around this by rebasing 
the DLLs, e.g. in the specific case of xterm, which uses Xaw:


cd /usr/bin
rebase -v -b 0x4 cygXt-6.dll
rebase -v -b 0x41000 cygXaw-7.dll

--
Jon TURNEY
Volunteer Cygwin/X X Server maintainer

--
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/

Re: xterm title setting breaks when upgrading from 32-bit to 64-bit cygwin

[Jeremy Elson]

On Thu, Aug 1, 2013 at 10:28 AM, Jon TURNEY  wrote:
> On 01/08/2013 01:55, Jeremy Elson wrote:
> > I recently upgraded from the 32-bit to the 64-bit build of Cygwin
> > 1.7.22 on Windows 8 x64. For the most part, everything works
> > identically (except faster!). But I have noticed one problem: xterm no
> > longer seems to respond to the magic escape codes that change its
> > title. My shell uses this to update the title to reflect the current
> > hostname and working directory, but after the upgrade all my xterms
> > just have the same title: "tcsh".
> >
> > I haven't seen any mention of this bug on the mailing lists. Is anyone
> > else experiencing this problem?
>
> Thanks for pointing out this problem.
>
> It seems that x86_64 X server has a bug that meant that no window could
> change
> it's title after it started.
>
> I've uploaded a snapshot at [1]. Perhaps you could try that and see if it
> improves things for you?
>
> [1]
> ftp://cygwin.com/pub/cygwinx/XWin.x86_64.20130801-git-beadc5a3202e096a.exe.bz2
>

Thanks for the very fast followup - yes, using the XWin binary below, my xterm
can now set its title correctly!

Thanks again, and regards,
Jeremy

--
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/

Re: xterm title setting breaks when upgrading from 32-bit to 64-bit cygwin

[Jon TURNEY]

On 01/08/2013 01:55, Jeremy Elson wrote:
> I recently upgraded from the 32-bit to the 64-bit build of Cygwin
> 1.7.22 on Windows 8 x64. For the most part, everything works
> identically (except faster!). But I have noticed one problem: xterm no
> longer seems to respond to the magic escape codes that change its
> title. My shell uses this to update the title to reflect the current
> hostname and working directory, but after the upgrade all my xterms
> just have the same title: "tcsh".
> 
> I haven't seen any mention of this bug on the mailing lists. Is anyone
> else experiencing this problem?

Thanks for pointing out this problem.

It seems that x86_64 X server has a bug that meant that no window could change
it's title after it started.

I've uploaded a snapshot at [1]. Perhaps you could try that and see if it
improves things for you?

[1] 
ftp://cygwin.com/pub/cygwinx/XWin.x86_64.20130801-git-beadc5a3202e096a.exe.bz2

-- 
Jon TURNEY
Volunteer Cygwin/X X Server maintainer

--
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/

Re: xterm and font problems after last update

[marco atzeri]

On 2/11/2013 12:42 PM, Thomas Dickey wrote:

On Mon, Feb 11, 2013 at 12:23:43PM +0100, marco atzeri wrote:

after last package update I noticed two issues:

on .XWinrc I was forced to change


The first one was reported a week ago as FreeBSD #175782,
and is fixed in #289 (last Friday).


nice to know, reverting to #287 solves the issue.




$ xfontsel.exe &
"Warning: Missing charsets in String to FontSet conversion"


The second one was (I think) reported/fixed on this list.



reported yes, I see it in some variants, solved not.

But reverting xterm, solves also the xfontsel.exe warning.

Regards
Marco





--
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/

Re: xterm and font problems after last update

[Thomas Dickey]

On Mon, Feb 11, 2013 at 12:23:43PM +0100, marco atzeri wrote:
> after last package update I noticed two issues:
> 
> on .XWinrc I was forced to change

The first one was reported a week ago as FreeBSD #175782,
and is fixed in #289 (last Friday).
 
> $ xfontsel.exe &
> "Warning: Missing charsets in String to FontSet conversion"

The second one was (I think) reported/fixed on this list.

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Re: XTerm icon updated? Re: Updated: xterm-283-1

[Thomas Dickey]

On Thu, Oct 18, 2012 at 04:35:24PM +, Matt Seitz (matseitz) wrote:
> > From: Thomas Dickey
> > 
> > I did consider providing a special resource value that would suppress the
> > xterm-specific icon (such as "none" or "default"), but decided to see what
> > type of feedback I'd get first.
> 
> I like having a specific xterm icon in the taskbar to make it clear which X 
> application is actually running.  I was just surprised to see a different 
> icon, and I was curious what had changed to make it appear.  Thanks for the 
> explanation!

no problem (thanks for the feedback)

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

RE: XTerm icon updated? Re: Updated: xterm-283-1

[Matt Seitz (matseitz)]

> From: Thomas Dickey
> 
> I did consider providing a special resource value that would suppress the
> xterm-specific icon (such as "none" or "default"), but decided to see what
> type of feedback I'd get first.

I like having a specific xterm icon in the taskbar to make it clear which X 
application is actually running.  I was just surprised to see a different icon, 
and I was curious what had changed to make it appear.  Thanks for the 
explanation!

  


--
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/

Re: XTerm icon updated? Re: Updated: xterm-283-1

[Thomas Dickey]

On Mon, Oct 15, 2012 at 03:42:02PM -0600, Jim Reisert AD1C wrote:
> On Mon, Oct 15, 2012 at 11:58 AM, Matt Seitz wrote:
> 
> > Did this update change the XTerm icon that is displayed in the Windows task 
> > bar?
> 
> Yes, it reminds me of the Texas Rangers logo (American baseball team).

Looking at that, I'd say not more than 10% (and wasn't inspired by it -
I don't pay much attention to organized sports).

See
http://invisible-island.net/xterm/xterm.icon.html

(I'll add more to the page, when I'm not working on more urgent things)

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Re: XTerm icon updated? Re: Updated: xterm-283-1

[Jim Reisert AD1C]

On Mon, Oct 15, 2012 at 11:58 AM, Matt Seitz wrote:

> Did this update change the XTerm icon that is displayed in the Windows task 
> bar?

Yes, it reminds me of the Texas Rangers logo (American baseball team).

-- 
Jim Reisert AD1C, , http://www.ad1c.us

--
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/

Re: XTerm icon updated? Re: Updated: xterm-283-1

[Thomas Dickey]

On Mon, Oct 15, 2012 at 05:58:10PM +, Matt Seitz (matseitz) wrote:
> Did this update change the XTerm icon that is displayed in the Windows task
> bar?
> 
> Previously, when I launched the XWin Server, I would see the x.org logo (a
> black X with an orange ring) in the task bar as the icon for the XTerm
> window.  Today, I see the XTerm icon for the XTerm window:  a red X with a
> blue T superimposed over it.

yes - from xterm's standpoint it's moderately complicated.

For Xwin Server, I assume that the icon is shown because that's the
window which keeps the server from exiting.

Though I investigated several cases, I didn't consider this particular
one.  xterm now specifies an icon because several of the cases I found
didn't provide any icon at all - a favor from the desktop packagers, it
seems. I did consider providing a special resource value that would
suppress the xterm-specific icon (such as "none" or "default"), but
decided to see what type of feedback I'd get first.

HTH
 
> "Yaakov (Cygwin/X)" wrote:
> > The following package has been updated for the Cygwin distribution:
> > 
> > *** xterm-283-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
> 
> --
> 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/

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Re: "xterm -si" doesn't hold the line

[Thomas Dickey]

On Sat, Jul 28, 2012 at 02:49:22PM +0200, Paul Maier wrote:
> Hi,
> 
> xterm -si doesn't work as expected.

The short answer is that it's always been that way :-)

This refers to the scrollTtyOutput, which in xterm is described:

   scrollTtyOutput (class ScrollCond)
   Specifies whether or not output to the terminal should automat-
   ically cause the scrollbar to go to the bottom of the scrolling
   region.  The default is ``true.''

and in rxvt (in the mid-1990s):

   scrollTtyOutput: boolean
   True: scroll to bottom when tty receives output; option -si.
   False: do not scroll to bottom when tty receives output; option
   +si.

However, rxvt (also long ago) implemented a different flavor:

   scrollWithBuffer: boolean
   True: scroll with scrollback buffer when tty receives new lines
   (and scrollTtyOutput is False); option -sw. False: do not scroll
   with scrollback buffer when tty receives new lines; option +sw.
 
and (relatively recently - two years ago) I implemented a different choice:

   allowScrollLock (class AllowScrollLock)
   Specifies  whether  control sequences that set/query the Scroll
   Lock key should be allowed, as well as whether the Scroll  Lock
   key responds to user's keypress.  The default is "false".

   When this feature is enabled, xterm will sense the state of the
   Scroll Lock key each time  it  acquires  focus.   Pressing  the
   Scroll Lock key toggles xterm's internal state, as well as tog-
   gling the associated LED.  While the  Scroll  Lock  is  active,
   xterm attempts to keep a viewport on the same set of lines.  If
   the current viewport is scrolled past  the  limit  set  by  the
   saveLines resource, then Scroll Lock has no further effect.

   The  reason for setting the default to "false" is to avoid user
   surprise.  This key is generally unused in keyboard  configura-
   tions,  and has not acquired a standard meaning even when it is
   used in that manner.  Consequently, users have assigned it  for
   ad hoc purposes.

That has the same general effect if Scroll Lock is set - I might still
add a "-sw" option like rxvt.

> To reproduce (think of a "tail -f" instead of xev):
> 
> 1. xterm -si -e /bin/xev
> 2. move the mouse in the xev window to produce some lines
> 3. scroll the xterm up half way and remember the visible lines
> 4. while looking at the xterm, again move the mouse in the xev window
> 
> You see: xterm scrolls slowly down.
> 
> I would expect xterm to hold the current view while xev produces more lines 
> at the end.
> 
> 
> Suppose you have a "tail -f" running and scroll the xterm up to view a 
> specific line.
> I would expect that line to stay visible until I scroll somewhere else.
> But it's not: as the "tail -f" produces output, the xterm scrolls slowly down.
> To clarify: xterm does not scroll down to the very end but it scrolls down 
> line by line,
> as if xterm would try to keep the same distance between the current scrolling 
> position and the most recent line.
> 
> I would expect xterm to keep the same distance between the current scrolling 
> position and the *FIRST* line.
> 
> 
> In case above behaviour is the desired behaviour, I wanted to suggest another 
> command line option like "-si-top"
> for my use case.
> 
> Regards,
>   Paul
> 

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Re: XTerm metaSendsEscape not working

[Jesse Ziser]

On 11/9/2011 8:09 PM, Thomas Dickey wrote:

On Wed, 9 Nov 2011, Jesse Ziser wrote:


Hello,

I find that adding the following:

XTerm*vt100.metaSendsEscape: true
XTerm*vt100.altSendsEscape: true
XTerm*vt100.eightBitInput: false

to my .Xdefaults does not seem to change the way XTerm behaves WRT
meta-key handling. It still sends 0xF7 for meta-W, for example (or the
UTF-8 equivalent, depending on how I set LANG in the environment).

I've also tried this:

XTerm*metaSendsEscape: true
XTerm*altSendsEscape: true
XTerm*eightBitInput: false

to no avail. However, adding lines like the following:

Meta W: string(0x1b) string("w") \n


well, there's more than one aspect to the problem. xterm is looking for
whatever is used for the modifier which corresponds to the meta key. But
X doesn't have that as a standard modifier. So xterm looks at the
modifiers and determines which one it is. It might be the same as an
Alt-key, and it might not. So there's altSendsEscape as a workaround for
that case.

On the other hand, if there are translations using the key that xterm
finds to be the "meta" key, then xterm refrains from using it as a
modifier, unless (for example) the alwaysUseMods resource is set to true.


OK, removing all translations involving Meta did indeed fix it, and so 
did setting alwaysUseMods to true.  So I guess it wasn't a 
Cygwin-specific issue then after all, just a manpage comprehension 
issue.  Thanks!


--
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/

Re: XTerm metaSendsEscape not working

[Thomas Dickey]

On Wed, 9 Nov 2011, Jesse Ziser wrote:


Hello,

I find that adding the following:

XTerm*vt100.metaSendsEscape: true
XTerm*vt100.altSendsEscape: true
XTerm*vt100.eightBitInput: false

to my .Xdefaults does not seem to change the way XTerm behaves WRT meta-key 
handling.  It still sends 0xF7 for meta-W, for example (or the UTF-8 
equivalent, depending on how I set LANG in the environment).


I've also tried this:

XTerm*metaSendsEscape: true
XTerm*altSendsEscape: true
XTerm*eightBitInput: false

to no avail.  However, adding lines like the following:

Meta W: string(0x1b) string("w") \n


well, there's more than one aspect to the problem.  xterm is looking for 
whatever is used for the modifier which corresponds to the meta key. But X 
doesn't have that as a standard modifier.  So xterm looks at the modifiers 
and determines which one it is.  It might be the same as an Alt-key, and 
it might not.  So there's altSendsEscape as a workaround for that case.


On the other hand, if there are translations using the key that xterm 
finds to be the "meta" key, then xterm refrains from using it as a 
modifier, unless (for example) the alwaysUseMods resource is set to true.


--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
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/

Re: xterm update

[webmaster]

> perhaps your development environment lacks the FreeType library
> (that would show up in the configure step)
Ah, indeed. Thanks!

For anyone who can't wait for xterm > 261 to be included, here's
version 270: http://www.donsbox.com/~dfelicia/xterm-270-1.tar.bz2

--
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/

Re: xterm update

[Thomas Dickey]

On Thu, 19 May 2011, webmaster wrote:


I'm eagerly expecting an update to xterm 270 which I hope includes the
fix for the scrollbar drawing issue

You can get 269 from git:
http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/xterm;a=summary

To build 270 just modify the 269 .cygport.

When I build 269 or 270 the scrollbar issue is fixed, but this line in
my ~/.Xdefaults stops having an effect:


perhaps your development environment lacks the FreeType library
(that would show up in the configure step)

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
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/

Re: xterm update

[webmaster]

> I'm eagerly expecting an update to xterm 270 which I hope includes the
> fix for the scrollbar drawing issue
You can get 269 from git:
http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/xterm;a=summary

To build 270 just modify the 269 .cygport.

When I build 269 or 270 the scrollbar issue is fixed, but this line in
my ~/.Xdefaults stops having an effect:

*VT100*faceName:  Terminus:pixelsize=12:antialias=true

XTerm 261 has the scrollbar issue, but I get my nice Terminus font.

--
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/

Re: xterm access violations (again)

[richardvo...@gmail.com]

> FWIW, I know what is causing the problem but not how to fix it.  It's
> similar to
>
> http://cygwin.com/ml/cygwin/2011-04/msg1.html
>
> Rebasing should fix that particular problem but it's not a panacea.

The strace output in that other thread shows that GetLastError of 997
formerly caused some pipe handling functions deep in cygwin1.dll to
return success and now is converted to an error.  997 is one of the
rare non-zero success codes (in some sense).

#define ERROR_IO_PENDING 997L


Ben Voigt

--
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/

Re: xterm access violations (again)

[Christopher Faylor]

On Mon, Apr 04, 2011 at 02:27:27PM +0100, Jon TURNEY wrote:
>On 01/04/2011 17:05, Jim Reisert AD1C wrote:
>> On Sun, Mar 27, 2011 at 1:50 PM, Jim Reisert AD1C wrote:
>>> On Sat, Mar 26, 2011 at 12:35 PM, Christopher Faylor wrote:
 Could someone try this with the latest snapshot?  I haven't made any
 changes but I just want to confirm that it still fails with something
 close to what will become Cygwin 1.7.9.

 http://cygwin.com/snapshots/

 You just have to replace the DLL.  Don't bother with a "cygwin-inst*"
 tarball.
>>>
>>> Yes, still there:
>> 
>> How can I/we assist in debugging this problem?  First we need to
>> determine where the problem lies, whether it's in Cygwin itself, or
>> xterm. Today it took me 3-4 tries to get an xterm up.  As I was
>> running late for work, it was kind of frustrating.
>
>I think you could:
>
>1. Obtain the cygwin1.dbg file corresponding to your cygwin1.dll (for
>snapshots, it is available from the snapshot page, for releases, I believe it
>is in the corresponding cygwin src package), and place it next to your 
>cygwin1.dll
>2. Run xterm under gdb
>3. Obtain a backtrace when the segv occurs
>4. Diagnose the problem
>5. Write and test a patch to fix it
>
>You'll probably want to refer to [1] for that last step. :-)
>
>[1] http://cygwin.com/contrib.html

FWIW, I know what is causing the problem but not how to fix it.  It's
similar to

http://cygwin.com/ml/cygwin/2011-04/msg1.html

Rebasing should fix that particular problem but it's not a panacea.

cgf

--
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/

Re: xterm access violations (again)

[Jon TURNEY]

On 01/04/2011 17:05, Jim Reisert AD1C wrote:
> On Sun, Mar 27, 2011 at 1:50 PM, Jim Reisert AD1C wrote:
>> On Sat, Mar 26, 2011 at 12:35 PM, Christopher Faylor wrote:
>>> Could someone try this with the latest snapshot?  I haven't made any
>>> changes but I just want to confirm that it still fails with something
>>> close to what will become Cygwin 1.7.9.
>>>
>>> http://cygwin.com/snapshots/
>>>
>>> You just have to replace the DLL.  Don't bother with a "cygwin-inst*"
>>> tarball.
>>
>> Yes, still there:
> 
> How can I/we assist in debugging this problem?  First we need to
> determine where the problem lies, whether it's in Cygwin itself, or
> xterm. Today it took me 3-4 tries to get an xterm up.  As I was
> running late for work, it was kind of frustrating.

I think you could:

1. Obtain the cygwin1.dbg file corresponding to your cygwin1.dll (for
snapshots, it is available from the snapshot page, for releases, I believe it
is in the corresponding cygwin src package), and place it next to your 
cygwin1.dll
2. Run xterm under gdb
3. Obtain a backtrace when the segv occurs
4. Diagnose the problem
5. Write and test a patch to fix it

You'll probably want to refer to [1] for that last step. :-)

[1] http://cygwin.com/contrib.html

-- 
Jon TURNEY
Volunteer Cygwin/X X Server maintainer

--
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/

Re: xterm access violations (again)

[Jim Reisert AD1C]

On Sun, Mar 27, 2011 at 1:50 PM, Jim Reisert AD1C
 wrote:

> On Sat, Mar 26, 2011 at 12:35 PM, Christopher Faylor wrote:
>
>> Could someone try this with the latest snapshot?  I haven't made any
>> changes but I just want to confirm that it still fails with something
>> close to what will become Cygwin 1.7.9.
>>
>> http://cygwin.com/snapshots/
>>
>> You just have to replace the DLL.  Don't bother with a "cygwin-inst*"
>> tarball.
>
> Yes, still there:

How can I/we assist in debugging this problem?  First we need to
determine where the problem lies, whether it's in Cygwin itself, or
xterm. Today it took me 3-4 tries to get an xterm up.  As I was
running late for work, it was kind of frustrating.

-- 
Jim Reisert AD1C, , http://www.ad1c.us

--
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/

Re: xterm access violations (again)

[Jim Reisert AD1C]

On Sat, Mar 26, 2011 at 12:35 PM, Christopher Faylor wrote:

> Could someone try this with the latest snapshot?  I haven't made any
> changes but I just want to confirm that it still fails with something
> close to what will become Cygwin 1.7.9.
>
> http://cygwin.com/snapshots/
>
> You just have to replace the DLL.  Don't bother with a "cygwin-inst*"
> tarball.

Yes, still there:

CYGWIN_NT-6.1-WOW64 JJR 1.7.9s(0.236/5/3) 20110327 15:26:47 i686 Cygwin

Exception: STATUS_ACCESS_VIOLATION at eip=61020497
eax=00CD00F8 ebx=6124556C ecx=76950D06 edx=00334118 esi= edi=0028F9F4
ebp=61020BE0 esp=0028C7C4 program=D:\cygwin\bin\xterm.exe, pid 7968, thread main
cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame Function  Args
End of stack trace

-- 
Jim Reisert AD1C, , http://www.ad1c.us

--
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/

Re: xterm access violations (again)

[Christopher Faylor]

On Fri, Mar 25, 2011 at 01:22:42AM -0400, Christopher Faylor wrote:
>On Thu, Mar 24, 2011 at 10:09:38PM -0600, Jim Reisert AD1C wrote:
>>On Thu, Mar 24, 2011 at 5:24 PM, webmaster wrote:
>>
>>> http://www.donsbox.com/~dfelicia/xterm-269[redacted]
>>
>>Still dumps, but xterm came up anyway:
>>
>>Exception: STATUS_ACCESS_VIOLATION at eip=61020497
>>eax=00DD00F8 ebx=61246A44 ecx=75570D06 edx=00334118 esi= edi=0028F9F4
>>ebp=61020BE0 esp=0028C7C4 program=F:\download\tt\usr\bin\xterm.exe,
>>pid 7796, thread main
>>cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
>>Stack trace:
>>Frame Function  Args
>>End of stack trace
>>
>>
>>In fact I tried it about 1/2 dozen times.  Half the time, no dump,
>>xterm starts.  Other half of the time, dump but xterm starts anyway.
>
>It's not an xterm problem, AFAICT.  It's SEGVing in Cygwin due to a
>problem with Cygwin's record keeping about loaded DLLs.  Possibly rebase
>will help.  I'll investigate more over the weekend.

Could someone try this with the latest snapshot?  I haven't made any
changes but I just want to confirm that it still fails with something
close to what will become Cygwin 1.7.9.

http://cygwin.com/snapshots/

You just have to replace the DLL.  Don't bother with a "cygwin-inst*"
tarball.

cgf

--
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/

Re: xterm access violations (again)

[webmaster]

> Possibly rebase will help.
Nope. Same result.

--
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/

Re: xterm access violations (again)

[Christopher Faylor]

On Thu, Mar 24, 2011 at 10:09:38PM -0600, Jim Reisert AD1C wrote:
>On Thu, Mar 24, 2011 at 5:24 PM, webmaster wrote:
>
>> http://www.donsbox.com/~dfelicia/xterm-269[redacted]
>
>Still dumps, but xterm came up anyway:
>
>Exception: STATUS_ACCESS_VIOLATION at eip=61020497
>eax=00DD00F8 ebx=61246A44 ecx=75570D06 edx=00334118 esi= edi=0028F9F4
>ebp=61020BE0 esp=0028C7C4 program=F:\download\tt\usr\bin\xterm.exe,
>pid 7796, thread main
>cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
>Stack trace:
>Frame Function  Args
>End of stack trace
>
>
>In fact I tried it about 1/2 dozen times.  Half the time, no dump,
>xterm starts.  Other half of the time, dump but xterm starts anyway.

It's not an xterm problem, AFAICT.  It's SEGVing in Cygwin due to a
problem with Cygwin's record keeping about loaded DLLs.  Possibly rebase
will help.  I'll investigate more over the weekend.

cgf

--
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/

Re: xterm access violations (again)

[Jim Reisert AD1C]

On Thu, Mar 24, 2011 at 5:24 PM, webmaster wrote:

> http://www.donsbox.com/~dfelicia/xterm-269[redacted]

Still dumps, but xterm came up anyway:

Exception: STATUS_ACCESS_VIOLATION at eip=61020497
eax=00DD00F8 ebx=61246A44 ecx=75570D06 edx=00334118 esi= edi=0028F9F4
ebp=61020BE0 esp=0028C7C4 program=F:\download\tt\usr\bin\xterm.exe,
pid 7796, thread main
cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame Function  Args
End of stack trace


In fact I tried it about 1/2 dozen times.  Half the time, no dump,
xterm starts.  Other half of the time, dump but xterm starts anyway.

-- 
Jim Reisert AD1C, , http://www.ad1c.us

--
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/

Re: xterm access violations (again)

[Christopher Faylor]

On Thu, Mar 24, 2011 at 04:40:01PM -0400, Thomas Dickey wrote:
>On Thu, 24 Mar 2011, webmaster wrote:
>
>>> I just built 269 and will uploaded it with the rest of the X11 updates.
>> It doesn't help. I built using cygport from what you've got in git and
>> I still get:
>>
>> Exception: STATUS_ACCESS_VIOLATION at eip=61020497
>> eax=00DA80E0 ebx=6124298C ecx=76A10D06 edx=00371D48 esi= edi=0028F9F4
>> ebp=61020BE0 esp=0028C7C4 program=C:\Cygwin\bin\xterm.exe, pid 672, thread 
>> main
>> cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
>> Stack trace:
>> Frame Function  Args
>> End of stack trace
>>
>> Note that I often (almost always) get this written to
>> xterm.exe.stackdump even when xterm opens successfully. Also note that
>> opening xterms is *much* slower than on XP.
>
>:-(
>
>It would be nice to know whether the problem lies in xterm itself, or
>the libraries.  Is it possible to compile with the -g debug option,
>run that from gdb, to get a walkback?

The EIP (61020497) above suggests a potential problem in Cygwin.

Could we get some cygcheck output, as per http://cygwin.com/problems.html ?

--
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/

Re: xterm access violations (again)

[Thomas Dickey]

On Thu, 24 Mar 2011, webmaster wrote:


I just built 269 and will uploaded it with the rest of the X11 updates.

It doesn't help. I built using cygport from what you've got in git and
I still get:

Exception: STATUS_ACCESS_VIOLATION at eip=61020497
eax=00DA80E0 ebx=6124298C ecx=76A10D06 edx=00371D48 esi= edi=0028F9F4
ebp=61020BE0 esp=0028C7C4 program=C:\Cygwin\bin\xterm.exe, pid 672, thread main
cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame Function  Args
End of stack trace

Note that I often (almost always) get this written to
xterm.exe.stackdump even when xterm opens successfully. Also note that
opening xterms is *much* slower than on XP.


:-(

It would be nice to know whether the problem lies in xterm itself, or
the libraries.  Is it possible to compile with the -g debug option,
run that from gdb, to get a walkback?

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
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/

Re: xterm access violations (again)

[webmaster]

> I just built 269 and will uploaded it with the rest of the X11 updates.
It doesn't help. I built using cygport from what you've got in git and
I still get:

Exception: STATUS_ACCESS_VIOLATION at eip=61020497
eax=00DA80E0 ebx=6124298C ecx=76A10D06 edx=00371D48 esi= edi=0028F9F4
ebp=61020BE0 esp=0028C7C4 program=C:\Cygwin\bin\xterm.exe, pid 672, thread main
cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame Function  Args
End of stack trace

Note that I often (almost always) get this written to
xterm.exe.stackdump even when xterm opens successfully. Also note that
opening xterms is *much* slower than on XP.

--
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/

Re: xterm access violations (again)

[webmaster]

>  where would one get xterm-269.cygport et al. for local building?Answered my 
> own question: 
> http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/xterm;a=summary

--
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/

Re: xterm access violations (again)

[webmaster]

> I just built 269 and will uploaded it with the rest of the X11 updates.
Probably in some FAQ and I just can't find it, but where would one get
xterm-269.cygport et al. for local building? Some git repository,
somewhere?

--
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/

Re: xterm access violations (again)

[Thomas Dickey]

On Wed, 23 Mar 2011, Yaakov (Cygwin/X) wrote:


On Wed, 2011-03-23 at 19:16 -0600, Jim Reisert AD1C wrote:

Thomas, that may well be true, but the latest one in the Cygwin
repository reports (261).  It shows up as 261-1 in setup.exe


I just built 269 and will uploaded it with the rest of the X11 updates.


thanks

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
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/

Re: xterm access violations (again)

[Yaakov (Cygwin/X)]

On Wed, 2011-03-23 at 19:16 -0600, Jim Reisert AD1C wrote:
> Thomas, that may well be true, but the latest one in the Cygwin
> repository reports (261).  It shows up as 261-1 in setup.exe

I just built 269 and will uploaded it with the rest of the X11 updates.


Yaakov
Cygwin/X



--
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/

Re: xterm access violations (again)

[Jim Reisert AD1C]

On Wed, Mar 23, 2011 at 3:17 PM, Thomas Dickey wrote:

> #269 is current.  At the moment, the only fixes I've made against that
> are minor things (an incomplete change for the fullscreen feature, and
> an obscure case of a control sequence from #251 changes).

Thomas, that may well be true, but the latest one in the Cygwin
repository reports (261).  It shows up as 261-1 in setup.exe

- Jim

-- 
Jim Reisert AD1C, , http://www.ad1c.us

--
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/

Re: xterm access violations (again)

[Thomas Dickey]

On Wed, 23 Mar 2011, webmaster wrote:


what is "xterm -v"?

$ xterm -v
XTerm(261)


That's from last June.  #263 makes a fix for a problem which might be 
relevant (and #265 fixes a regression from #263).



Note I built myself using cygport so that I could add
--disable-narrowproto (See thread with subject "Bug: XTerm scrollbar
issue" last updated 7/13/2010)


#269 is current.  At the moment, the only fixes I've made against that
are minor things (an incomplete change for the fullscreen feature, and
an obscure case of a control sequence from #251 changes).

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
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/

Re: xterm access violations (again)

[Jim Reisert AD1C]

On Tue, Mar 22, 2011 at 11:28 AM, Jim Reisert AD1C
 wrote:

> On Tue, Mar 22, 2011 at 11:15 AM, webmaster wrote:
>
>> After updating to the latest cygwin 1.7.8, today, xterm constantly crashes.
>>
>> cat xterm.exe.stackdump
>> [...]
>>
>> Usually rebaseall fixes this problem, but not this time. I also tried
>> building xterm with cygport, but same result. This is on Windows 7 x64
>> Professional.
>
> On my Win7 system, it crashes about 1/2 the time.  If I start it from
> the system tray icon, and the xterm window doesn't appear in under a
> second, it has crashed and I try again.

This morning it took three tries to get an xterm:

Exception: STATUS_ACCESS_VIOLATION at eip=61020497
eax=00B400F8 ebx=612455AC ecx=75570D06 edx=002C4118 esi= edi=0028F9F4
ebp=61020BE0 esp=0028C7C4 program=D:\Cygwin\bin\xterm.exe, pid 8048, thread main
cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame Function  Args
End of stack trace


JJR:~> xterm -v
Cygwin 6.8.99.903(261)


-- 
Jim Reisert AD1C, , http://www.ad1c.us

--
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/

Re: xterm access violations (again)

[webmaster]

> what is "xterm -v"?
$ xterm -v
XTerm(261)

Note I built myself using cygport so that I could add
--disable-narrowproto (See thread with subject "Bug: XTerm scrollbar
issue" last updated 7/13/2010)

--
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/

Re: xterm access violations (again)

[Jim Reisert AD1C]

On Tue, Mar 22, 2011 at 11:28 AM, Jim Reisert AD1C
 wrote:

> On Tue, Mar 22, 2011 at 11:15 AM, webmaster wrote:
>
>> After updating to the latest cygwin 1.7.8, today, xterm constantly crashes.
>>
>> cat xterm.exe.stackdump
>> [...]
>>
>> Usually rebaseall fixes this problem, but not this time. I also tried
>> building xterm with cygport, but same result. This is on Windows 7 x64
>> Professional.
>
> On my Win7 system, it crashes about 1/2 the time.  If I start it from
> the system tray icon, and the xterm window doesn't appear in under a
> second, it has crashed and I try again.

At work, I'm using the latest version of Cygwin and X server (same
versions as at home), but running on a Windows XP system (SP3).  I
never have any problems.

NOTE: the Win7 system at home is 64-bit Pro version.

-- 
Jim Reisert AD1C, , http://www.ad1c.us

--
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/

Re: xterm access violations (again)

[Thomas Dickey]

On Tue, 22 Mar 2011, webmaster wrote:


On my Win7 system, [xterm] crashes about 1/2 the time.

Right. Same, here. It used to crash a lot less frequently.


what is "xterm -v"?

(the last crash-related bug I recall was fixed last spring).

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
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/

Re: xterm access violations (again)

[webmaster]

> On my Win7 system, [xterm] crashes about 1/2 the time.
Right. Same, here. It used to crash a lot less frequently.

--
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/

Re: xterm access violations (again)

[Jim Reisert AD1C]

On Tue, Mar 22, 2011 at 11:15 AM, webmaster wrote:

> After updating to the latest cygwin 1.7.8, today, xterm constantly crashes.
>
> cat xterm.exe.stackdump
> [...]
>
> Usually rebaseall fixes this problem, but not this time. I also tried
> building xterm with cygport, but same result. This is on Windows 7 x64
> Professional.

On my Win7 system, it crashes about 1/2 the time.  If I start it from
the system tray icon, and the xterm window doesn't appear in under a
second, it has crashed and I try again.

- Jim

-- 
Jim Reisert AD1C, , http://www.ad1c.us

--
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/

Re: xterm opens two windows

[Andy Koppe]

On 18 December 2010 01:33, Marshall, Lee wrote:
> One has a windows icon and the text "Warning: Missing charsets in String to 
> FontSet conversion"
> The other has the X icon with a menu bar and "sh-3.2$".
>
> My biggest objection to this is just the clutter of having a second, useless 
> window open displaying this warning.  Searching the internet, I found 
> http://sourceware.org/bugzilla/show_bug.cgi?id=10948 and installed the 
> additional fonts: font-isas-misc, font-jis-misc and font-daewoo-misc without 
> eliminating the warning.

The second window is a Windows console. Windows creates that
automatically because xterm is (arguably wrongly) marked as a console
application. Avoid it by invoking xterm through the 'run' or 'run2'
tools. See their man pages for further details.

Andy

--
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/

Re: Xterm Title

[Csaba Raduly]

Hi Ajay,

On Mon, Nov 1, 2010 at 5:59 AM, Ajay Jain  wrote:
> Hi,
>
> I want my Xterm to display a constant title say mercury. So I use:
> Xterm -T mercury. Further, I have placed the following line in my
> .Xresources: xterm*allowTitleOps: 0. From my .vnc/xstartup, I also do:
> xrdb -merge ~/.Xresources. Even then my Xterm title changes to
> logn...@hostname:pwd. I want to avoid it and replace this with a fixed
> title. Could you suggest something? After all, what is it that is
> going wrong? I am also trying to set PROMT_COMMAND, without any
> success.

Check your prompt ($PS1) for xterm title escape sequences
(http://www.faqs.org/docs/Linux-mini/Xterm-Title.html), like \[\e]0;
... stuff ... \a\]

-- 
GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++
Life is complex, with real and imaginary parts.
"Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds
"People disagree with me. I just ignore them." -- Linus Torvalds

--
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/

Re: Re: xterm and 7-bit control codes

[Thomas Dickey]

On Sat, 14 Aug 2010, Ryan Johnson wrote:


On 8:59 PM, Thomas Dickey wrote:

As far as I know, xterm's never sent more than one byte for either x/y in
a button event.  Ditto for rxvt.  It sounds like a useful idea, except that 
it would of course be incompatible with the existing applications.

So it would have to be enabled by a new control sequence.
Hehe... very true about breaking existing apps. All those years ago the extra 
octet kick-started everything by confusing emacs (well, xterm-mouse-mode, 
really). I started looking at the character stream and reverse-engineered the 
above formula while trying to get rid of all the ascii garbage that polluted 
my buffers after stray mouse clicks. Only then did I realize I could exploit 
(rather than suppress) the extra octets to make large terminals behave 
better...




(On the other hand, whatever application you were using at the time may
have translated the characters in that manner).
I dug up an old .emacs, and it actually mentions gnu screen. If so, that's 
definitely been "fixed" because I specifically tested screen on several 
machines (cygwin, solaris, linux), plus rxvt and the gnome terminal***) 
before posting here. Any ideas what other terminal emulators I might test?


Not offhand.  The only prior discussion I recall in that area was the
1-byte limit.  It might have been someone's more/less private patch to
screen - to be usable with screen in the first place, it has to be aware
of the control sequence (otherwise it tends to filter things out).  The
mouse control sequences are a special case, since they don't have a final
character.

Side note: how much pain would it be asking for if I tried to add the 
double-octet behavior to xterm as a feature? Would it be better to tackle 
rxvt? Or would it be man-weeks of work no matter what and I should just drop 
it?


It didn't sound like a lot of work: a case-statement entry in dpmodes 
(charproc.c) to enable/disable it, and a few lines of code in EditorButton 
(button.c) plus updating ctlseqs.ms).




Thanks,
Ryan

*** testing gnome terminal was hilarious: enabling mouse support and clicking 
on the wrong position sends a control sequence containing ^Z, which duly 
backgrounds the app!


;-)

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
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/

Re: Re: xterm and 7-bit control codes

[Ryan Johnson]

 On 8:59 PM, Thomas Dickey wrote:

As far as I know, xterm's never sent more than one byte for either x/y in
a button event.  Ditto for rxvt.  It sounds like a useful idea, except 
that it would of course be incompatible with the existing applications.

So it would have to be enabled by a new control sequence.
Hehe... very true about breaking existing apps. All those years ago the 
extra octet kick-started everything by confusing emacs (well, 
xterm-mouse-mode, really). I started looking at the character stream and 
reverse-engineered the above formula while trying to get rid of all the 
ascii garbage that polluted my buffers after stray mouse clicks. Only 
then did I realize I could exploit (rather than suppress) the extra 
octets to make large terminals behave better...




(On the other hand, whatever application you were using at the time may
have translated the characters in that manner).
I dug up an old .emacs, and it actually mentions gnu screen. If so, 
that's definitely been "fixed" because I specifically tested screen on 
several machines (cygwin, solaris, linux), plus rxvt and the gnome 
terminal***) before posting here. Any ideas what other terminal 
emulators I might test?


Side note: how much pain would it be asking for if I tried to add the 
double-octet behavior to xterm as a feature? Would it be better to 
tackle rxvt? Or would it be man-weeks of work no matter what and I 
should just drop it?


Thanks,
Ryan

*** testing gnome terminal was hilarious: enabling mouse support and 
clicking on the wrong position sends a control sequence containing ^Z, 
which duly backgrounds the app!



--
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/

Re: xterm and 7-bit control codes

[Thomas Dickey]

On Thu, 12 Aug 2010, Ryan Johnson wrote:


Hi all,

I'm running into a strange one...

At some point in the past (on linux because I didn't know about cygwin yet), 
xterm used to send the following control sequence for a mouse click at row 1, 
col 250


ESC [ M SPC \303\206 ! ESC [ M # \303\206 !

From what I could piece together, the formula for the x position was:

\40+x (x < 96)
\300+X/64 \200+X%64 (otherwise)

In other words, the first 96 characters were encoded as single octets, with 
all later ones encoded as an octet pair.


As far as I know, xterm's never sent more than one byte for either x/y in
a button event.  Ditto for rxvt.  It sounds like a useful idea, except 
that it would of course be incompatible with the existing applications.

So it would have to be enabled by a new control sequence.

(On the other hand, whatever application you were using at the time may
have translated the characters in that manner).

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
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/

Re: XTerm scrollbar issue

[Thomas Dickey]

On Wed, 30 Jun 2010, Thomas Dickey wrote:


On Wed, 30 Jun 2010, webmaster wrote:


All releases of xterm newer that 229 (i.e. since June '08) have a
broken scrollbar.  It never bothered me enough to post a message, but
I've been setting up some new systems and have found it annoying to
dig up xterm-229 and manually install it.

These images show what the scrollbar used to look like (and what it
still looks like in all recent Linux distributions, even with latest
xterm builds):


Problems like that shown with the scrollbar are usually a compile-time
mismatch on floating-point.  There's a configure option for xterm to
address this (--enable-narrowproto or --disable-narrowproto), since
the mismatch is not detectable via automatic checks.


The issue is documented in xterm's INSTALL file.  Packagers have to 
essentially ensure that the prototype for XawScrollbarSetThumb is compiled 
properly.  For instance, the package for xterm in Debian uses 
--enable-narrowproto


That turns on a #define for NARROWPROTO which may be missing (or not not 
coordinated with Xfuncproto.h, which in turn sets #defines used in Xaw, to 
choose between a "float" and a "double" for the type of one of its 
parameters).


--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
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/

Re: XTerm scrollbar issue

[Thomas Dickey]

On Wed, 30 Jun 2010, webmaster wrote:


All releases of xterm newer that 229 (i.e. since June '08) have a
broken scrollbar.  It never bothered me enough to post a message, but
I've been setting up some new systems and have found it annoying to
dig up xterm-229 and manually install it.

These images show what the scrollbar used to look like (and what it
still looks like in all recent Linux distributions, even with latest
xterm builds):


Problems like that shown with the scrollbar are usually a compile-time
mismatch on floating-point.  There's a configure option for xterm to
address this (--enable-narrowproto or --disable-narrowproto), since
the mismatch is not detectable via automatic checks.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
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/

RE: xterm faceSize and -fs in version 260

[Thomas Dickey]

On Sun, 27 Jun 2010, Joseph Quinsey wrote:


Thomas Dickey replied:


And I realize -fa also doesn't seem to work for me for 260.


thanks - it's some error in the way I added the logic for the renderFont
resource.  You should be able to work around by adding

*renderFont:true

to your X resource settings.


Thank you.  This works for 260.


no problem (will fix "soon")

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
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/

RE: xterm faceSize and -fs in version 260

[Joseph Quinsey]

Thomas Dickey replied:

>> And I realize -fa also doesn't seem to work for me for 260.
>
>thanks - it's some error in the way I added the logic for the renderFont
>resource.  You should be able to work around by adding
>
>*renderFont:true
>
>to your X resource settings.

Thank you.  This works for 260.
---
Joseph Quinsey



--
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/

RE: xterm faceSize and -fs in version 260

[Joseph Quinsey]

Attached are the results of appres XTerm and xterm.


appres_XTerm2
Description: Binary data


appres_xterm
Description: Binary data
--
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/

Re: xterm faceSize and -fs in version 260

[Thomas Dickey]

On Sun, 27 Jun 2010, Joseph Quinsey wrote:


The xterm faceSize resource and the -fs command line option do not seem to
work with xterm version 260.  Installing the previous Cygwin version, 255,
fixes this.


hmm - I changed the handling of the renderFont resource, but didn't
notice breakage of the other resources (perhaps the output of "appres 
XTerm" would show me the problem)


--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
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/

Re: xterm no longer accepts keyboard input

[Josh]

Larry Hall (Cygwin X  cygwin.com> writes:

> 
> On 5/6/2010 3:18 AM, Jyh-Shyong Ho wrote:
> > I read a series of discussion on this problem, have you been able to solve 
this
> > problem?
> 
> 
> 

Hi, Larry,

I have tried use FAQ's step to unset XkeysysDB on my cygwin, but still not 
work.
also I have using command 'source /etc/profile.d/xinit.sh' to unset 
XkeysysDB.
But, still not work.
How could I make sure the XkeysysDB unset properly?
Anyone could give me a hand would appreciate.

Regards
josh



--
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/

Re: xterm no longer accepts keyboard input

[Larry Hall (Cygwin X)]

On 5/6/2010 3:18 AM, Jyh-Shyong Ho wrote:

I read a series of discussion on this problem, have you been able to solve this
problem?




--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

_

A: Yes.

Q: Are you sure?

A: Because it reverses the logical flow of conversation.

Q: Why is top posting annoying in email?


--
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/

Re: xterm no longer accepts keyboard input

[Jyh-Shyong Ho]

Hi,

I read a series of discussion on this problem, have you been able to solve this
problem?

I just had a PC with 64-bit Windows 7 installed, and try to install CYGWIN/X on
it, I encountered the same problem: the xterm no longer accepts keyboard input.
I tried various methods to solve this problem but failed, so I like to know how
do you make the CYGWIN/X work again?

I have been using the old version of CYGWIN/X on WindowsXP and Windows VISTA for
a long time without any problem.  Thank you.





--
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/

Re: xterm no longer accepts keyboard input

[David Barr]

On Mon, Mar 15, 2010 at 10:44 AM, Jon TURNEY
 wrote:
>
> No.  startx and startxwin are different tools to solve different problems.
>
> I keep adding more text to [1] to clarify this, but this doesn't appear to
> help, perhaps because nobody actually reads it...
>
> [1] http://x.cygwin.com/docs/ug/using.html#using-starting
>

I read it.  I just don't agree with it.  These appear to be the reasons:

1) "startxwin supplies the -multiwindow  option to XWin.exe"

So does startx if you put that in the shortcut.

2) "It uses a different script to start clients (~/.startxwinrc rather
than ~/.xinitrc), because ~/.xinitrc will normally end by starting a
window manager, which would be incorrect for  ~/.startxwinrc (as it
would discover the internal window manager is already running and exit
immediately)."

In my opinion, it doesn't really matter with .xinitrc normally ends
with.  We can end it with anything that we want.  It sounds like you
can get the startxwin behavior (if that's what you really want) from
startx if you put "sh ~/.startxwinrc& while : ; do sleep 1000; done"
in your .xinitrc.

3) "startxwin exits after ~/.startxwinrc  has completed and leaves
XWin.exe running, whereas startx waits until ~/.xinitrc exits (which
is usually waiting for the window manager started by it to exit) and
then kills XWin.exe."

If you don't like the behavior of startx exiting after the .xinitrc is
complete, then why not write your .xinitrc so that it doesn't exit?

Is it really worth maintaining another program when you can get the
same behavior out of existing programs through config changes?
Additionally, the startxwin.exe program is missing the security
feature of creating a .Xauthority file.

--
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/

Re: xterm no longer accepts keyboard input

[Bob Kline]

On 3/15/2010 1:35 PM, Jon TURNEY wrote:

... I'm not sure if the difficulties starting a server mean you have 
some other problem as well.




Thanks for your response, Jon.  As you'll see from a more recent post, I 
was able to solve both problems by going back to using a script instead 
of the compiled binary for startxwin.


--
Bob Kline
http://www.rksystems.com
mailto:bkl...@rksystems.com


--
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/

Re: xterm no longer accepts keyboard input

[Jon TURNEY]

On 15/03/2010 05:42, David Barr wrote:

On Sun, Mar 14, 2010 at 7:17 AM, Jeff Spirko  wrote:

The icon runs from the Windows environment, so the run.exe and
bash.exe wrapper programs are needed to set up the proper cygwin
environment.  Once you're in a cygwin shell, you already have the
cygwin environment set up.  That's why you don't need to type them in
from the command line.

So, they really should be equivalent.


I've probably missed a prior discussion, but if "startxwin.exe"
doesn't set up the Cygwin environment, then what good is it? I thought
that this was about the only advantage that "startxwin.bat" had over
"startx".


No.  startx and startxwin are different tools to solve different problems.

I keep adding more text to [1] to clarify this, but this doesn't appear to 
help, perhaps because nobody actually reads it...


[1] http://x.cygwin.com/docs/ug/using.html#using-starting

> Considering that "startx" also sets up the .Xauthority file

and startxwin.exe doesn't, I see absolutely no reason to use
startxwin.exe instead of startx.



--
Jon TURNEY
Volunteer Cygwin/X X Server maintainer

--
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/

Re: xterm no longer accepts keyboard input

[Jon TURNEY]

On 13/03/2010 21:47, Bob Kline wrote:

On 3/13/2010 1:05 PM, Bob Kline wrote:

I have used X under Cygwin successfully for years. Yesterday I did an
upgrade of my Cygwin installation and X stopped working. After
struggling to get things working again, I decided to just install
Cygwin fresh and start over. Now I can get the X server started
(following the instructions in the Cygwin/X User's Guide, running
/usr/bin/startxwin from a Cygwin shell), but xterm windows that I open
do not respond to keyboard input. I looked at the FAQ and found the
entry (3.2 I upgraded my X server and now I can't type anything into
any X application) which warns against using any older scripts to
launch X, but as noted above, I'm invoking the startxwin binary
directly. Any thoughts as to what could be going wrong, given that
this is an installation of Cygwin and X from scratch?


looking at your cygcheck.out, you have the following variables in your 
environment

XKEYSYMDB = '/usr/X11R6/lib/X11/XKeysymDB'
XAPPLRESDIR = '/usr/X11R6/lib/X11/app-defaults'
XCMSDB = '/usr/X11R6/lib/X11/Xcms.txt'
XNLSPATH = '/usr/X11R6/lib/X11/locale'

These have probably been set by Microsoft Services for Unix, and as the FAQ 
tries to make clear, at least XKEYSYMDB must be unset for keyboard input to 
XWin to work correctly (FAQ 3.2 refers to FAQ 8.8)


We used to have something in startxwin.bat to unset this, so I guess it is a 
regression that we don't do that anymore.



Following up on my earlier post, I see that although I am able to start
the X server if I invoke /usr/bin/startxwin directly from a Cygwin
shell, that's not *exactly* what the FAQ was suggesting.


I'm not sure if the difficulties starting a server mean you have some other 
problem as well.


--
Jon TURNEY
Volunteer Cygwin/X X Server maintainer

--
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/

Re: xterm no longer accepts keyboard input

[David Barr]

On Sun, Mar 14, 2010 at 7:17 AM, Jeff Spirko  wrote:
> The icon runs from the Windows environment, so the run.exe and
> bash.exe wrapper programs are needed to set up the proper cygwin
> environment.  Once you're in a cygwin shell, you already have the
> cygwin environment set up.  That's why you don't need to type them in
> from the command line.
>
> So, they really should be equivalent.

I've probably missed a prior discussion, but if "startxwin.exe"
doesn't set up the Cygwin environment, then what good is it? I thought
that this was about the only advantage that "startxwin.bat" had over
"startx". Considering that "startx" also sets up the .Xauthority file
and startxwin.exe doesn't, I see absolutely no reason to use
startxwin.exe instead of startx.

--
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/

Re: xterm no longer accepts keyboard input

[Bob Kline]

On 3/14/2010 12:20 PM, Bob Kline wrote:

Attached is the log file from launch of X which does *not* result in 
the failure dialog window, but whose X session is not able to use 
input from the keyboard.


Sorry, that was the wrong log file (from an attempt to launch X from the 
shortcut).  Here is the log file from an X session created by invoking 
startxwin.exe directly from a bash console window.


--
Bob Kline
http://www.rksystems.com
mailto:bkl...@rksystems.com

Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 1.7.5.0 (10705000)
Build Date: 2010-02-25

Contact: cygwin-xfree@cygwin.com
XWin was started with the following command line:

X :0 -multiwindow 

ddxProcessArgument - Initializing default screens
winInitializeDefaultScreens - w 1920 h 1200
winInitializeDefaultScreens - Returning
2010-03-14 12:22:18 (WW) /tmp mounted in textmode
2010-03-14 12:22:18 _XSERVTransSocketOpenCOTSServer: Unable to open socket for 
inet6
2010-03-14 12:22:18 _XSERVTransOpen: transport open failed for inet6/xp:0
2010-03-14 12:22:18 _XSERVTransMakeAllCOTSServerListeners: failed to open 
listener for inet6
2010-03-14 12:22:19 winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1
2010-03-14 12:22:19 (II) xorg.conf is not supported
2010-03-14 12:22:19 (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for 
more information
2010-03-14 12:22:19 LoadPreferences: /cygdrive/c/home/bkline/.XWinrc not found
2010-03-14 12:22:19 LoadPreferences: Loading /etc/X11/system.XWinrc
2010-03-14 12:22:19 LoadPreferences: Done parsing the configuration file...
2010-03-14 12:22:19 winGetDisplay: DISPLAY=:0.0
2010-03-14 12:22:19 winDetectSupportedEngines - Windows NT/2000/XP
2010-03-14 12:22:19 winDetectSupportedEngines - DirectDraw installed
2010-03-14 12:22:19 winDetectSupportedEngines - DirectDraw4 installed
2010-03-14 12:22:19 winDetectSupportedEngines - Returning, supported engines 
0007
2010-03-14 12:22:19 winSetEngine - Multi Window or Rootless => ShadowGDI
2010-03-14 12:22:19 winAdjustVideoModeShadowGDI - Using Windows display depth 
of 32 bits per pixel
2010-03-14 12:22:19 winAllocateFBShadowGDI - Creating DIB with width: 1920 
height: 1200 depth: 32
2010-03-14 12:22:19 winFinishScreenInitFB - Masks: 00ff ff00 00ff
2010-03-14 12:22:19 winInitVisualsShadowGDI - Masks 00ff ff00 00ff 
BPRGB 8 d 24 bpp 32
2010-03-14 12:22:19 null screen fn ReparentWindow
2010-03-14 12:22:19 null screen fn RestackWindow
2010-03-14 12:22:19 InitQueue - Calling pthread_mutex_init
2010-03-14 12:22:19 InitQueue - pthread_mutex_init returned
2010-03-14 12:22:19 InitQueue - Calling pthread_cond_init
2010-03-14 12:22:19 InitQueue - pthread_cond_init returned
2010-03-14 12:22:19 winInitMultiWindowWM - Hello
2010-03-14 12:22:19 winMultiWindowXMsgProc - Hello
2010-03-14 12:22:19 Screen 0 added at XINERAMA coordinate (0,0).
2010-03-14 12:22:19 winInitMultiWindowWM - Calling pthread_mutex_lock ()
2010-03-14 12:22:19 winMultiWindowXMsgProc - Calling pthread_mutex_lock ()
2010-03-14 12:22:19 MIT-SHM extension disabled due to lack of kernel support
2010-03-14 12:22:19 XFree86-Bigfont extension local-client optimization 
disabled due to lack of shared memory support in the kernel
2010-03-14 12:22:19 (II) AIGLX: Loaded and initialized 
/usr/lib/dri/swrast_dri.so
2010-03-14 12:22:19 (II) GLX: Initialized DRISWRAST GL provider for screen 0
2010-03-14 12:22:29 winPointerWarpCursor - Discarding first warp: 960 600
2010-03-14 12:22:29 (--) 3 mouse buttons found
2010-03-14 12:22:30 (--) Setting autorepeat to delay=500, rate=31
2010-03-14 12:22:30 (--) winConfigKeyboard - Layout: "0409" (0409) 
2010-03-14 12:22:30 (--) Using preset keyboard for "English (USA)" (409), type 
"4"
2010-03-14 12:22:30 Rules = "base" Model = "pc105" Layout = "us" Variant = 
"none" Options = "none"
2010-03-14 12:22:30 winInitMultiWindowWM - pthread_mutex_lock () returned.
2010-03-14 12:22:30 winProcEstablishConnection - Hello
2010-03-14 12:22:30 winInitMultiWindowWM - pthread_mutex_unlock () returned.
2010-03-14 12:22:30 winMultiWindowXMsgProc - pthread_mutex_lock () returned.
2010-03-14 12:22:30 winInitClipboard ()
2010-03-14 12:22:30 winGetDisplay: DISPLAY=:0.0
2010-03-14 12:22:30 winMultiWindowXMsgProc - pthread_mutex_unlock () returned.
2010-03-14 12:22:30 winInitMultiWindowWM - DISPLAY=:0.0
2010-03-14 12:22:30 winGetDisplay: DISPLAY=:0.0
2010-03-14 12:22:30 winClipboardProc - Hello
2010-03-14 12:22:30 winProcEstablishConnection - winInitClipboard returned.
2010-03-14 12:22:30 winMultiWindowXMsgProc - DISPLAY=:0.0
2010-03-14 12:22:30 DetectUnicodeSupport - Windows NT/2000/XP
2010-03-14 12:22:30 winGetDisplay: DISPLAY=:0.0
2010-03-14 12:22:30 winInitMultiWindowWM - XOpenDisplay () returned and 
successfully opened the display.
2010-03-14 12:22:30 winMultiWindowXMsgProc - XOpenDisplay () returned and 
successfully opened the display.
2010-03-14 12:22:30 winClipboardProc - DISPLAY=:0.0
2010-03-14 12:22:30 winClipboardProc - XOpenDisplay () r

Re: xterm no longer accepts keyboard input

[Bob Kline]

On 3/14/2010 10:17 AM, Jeff Spirko wrote:

The icon runs from the Windows environment, so the run.exe and
bash.exe wrapper programs are needed to set up the proper cygwin
environment.  Once you're in a cygwin shell, you already have the
cygwin environment set up.  That's why you don't need to type them in
from the command line.

So, they really should be equivalent.
   


I would have thought so, too.  However, the fact remains that the 
outcomes are different for the two methods of starting X.


I can live with working around the second problem (that launching X 
using the shortcut doesn't work at all) by invoking startxwin.exe 
directly.  I'm much more eager to solve the original problem (X no 
longer recognizes input from the keyboard).  So, while I don't want to 
discourage anyone from looking for clues to solving the keyboard input 
problem in the log file from the launch of X which blows up, I am 
focusing on the original problem myself.  Attached is the log file from 
launch of X which does *not* result in the failure dialog window, but 
whose X session is not able to use input from the keyboard.


--
Bob Kline
http://www.rksystems.com
mailto:bkl...@rksystems.com

Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 1.7.5.0 (10705000)
Build Date: 2010-02-25

Contact: cygwin-xfree@cygwin.com
XWin was started with the following command line:

X :0 -multiwindow 

ddxProcessArgument - Initializing default screens
winInitializeDefaultScreens - w 1920 h 1200
winInitializeDefaultScreens - Returning
2010-03-14 12:12:19 (WW) /tmp mounted in textmode
2010-03-14 12:12:19 _XSERVTransSocketOpenCOTSServer: Unable to open socket for 
inet6
2010-03-14 12:12:19 _XSERVTransOpen: transport open failed for inet6/xp:0
2010-03-14 12:12:19 _XSERVTransMakeAllCOTSServerListeners: failed to open 
listener for inet6
2010-03-14 12:12:20 winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1
2010-03-14 12:12:20 (II) xorg.conf is not supported
2010-03-14 12:12:20 (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for 
more information
2010-03-14 12:12:20 LoadPreferences: /cygdrive/c/home/bkline/.XWinrc not found
2010-03-14 12:12:20 LoadPreferences: Loading /etc/X11/system.XWinrc
2010-03-14 12:12:20 LoadPreferences: Done parsing the configuration file...
2010-03-14 12:12:20 winGetDisplay: DISPLAY=:0.0
2010-03-14 12:12:20 winDetectSupportedEngines - Windows NT/2000/XP
2010-03-14 12:12:20 winDetectSupportedEngines - DirectDraw installed
2010-03-14 12:12:20 winDetectSupportedEngines - DirectDraw4 installed
2010-03-14 12:12:20 winDetectSupportedEngines - Returning, supported engines 
0007
2010-03-14 12:12:20 winSetEngine - Multi Window or Rootless => ShadowGDI
2010-03-14 12:12:20 winAdjustVideoModeShadowGDI - Using Windows display depth 
of 32 bits per pixel
2010-03-14 12:12:20 winAllocateFBShadowGDI - Creating DIB with width: 1920 
height: 1200 depth: 32
2010-03-14 12:12:20 winFinishScreenInitFB - Masks: 00ff ff00 00ff
2010-03-14 12:12:20 winInitVisualsShadowGDI - Masks 00ff ff00 00ff 
BPRGB 8 d 24 bpp 32
2010-03-14 12:12:20 null screen fn ReparentWindow
2010-03-14 12:12:20 null screen fn RestackWindow
2010-03-14 12:12:20 InitQueue - Calling pthread_mutex_init
2010-03-14 12:12:20 InitQueue - pthread_mutex_init returned
2010-03-14 12:12:20 InitQueue - Calling pthread_cond_init
2010-03-14 12:12:20 InitQueue - pthread_cond_init returned
2010-03-14 12:12:20 winInitMultiWindowWM - Hello
2010-03-14 12:12:20 winMultiWindowXMsgProc - Hello
2010-03-14 12:12:20 Screen 0 added at XINERAMA coordinate (0,0).
2010-03-14 12:12:20 winInitMultiWindowWM - Calling pthread_mutex_lock ()
2010-03-14 12:12:20 winMultiWindowXMsgProc - Calling pthread_mutex_lock ()
2010-03-14 12:12:20 MIT-SHM extension disabled due to lack of kernel support
2010-03-14 12:12:20 XFree86-Bigfont extension local-client optimization 
disabled due to lack of shared memory support in the kernel
2010-03-14 12:12:20 (II) AIGLX: Loaded and initialized 
/usr/lib/dri/swrast_dri.so
2010-03-14 12:12:20 (II) GLX: Initialized DRISWRAST GL provider for screen 0
2010-03-14 12:12:28 winPointerWarpCursor - Discarding first warp: 960 600
2010-03-14 12:12:28 (--) 3 mouse buttons found
2010-03-14 12:12:28 (--) Setting autorepeat to delay=500, rate=31
2010-03-14 12:12:28 (--) winConfigKeyboard - Layout: "0409" (0409) 
2010-03-14 12:12:28 (--) Using preset keyboard for "English (USA)" (409), type 
"4"
2010-03-14 12:12:28 Rules = "base" Model = "pc105" Layout = "us" Variant = 
"none" Options = "none"
2010-03-14 12:12:28 winInitMultiWindowWM - pthread_mutex_lock () returned.
2010-03-14 12:12:28 winProcEstablishConnection - Hello
2010-03-14 12:12:28 winInitClipboard ()
2010-03-14 12:12:28 winInitMultiWindowWM - pthread_mutex_unlock () returned.
2010-03-14 12:12:28 winMultiWindowXMsgProc - pthread_mutex_lock () returned.
2010-03-14 12:12:28 winGetDisplay: DISPLAY=:0.0
2010-03-14 12:12:28 winProcEstablishConnection - winInitClipboard returned.

Re: xterm no longer accepts keyboard input

[Jeff Spirko]

On Sat, Mar 13, 2010 at 11:39 PM, Bob Kline  wrote:
> Jeff Spirko wrote:
>
>> If you see different results from running startxwin from the command
>> line vs. the icon, you should check to see if you have an old batch
>> file laying around 
>
> Thanks for the suggestion.  I looked again for any old scripts which might
> be found by the shell, but there aren't any.  The difference in behavior may
> be accounted for by the fact that the shortcut doesn't actually have the
> same command line as is recommended by the users' guide, which advises
> running simply /usr/bin/startxwin from a Cygwin shell.  The command line
> used by the shortcut is instead:
>
> C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe

The icon runs from the Windows environment, so the run.exe and
bash.exe wrapper programs are needed to set up the proper cygwin
environment.  Once you're in a cygwin shell, you already have the
cygwin environment set up.  That's why you don't need to type them in
from the command line.

So, they really should be equivalent.


-- 
Jeff Spirko   spi...@gmail.com   spi...@lehigh.edu   WD3V   |=>

The study of non-linear physics is like the study of non-elephant biology.

--
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/

Re: xterm no longer accepts keyboard input

[Bob Kline]

Jeff Spirko wrote:

> If you see different results from running startxwin from the command
> line vs. the icon, you should check to see if you have an old batch
> file laying around 

Thanks for the suggestion.  I looked again for any old scripts which 
might be found by the shell, but there aren't any.  The difference in 
behavior may be accounted for by the fact that the shortcut doesn't 
actually have the same command line as is recommended by the users' 
guide, which advises running simply /usr/bin/startxwin from a Cygwin 
shell.  The command line used by the shortcut is instead:


C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe

--
Bob Kline
http://www.rksystems.com
mailto:bkl...@rksystems.com


--
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/

Re: xterm no longer accepts keyboard input

[Jeff Spirko]

On Sat, Mar 13, 2010 at 4:47 PM, Bob Kline  wrote:
> On 3/13/2010 1:05 PM, Bob Kline wrote:
>>
>> I have used X under Cygwin successfully for years.  Yesterday I did an
>> upgrade of my Cygwin installation and X stopped working.  After struggling
>> to get things working again, I decided to just install Cygwin fresh and
>> start over.  Now I can get the X server started (following the instructions
>> in the Cygwin/X User's Guide, running /usr/bin/startxwin from a Cygwin
>> shell), but xterm windows that I open do not respond to keyboard input.  I
>> looked at the FAQ and found the entry (3.2 I upgraded my X server and now I
>> can't type anything into any X application) which warns against using any
>> older scripts to launch X, but as noted above, I'm invoking the startxwin
>> binary directly.  Any thoughts as to what could be going wrong, given that
>> this is an installation of Cygwin and X from scratch?
>>
>
> Following up on my earlier post, I see that although I am able to start the
> X server if I invoke /usr/bin/startxwin directly from a Cygwin shell, that's
> not *exactly* what the FAQ was suggesting.  What the FAQ document actually
> suggests is that I start the X server by using the shortcut under "Cygwin-X"
> on the start menu.

If you see different results from running startxwin from the command
line vs. the icon, you should check to see if you have an old batch
file laying around using commands like these:
  vdir /usr/bin/startxwin*
  which startxwin
Unfortunately, I can't help with your actual problem, but this may be
complicating things.

-Jeff


-- 
Jeff Spirko   spi...@gmail.com   spi...@lehigh.edu   WD3V   |=>

The study of non-linear physics is like the study of non-elephant biology.

--
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/

Re: xterm + mc problem: messed up output when running commands

[Andy Koppe]

2010/1/7 Andrew Zhezherun:
> I have a weird problem with the latest Cygwin 1.7. It happens with
> both a fresh install on a Windows 7 machine and with an upgraded
> install of Cygwin on a Windows XP machine. When I execute various
> commands from Midnight Commander when it is running under Cygwin/X
> xterm, e.g. cat, the lines are printed with an offset. For example,
> when I run
>
> cat /etc/X11/app-defaults/XTerm
>
> I get the following output on the screen:
>
> -
>        ! VT100s and similar terminals recognize escape sequences
> and control
>            ! characters to which they reply to the host with othe
> r escape sequences,
>                    ! to provide information.  The "resize" progra
> m uses this feature.
> [...]

I find that mc immediately switches back to the folder view. How do
you keep it on the screen? If I add a 'sleep 3' after the cat, I see
that the lines are arranged as intended, without the staircase effect.

The carriage return after the newline is normally added by the pseudo
terminal driver. This is controlled by the stty onlcr setting.

Andy

--
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/

Re: xterm + mc problem: messed up output when running commands

[Andrew Zhezherun]

Hi All,

Somehow Cygwin mailing list shows  characters in my previous
message; it should have been all spaces instead.

Best Regards,
Andrew

--
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/

Re: xterm process exists but no window appears when XWin Server launched (current release)

[Yaakov (Cygwin/X)]

On 30/12/2009 11:52, Timares, Brian (Harris Corp.) wrote:

I checked the FAQ, looked over the XWin.0 log, looked over the cygcheck
output which shows:
Sonic Solutions burning software containing DLA component
Detected: Named process.

ZoneAlarm Personal Firewall
Detected: HKLM Registry Key, Named file.

I had rebooted since last I used the Sonic Solutions (I can remove it if
it is worth trying), the ZoneAlarm I have no control over (nor the other
security-related items).


BLODA often needs to be completely uninstalled, followed by a reboot, 
for it not to interfere.  ZA is a known troublemaker wrt Cygwin, so if 
you can't remove it, then I'm not sure that we'll be able to help.



Yaakov
Cygwin/X

--
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/

Re: xterm doesn't open on start

[Larry Hall (Cygwin X)]

On 12/03/2009 10:47 PM, Timares, Brian (Harris Corp.) wrote:

I do appreciate all the terrific replies--I've been on the net for
awhile and this is one of the friendliest lists I've been on.


Do you mind if I frame this and hang it on the Cygwin home page. ;-)

--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
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/

RE: xterm doesn't open on start

[Timares, Brian (Harris Corp.)]

Linda Walsh wrote:
>Timares, Brian (Patriot) wrote:
>> Any other ideas?  I keep updating but so far all I can do is launch
>> an Xterm manually and clean up, then everything seems fine til the
>> next time I relaunch it.

>   Do you have
>DISPLAY=:0
>set in your Windows environment?

I didn't, but I do now.

I am forced to use Outlook so I forwarded the more extensive email to my
personal account so I can edit it more easily/correctly and because my
work got pretty busy.

I reverted to 1.5 to see if that would work better, it doesn't really,
so I'll try to install 1.7 in parallel when I get a chance (I have
servers doing things now so I have to let it alone for awhile).

I do appreciate all the terrific replies--I've been on the net for
awhile and this is one of the friendliest lists I've been on.


Brian Timares
oh and then there is the 7-year-old, he is taking lots of time :)

--
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/

Re: xterm doesn't open on start

[Linda Walsh]

Timares, Brian (Patriot) wrote:

Any other ideas?  I keep updating but so far all I can do is launch
an Xterm manually and clean up, then everything seems fine til the
next time I relaunch it.

---
Do you have
DISPLAY=:0
set in your Windows environment?

(system properties, Advanced, Env Vars).
I put mine in the System Environment so it's
there no matter how I'm logged in.


--
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/

Re: xterm doesn't open on start (was: checkX problems)

[Lothar Brendel]

Christopher Faylor wrote:

On Thu, Dec 03, 2009 at 12:25:14AM +0100, Lothar Brendel wrote:

More information as promised, after getting the new run and checkX
(run2) packages announced this morning.

$ checkX -v
run2 0.3.2


0.3.2 announced? I didn't get any such message, and setup still only
offers 
0.3.1-1 to me.


http://cygwin.com/ml/cygwin-announce/2009-12/msg2.html
http://cygwin.com/ml/cygwin/2009-12/msg00079.html


Thanx. I had just focused on cygwin-xfree, but indeed run2 is more general.

Ciao
   Lothar


--
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/

Re: xterm doesn't open on start (was: checkX problems)

[Christopher Faylor]

On Thu, Dec 03, 2009 at 12:25:14AM +0100, Lothar Brendel wrote:
>>More information as promised, after getting the new run and checkX
>>(run2) packages announced this morning.
>>
>> $ checkX -v
>> run2 0.3.2
>
>0.3.2 announced? I didn't get any such message, and setup still only offers 
>0.3.1-1 to me.

http://cygwin.com/ml/cygwin-announce/2009-12/msg2.html
http://cygwin.com/ml/cygwin/2009-12/msg00079.html

cgf

--
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/

Re: xterm doesn't open on start (was: checkX problems)

[Lothar Brendel]

Hi!


More information as promised, after getting the new run and checkX
(run2) packages announced this morning.

$ checkX -v
run2 0.3.2


0.3.2 announced? I didn't get any such message, and setup still only offers 
0.3.1-1 to me.




vhaisbtim...@isb-timaresbrian-lt ~
$ XWin -multiwindow &
[1] 5004

vhaisbtim...@isb-timaresbrian-lt ~
$ Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 1.7.1.0 (10701000)
Build Date: 2009-11-11
- UNQUOTE -


Yes, the log didn't show anything unusual. (BTW: You got it from 
/var/log/XWin.log.0, not from stdout, right?)




After quitting and destroying any processes from a DOS window, trying
startxwin.bat with echo on

First off all, nothing appeared (no X icon, no window).


[...]


At this point I run "Cygwin Bash Shell" and from that window I run
startxwin.bat and it works fine, even after closing the Cygwin Bash
Shell.


Brief, running ``startxwin.bat'' from the Cygwin Bash Shell works while 
running it from a Windows Prompt (DOS window) does not. Right?


Ok, same check over there. In the Windows Prompt:

C:\cygwin\bin\run XWin

What does happen? Nothing?

Asks
   Lothar


--
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/

RE: xterm doesn't open on start (was: checkX problems)

[Timares, Brian (Harris Corp.)]

More information as promised, after getting the new run and checkX
(run2) packages announced this morning.

$ checkX -v
run2 0.3.2

- QUOTE -
Lothar Brendel wrote:
>Timares, Brian (Patriot) wrote:

>> The X window showed up, but it blew up real good (the windows
>> disappeared, then the X icon.  After a rebootit
>> didn't launch at all.  I ran startxwin.sh from the Cygwin Bash
>> Shell, and it started.
>
>At least we're getting *somewhere* :-)
>
>Ok, what happens when entering the two vital commands by hand in the
the 
>Cygwin Bash Shell (waiting with the second until the X-icon has
appeared)?
>
>XWin -multiwin &
>xterm -display :0
>
>Reproducible success?

I'll try again from home (I went into the office to simplify things).
Here
is what I got (sorry for the word-wrap):

vhaisbtim...@isb-timaresbrian-lt ~
$ XWin -multiwindow &
[1] 5004

vhaisbtim...@isb-timaresbrian-lt ~
$ Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 1.7.1.0 (10701000)
Build Date: 2009-11-11
- UNQUOTE -

Trying from home with the VPN active, again, it works; here is the ps
from the xterm that showed up:
vhaisbtim...@isb-timaresbrian-lt ~
$ ps
  PIDPPIDPGID WINPID  TTY  UIDSTIME COMMAND
 3556   13556   35560 180490 11:11:27 /usr/bin/bash
 6020   16020   6020? 180490 11:11:28
/usr/bin/ssh-agent
I294435562944   36880 180490 11:12:07 /usr/bin/XWin
 593635565936   40600 180490 11:12:56 /usr/bin/xterm
 478059364780   18401 180490 11:12:57 /usr/bin/bash
  9324780 932   46961 180490 11:12:59 /usr/bin/ps

After quitting and destroying any processes from a DOS window, trying
startxwin.bat with echo on

First off all, nothing appeared (no X icon, no window).  Here is what ps
in a DOS window shows after running startxwin.bat:
C:\cygwin\bin>ps
  PIDPPIDPGID WINPID  TTY  UIDSTIME COMMAND
 1656   11656   16560 180490 10:57:45 /usr/bin/bash
 5516   15516   5516? 180490 10:57:47
/usr/bin/ssh-agent
I467616561656   44760 180490 10:57:47
/usr/bin/ssh-add
I2024   12024   20241 180490 11:09:16 /usr/bin/bash
 1464   11464   14642 180490 11:09:40 /usr/bin/ps

Here is the output with blank lines and REM lines removed (I added the
2nd SET DISPLAY, CYGWIN is set to tty elsewhere as well as here, I don't
know what that is at the end of the PATH):
C:\cygwin\bin>startxwin.bat 
C:\cygwin\bin>SET DISPLAY=127.0.0.1:0.0 
C:\cygwin\bin>SET CYGWIN=tty tty tty 
C:\cygwin\bin>if defined CYGWIN_ROOT goto :OK 
C:\cygwin\bin>SET RUN=C:\cygwin\bin\\..\bin\run -p /usr/bin 
C:\cygwin\bin>SET
PATH=C:\cygwin\bin\\..\bin;C:\cygwin\bin\\..\bin;C:\WINDOWS\system32;C:\
WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\IBM\Personal
Communications\;C:\Program Files\IBM\Trace Facility\;C:\Program
Files\Common Files\InterSystems\Cache;C:\Program Files\Windows
Imaging\;C:\Program Files\ActivIdentity\ActivClient\;P 
C:\cygwin\bin>SET XAPPLRESDIR=
C:\cygwin\bin>SET XCMSDB=
C:\cygwin\bin>SET XKEYSYMDB=
C:\cygwin\bin>SET XNLSPATH=
C:\cygwin\bin>if not exist C:\cygwin\bin\\..\tmp\.X11-unix\X0 goto
CLEANUP-FINISH
C:\cygwin\bin>attrib -s C:\cygwin\bin\\..\tmp\.X11-unix\X0
C:\cygwin\bin>del C:\cygwin\bin\\..\tmp\.X11-unix\X0
C:\cygwin\bin>if exist C:\cygwin\bin\\..\tmp\.X11-unix rmdir
C:\cygwin\bin\\..\tmp\.X11-unix
C:\cygwin\bin>SET DISPLAY=127.0.0.1:0.0
C:\cygwin\bin>C:\cygwin\bin\\..\bin\run -p /usr/bin bash -l -c "XWin
-multiwindow -clipboard -silent-dup-error -winkill -emulate3buttons 100"

C:\cygwin\bin>C:\cygwin\bin\\..\bin\run -p /usr/bin checkX -wait -d
127.0.0.1:0.0 -t 12
C:\cygwin\bin>C:\cygwin\bin\\..\bin\run -p /usr/bin xterm -e
/usr/bin/bash -l
C:\cygwin\bin>

At this point I run "Cygwin Bash Shell" and from that window I run
startxwin.bat and it works fine, even after closing the Cygwin Bash
Shell.


Brian Timares

--
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/

RE: xterm doesn't open on start (was: checkX problems)

[Timares, Brian (Patriot)]

Lothar Brendel wrote:
>Timares, Brian (Patriot) wrote:

>> The X window showed up, but it blew up real good (the windows
>> disappeared, then the X icon.  After a rebootit
>> didn't launch at all.  I ran startxwin.sh from the Cygwin Bash
>> Shell, and it started.
>
>At least we're getting *somewhere* :-)
>
>Ok, what happens when entering the two vital commands by hand in the
the 
>Cygwin Bash Shell (waiting with the second until the X-icon has
appeared)?
>
>XWin -multiwin &
>xterm -display :0
>
>Reproducible success?

I'll try again from home (I went into the office to simplify things).
Here
is what I got (sorry for the word-wrap):

vhaisbtim...@isb-timaresbrian-lt ~
$ XWin -multiwindow &
[1] 5004

vhaisbtim...@isb-timaresbrian-lt ~
$ Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 1.7.1.0 (10701000)
Build Date: 2009-11-11

Contact: cygwin-xfree@cygwin.com

XWin was started with the following command line:

XWin -multiwindow

_XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6
_XSERVTransOpen: transport open failed for inet6/isb-timaresbrian-lt:0
_XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6
winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1
(II) xorg.conf is not supported
(II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more
information
winPrefsLoadPreferences: /etc/X11/system.XWinrc
LoadPreferences: Done parsing the configuration file...
winGetDisplay: DISPLAY=:0.0
winDetectSupportedEngines - Windows NT/2000/XP
winDetectSupportedEngines - DirectDraw installed
winDetectSupportedEngines - DirectDraw4 installed
winDetectSupportedEngines - Returning, supported engines 0007
winSetEngine - Multi Window or Rootless => ShadowGDI
winAdjustVideoModeShadowGDI - Using Windows display depth of 32 bits per
pixel
winAllocateFBShadowGDI - Creating DIB with width: 3200 height: 1200
depth: 32
winFinishScreenInitFB - Masks: 00ff ff00 00ff
winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24
bpp 32
null screen fn ReparentWindow
null screen fn RestackWindow
InitQueue - Calling pthread_mutex_init
InitQueue - pthread_mutex_init returned
InitQueue - Calling pthread_cond_init
InitQueue - pthread_cond_init returned
winInitMultiWindowWM - Hello
Screen 0 added at XINERAMA coordinate (0,0).
winMultiWindowXMsgProc - Hello
winInitMultiWindowWM - Calling pthread_mutex_lock ()
winMultiWindowXMsgProc - Calling pthread_mutex_lock ()
MIT-SHM extension disabled due to lack of kernel support
XFree86-Bigfont extension local-client optimization disabled due to lack
of shar
ed memory support in the kernel
(II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so
(II) GLX: Initialized DRISWRAST GL provider for screen 0
winPointerWarpCursor - Discarding first warp: 1600 600
(--) 3 mouse buttons found
(--) Setting autorepeat to delay=500, rate=31
(--) winConfigKeyboard - Layout: "0409" (0409)
(--) Using preset keyboard for "English (USA)" (409), type "4"
Rules = "base" Model = "pc105" Layout = "us" Variant = "none" Options =
"none"
winInitMultiWindowWM - pthread_mutex_lock () returned.
winInitMultiWindowWM - pthread_mutex_unlock () returned.
winMultiWindowXMsgProc - pthread_mutex_lock () returned.
winGetDisplay: DISPLAY=:0.0
winMultiWindowXMsgProc - pthread_mutex_unlock () returned.
winInitMultiWindowWM - DISPLAY=:0.0
winGetDisplay: DISPLAY=:0.0
winMultiWindowXMsgProc - DISPLAY=:0.0
winProcEstablishConnection - Hello
winInitClipboard ()
winProcEstablishConnection - winInitClipboard returned.
winClipboardProc - Hello
DetectUnicodeSupport - Windows NT/2000/XP
winGetDisplay: DISPLAY=:0.0
winClipboardProc - DISPLAY=:0.0
winInitMultiWindowWM - XOpenDisplay () returned and successfully opened
the disp
lay.
winMultiWindowXMsgProc - XOpenDisplay () returned and successfully
opened the di
splay.
winClipboardProc - XOpenDisplay () returned and successfully opened the
display.

From the xterm, which has stayed open:
vhaisbtim...@isb-timaresbrian-lt ~
$ ps
  PIDPPIDPGID WINPID  TTY  UIDSTIME COMMAND
 5516   15516   55160 180490 16:51:58 /usr/bin/bash
 3868   13868   3868? 180490 16:52:02
/usr/bin/ssh-agent
 500455165004   46120 180490 16:54:07 /usr/bin/XWin
 4064551640649240 180490 16:56:09 /usr/bin/xterm
 601240646012   51441 180490 16:56:10 /usr/bin/bash
 218460122184   42401 180490 16:56:21 /usr/bin/ps
 

Brian Timares

--
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/

Re: xterm doesn't open on start (was: checkX problems)

[Lothar Brendel]

Timares, Brian (Patriot) wrote:

Lothar Brendel wrote:

Timares, Brian (Patriot) wrote:

Lothar Brendel wrote:
$ checkX -v
run2 0.3.0



So, you've got the situation I surmised in
http://cygwin.com/ml/cygwin-xfree/2009-11/msg00200.html


Grr, I saw that, went and _thought_ I got the right version but
it seems the right version wasn't avaiable at the time and
I got fooled by the 0.3.0-1 to think 0.3.1.  I have carefully
upgraded, and when running Setup17.exe I saw it wanted to
revert, but I didn't let it.


Exactly, the "evil setup" tries to revert it to 0.3.0-1 every time. Quite 
easy to forget keeping an eye on that when tinkering with other packages.




The X window showed up, but it blew up real good (the windows
disappeared, then the X icon.  After a rebootit
didn't launch at all.  I ran startxwin.sh from the Cygwin Bash
Shell, and it started.


At least we're getting *somewhere* :-)

Ok, what happens when entering the two vital commands by hand in the the 
Cygwin Bash Shell (waiting with the second until the X-icon has appeared)?


XWin -multiwin &
xterm -display :0

Reproducible success?

Asks
   Lothar


--
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/

RE: xterm doesn't open on start (was: checkX problems)

[Timares, Brian (Patriot)]

Lothar Brendel wrote:
>Timares, Brian (Patriot) wrote:
>> Lothar Brendel wrote:
>> $ checkX -v
>> run2 0.3.0

>So, you've got the situation I surmised in 
>http://cygwin.com/ml/cygwin-xfree/2009-11/msg00200.html

Grr, I saw that, went and _thought_ I got the right version but
it seems the right version wasn't avaiable at the time and
I got fooled by the 0.3.0-1 to think 0.3.1.  I have carefully
upgraded, and when running Setup17.exe I saw it wanted to
revert, but I didn't let it.

The X window showed up, but it blew up real good (the windows
disappeared, then the X icon.  After a rebootit
didn't launch at all.  I ran startxwin.sh from the Cygwin Bash 
Shell, and it started.  After quitting that I launched it from 
startxwin.bat and the windows showed up but they died after a 
second at most and no X icon in the taskbar tray..

Same thing after reboot.  This time I after launching from a 
Cygwin Bash Shell (successfully) I closed the cygwin bash 
shell and the X Window died.  The X server kept running.


Brian

--
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/

Re: xterm doesn't open on start (was: checkX problems)

[Lothar Brendel]

Timares, Brian (Patriot) wrote:

Lothar Brendel wrote:


[...]


Thus, once more: What does
   md5sum /usr/bin/checkX
yield?

a827086e9cbb331ef49d416b3cb1b135 or a36409714f5ce9d01e8dfb4cb38b7216?


The 2nd:

vhaisbtim...@isb-timaresbrian-lt ~
$ md5sum /usr/bin/checkX
a36409714f5ce9d01e8dfb4cb38b7216 */usr/bin/checkX


... and that's the checksum for the version 0.3.0 of checkX!



$ checkX -v
run2 0.3.0


Ok, yes, that's an easier version check :-)

So, you've got the situation I surmised in 
http://cygwin.com/ml/cygwin-xfree/2009-11/msg00200.html


I.e. you *don't* have the new version (0.3.1) of the run2-package installed. 
Install that and retry, please.


Ciao
   Lothar


--
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/

RE: xterm doesn't open on start (was: checkX problems)

[Timares, Brian (Patriot)]

Lothar Brendel wrote:
>Timares, Brian (Patriot) wrote:
>> Just to be clear from the start, Cygwin 1.7 not 1.5.
>
>ACK.

*blush*  Sorry!

...
>Thus, once more: What does
>md5sum /usr/bin/checkX
>yield?
>
>a827086e9cbb331ef49d416b3cb1b135 or a36409714f5ce9d01e8dfb4cb38b7216?

The 2nd:

vhaisbtim...@isb-timaresbrian-lt ~
$ md5sum /usr/bin/checkX
a36409714f5ce9d01e8dfb4cb38b7216 */usr/bin/checkX

$ checkX -v
run2 0.3.0


Brian

--
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/

Re: xterm not working

[Charles Wilson]

Yaakov (Cygwin/X) wrote:
> On 29/11/2009 21:28, Joe Java wrote:
>>Gone for Thanksgiving break, return and update cygwin, and now
>> xterm does not show anymore.  I have not upgraded to the latest 1.7 (I
>> am waiting for the official release).  I read the other messages and
>> nothing seems to work.
>>
>>Does anyone have a SIMPLE solution to this problem.
> 
> Downgrade the termcap package until there is another update thereto.

Should be fixed by termcap-5.7_20091114-4 (cygwin-1.5) or
termcap-5.7_20091114-13 (cygwin-1.7).

--
Chuck

--
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/

Re: xterm doesn't open on start (was: checkX problems)

[Lothar Brendel]

Timares, Brian (Patriot) wrote:

Just to be clear from the start, Cygwin 1.7 not 1.5.


ACK.

[...]


i) ```time checkX -t 12''
How long does it take?


vhaisbtim...@isb-timaresbrian-lt ~
$ time checkX -t 12

real0m0.098s
user0m0.046s
sys 0m0.031s


And *that* shouldn't happen!

I don't quite get your VPN setup, but it being active *may* cause a delay in 
getting up the X server, and that *may* cause xterm to "loose its patience".




ii) ``startxwin.sh''
Any messages?


Yes, see below, but after reviewing it all I tried it with various
items on and
off and having the One-VA VPN client (Cisco VPN Client 5) off makes
the difference.
It is odd, though, that if I run startxwin.sh again, it works the
second time, even though the VPN is on.


Not really, I think. The message


xterm Xt error: Can't open display: 127.0.0.1:0.0


indicates that xterm didn't find the X server being up. And the reason is 
``checkX'' not doing its job, namely waiting until it is really up.


If you then start ``startxwin.sh'' again, it complains about an X server 
already being up, but at least xterm can finally connect.


Thus, once more: What does
   md5sum /usr/bin/checkX
yield?

a827086e9cbb331ef49d416b3cb1b135 or a36409714f5ce9d01e8dfb4cb38b7216?

Asks
   Lothar


--
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/

RE: xterm doesn't open on start (was: checkX problems)

[Timares, Brian (Patriot)]

I wrote:
>And I tried to make this clear.
  email -^

*sigh*

Sorry!


Brian

--
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/

RE: xterm doesn't open on start (was: checkX problems)

[Timares, Brian (Patriot)]

Just to be clear from the start, Cygwin 1.7 not 1.5.  And I tried to
make this clear.  And I tried to not let Outlook's word-wrap inter-
fere.

Lothar Brendel wrote:
>Timares, Brian (Patriot) wrote:
>> Lothar Brendel wrote:
>>> Timares, Brian (Patriot) wrote:
 Lothar Brendel wrote:
> My guess: It's the old checkX-problem again because you're using
> version
> 0.3.0-1 of the run2-package. Do to some reason unknown to me,
> that's the default version. But we need 0.3.1-1, which you only
> get when 
 Tried it, including changing XWin Server to
 C:\cygwin\bin\run2.exe /usr/bin/startxwin.bat
>> 
>>> That was a misunderstanding. I didn't mean to use ``run2'' instead
of
>>> ``run'' but to verify that the version of the *package* 'run2'
>>> (containing ``checkX'') is the most recent one. Did you do that?
>> 
>> You were clear.  I did get the 0.3.1-1 and it showed up just as you
>> said.
>
>IC, but could you please perform the following two tests nevertheless?
>First open Cygwin's standard bash console, then enter:

Ran Cygwin Bash Shell, which has a Target of "C:\cygwin\Cygwin.bat  ":

Initialising new SSH agent...
succeeded
Enter passphrase for /home/VHAISBTIMARB/.ssh/id_rsa:
Bad passphrase, try again for /home/VHAISBTIMARB/.ssh/id_rsa:
Identity added: /home/VHAISBTIMARB/.ssh/id_rsa
(/home/VHAISBTIMARB/.ssh/id_rsa)

vhaisbtim...@isb-timaresbrian-lt ~
$ ps
  PIDPPIDPGID WINPID  TTY  UIDSTIME COMMAND
 4676   14676   46760 180490 09:16:53 /usr/bin/bash
 4824   14824   4824? 180490 09:16:54
/usr/bin/ssh-agent
 554846765548   16080 180490 09:17:30 /usr/bin/ps

>i) ```time checkX -t 12''
>How long does it take?

vhaisbtim...@isb-timaresbrian-lt ~
$ time checkX -t 12

real0m0.098s
user0m0.046s
sys 0m0.031s

>ii) ``startxwin.sh''
>Any messages?

Yes, see below, but after reviewing it all I tried it with various items
on and
off and having the One-VA VPN client (Cisco VPN Client 5) off makes the
difference.
It is odd, though, that if I run startxwin.sh again, it works the second
time, even
though the VPN is on.  Also, if I quit X Windows (making sure the
ssh-agent process
is gone) and relaunch everything works fine.  It is just the first time
that I have
trouble if the VPN is on.

I believe the VPN hadn't caused me problems with Cygwin's X Windows
implementation, 
but I can't say that with 100% certainty.  Anyway, here is the key
difference to
no VPN versus VPN on:

diff working.txt broken.txt
7a8
> xterm Xt error: Can't open display: 127.0.0.1:0.0
...

Long version at the bottom.

I note that "9.11. Cannot Open Display: 127.0.0.1:0.0" on the referenced

page
http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-cannot-open-display 
apparently needs the text changed (added?) to: 
"Can't open display: 127.0.0.1:0.0".

1) Why does launching it again work?  Because it doesn't need me to
enter my key's password?
2) Why does quitting/launching after it has worked once work?  Again, is
it because of it not needing my input?
3) If I go my preferred 'XWin Server' to launch it, it doesn't work, not

even the X icon shows up.  If I launch that again, it works.  If I open 
a cygwin bash shell (before the 2nd launch) and check processes it
shows:
vhaisbtim...@isb-timaresbrian-lt ~
$ ps
  PIDPPIDPGID WINPID  TTY  UIDSTIME COMMAND
 3076   13076   30760 180490 14:01:32 /usr/bin/bash
  600   1 600600? 180490 14:01:47
/usr/bin/ssh-agent
I172430763076   33360 180490 14:01:47
/usr/bin/ssh-add
 3304   13304   33041 180490 14:02:05 /usr/bin/bash
 318833043188   25681 180490 14:02:09 /usr/bin/ps

What I want is to have an alias to XWin Server (currently its Target is
C:\cygwin\bin\run.exe /usr/bin/startxwin.bat) in my startup items so I
always get X Windows, and always am prompted in an xterm for my ssh
key's
password.

What I'll try next:  Update to the current version of cygwin (hopefully 
the new termcap gets rid of the 'clear screen after viewing man page or 
running vi' issue AKA the -X option in less AKA the 
'XTerm*titeInhibit: true' issue) and see if that helps, but it appears 
I just have to be careful to launch the VPN after starting X Windows 
after launching a cygwin bash shell.

-- long (complete) version of startxwin.sh with VPN on:
vhaisbtim...@isb-timaresbrian-lt ~
$ startxwin.sh
Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 1.7.1.0 (10701000)
Build Date: 2009-11-11

Contact: cygwin-xfree@cygwin.com

XWin was started with the following command line:

XWin -multiwindow -clipboard -silent-dup-error


vhaisbtim...@isb-timaresbrian-lt ~
$ xterm Xt error: Can't open display: 127.0.0.1:0.0
_XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6
_XSERVTransOpen: transport open failed for inet6/isb-timaresbrian-lt:0
_XSERVTransMakeAllCOTSServerListener

Re: xterm not working

[Charles Wilson]

Corinna Vinschen wrote:

> Isn't xterm linked against ncurses?

The new 1.7 xterm is.  The old 1.5 xterm is still termcap based.

> Why does it break on a termcap
> file at all?  

1.5 only, and it breaks because the termcap file was NOT generated using
'-r' to limit the number of allowed ':tc=' options in a single termcap
definition.

Will be fixed soon.

--
chuck

--
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/

Re: xterm not working

[Charles Wilson]

Thomas Dickey wrote:
> On Mon, 30 Nov 2009, Andy Koppe wrote:
>> The latest termcap, which was automatically generated from terminfo,
>> has entries longer than 1K in it.
> 
> ok... (I thought cygwin was using GNU termcap, which supposedly works
> with longer entries - though I recall _that_ being fixed more than once).

Red herring.  The problem IS with the latest /etc/termcap, but it isn't
an "entry too long" problem.  It is an "entries contain multiple :tc="
options problem. This can be fixed by generating /etc/termcap using
tic's '-r' option.  Look for a new /etc/termcap soon.

It'd be nice if xterm didn't coredump, but I suspect the coredump
actually occurs inside code from the (obsoleted on cygwin) libtermcap.a
-- so there's nothing to fix, except to recompile xterm on cygwin to not
use libtermcap and instead use libncurses.

Which is exactly what Yaakov has already done, for cygwin-1.7 only.

--
Chuck


--
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/

Re: xterm not working

[Andy Koppe]

2009/11/30 Corinna Vinschen:
>> >   Gone for Thanksgiving break, return and update cygwin, and now xterm 
>> > does not show anymore.  I have not upgraded to the latest 1.7 (I am 
>> > waiting for the official release).  I read the other messages and nothing 
>> > seems to work.
>> >
>> >   Does anyone have a SIMPLE solution to this problem.
>>
>> Downgrade the termcap package until there is another update thereto.
>
> Isn't xterm linked against ncurses?  Why does it break on a termcap
> file at all?  There's a big chance that I just missed the thread in
> which this has been discussed.  A pointer would be nice.

It doesn't answer your questions, but here it is:

http://cygwin.com/ml/cygwin/2009-11/msg00936.html

Andy

--
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/

Re: xterm not working

[Corinna Vinschen]

On Nov 29 22:42, Yaakov S wrote:
> On 29/11/2009 21:28, Joe Java wrote:
> >   Gone for Thanksgiving break, return and update cygwin, and now xterm does 
> > not show anymore.  I have not upgraded to the latest 1.7 (I am waiting for 
> > the official release).  I read the other messages and nothing seems to work.
> >
> >   Does anyone have a SIMPLE solution to this problem.
> 
> Downgrade the termcap package until there is another update thereto.

Isn't xterm linked against ncurses?  Why does it break on a termcap
file at all?  There's a big chance that I just missed the thread in
which this has been discussed.  A pointer would be nice.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
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/

Re: xterm not working

[Joe Java]

Thank you!  xterm now works again.

The solution was:
Run the Cygwin "setup" program, and on the "Select Packages" page, 
choose "Utils" and within there choose "termcap"
and downgrade to version "20050421-1".



  

--
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/

Re: xterm not working

[Thomas Dickey]

On Mon, 30 Nov 2009, Andy Koppe wrote:


2009/11/30 Thomas Dickey:

  Gone for Thanksgiving break, return and update cygwin, and now xterm
does not show anymore.  I have not upgraded to the latest 1.7 (I am waiting
for the official release).  I read the other messages and nothing seems to
work.

  Does anyone have a SIMPLE solution to this problem.


Downgrade the termcap package until there is another update thereto.


I didn't see that one (what was the issue?)


The latest termcap, which was automatically generated from terminfo,
has entries longer than 1K in it.


btw, infocmp -Cr should limit that by default, unless -T option is added

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
--
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/

Re: xterm not working

[Thomas Dickey]

On Mon, 30 Nov 2009, Andy Koppe wrote:


2009/11/30 Thomas Dickey:

  Gone for Thanksgiving break, return and update cygwin, and now xterm
does not show anymore.  I have not upgraded to the latest 1.7 (I am waiting
for the official release).  I read the other messages and nothing seems to
work.

  Does anyone have a SIMPLE solution to this problem.


Downgrade the termcap package until there is another update thereto.


I didn't see that one (what was the issue?)


The latest termcap, which was automatically generated from terminfo,
has entries longer than 1K in it.


ok... (I thought cygwin was using GNU termcap, which supposedly works
with longer entries - though I recall _that_ being fixed more than once).

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
--
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/

Re: xterm not working

[Andy Koppe]

2009/11/30 Thomas Dickey:
>>>   Gone for Thanksgiving break, return and update cygwin, and now xterm
>>> does not show anymore.  I have not upgraded to the latest 1.7 (I am waiting
>>> for the official release).  I read the other messages and nothing seems to
>>> work.
>>>
>>>   Does anyone have a SIMPLE solution to this problem.
>>
>> Downgrade the termcap package until there is another update thereto.
>
> I didn't see that one (what was the issue?)

The latest termcap, which was automatically generated from terminfo,
has entries longer than 1K in it.

Andy

--
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/

Re: xterm not working

[Thomas Dickey]

On Sun, 29 Nov 2009, Yaakov (Cygwin/X) wrote:


On 29/11/2009 21:28, Joe Java wrote:
   Gone for Thanksgiving break, return and update cygwin, and now xterm 
does not show anymore.  I have not upgraded to the latest 1.7 (I am waiting 
for the official release).  I read the other messages and nothing seems to 
work.


   Does anyone have a SIMPLE solution to this problem.


Downgrade the termcap package until there is another update thereto.


I didn't see that one (what was the issue?)

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
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/

Re: xterm not working

[Yaakov (Cygwin/X)]

On 29/11/2009 21:28, Joe Java wrote:

   Gone for Thanksgiving break, return and update cygwin, and now xterm does 
not show anymore.  I have not upgraded to the latest 1.7 (I am waiting for the 
official release).  I read the other messages and nothing seems to work.

   Does anyone have a SIMPLE solution to this problem.


Downgrade the termcap package until there is another update thereto.


Yaakov
Cygwin/X

--
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/

Re: xterm doesn't open on start (was: checkX problems)

[Lothar Brendel]

Timares, Brian (Patriot) wrote:

Lothar Brendel wrote:

Timares, Brian (Patriot) wrote:

Lothar Brendel wrote:

My guess: It's the old checkX-problem again because you're using
version
0.3.0-1 of the run2-package. Do to some reason unknown to me,
that's the default version. But we need 0.3.1-1, which you only
get when 

Tried it, including changing XWin Server to
C:\cygwin\bin\run2.exe /usr/bin/startxwin.bat



That was a misunderstanding. I didn't mean to use ``run2'' instead of
``run'' but to verify that the version of the *package* 'run2'
(containing ``checkX'') is the most recent one. Did you do that?


You were clear.  I did get the 0.3.1-1 and it showed up just as you
said.


IC, but could you please perform the following two tests nevertheless?
First open Cygwin's standard bash console, then enter:

i) ```time checkX -t 12''
How long does it take?

ii) ``startxwin.sh''
Any messages?

Ciao
   Lothar


--
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/

RE: xterm doesn't open on start (was: checkX problems)

[Timares, Brian (Patriot)]

Lothar Brendel wrote:
>Timares, Brian (Patriot) wrote:
>> Lothar Brendel wrote:
>>> My guess: It's the old checkX-problem again because you're using
>>> version
>>> 0.3.0-1 of the run2-package. Do to some reason unknown to me, that's
>>> the default version. But we need 0.3.1-1, which you only get when
>> Tried it, including changing XWin Server to
>> C:\cygwin\bin\run2.exe /usr/bin/startxwin.bat

>That was a misunderstanding. I didn't mean to use ``run2'' instead of 
>``run'' but to verify that the version of the *package* 'run2'
(containing 
>``checkX'') is the most recent one. Did you do that?

You were clear.  I did get the 0.3.1-1 and it showed up just as you
said.
It didn't help, so then I tried changing run to run2, but changed it all
back since it didn't help.


Brian
by the way, Outlook makes proper quoting a royal pain :-/

--
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/

Re: xterm doesn't open on start (was: checkX problems)

[Lothar Brendel]

Timares, Brian (Patriot) wrote:

Lothar Brendel wrote:


[...]


My guess: It's the old checkX-problem again because you're using
version
0.3.0-1 of the run2-package. Do to some reason unknown to me, that's
the default version. But we need 0.3.1-1, which you only get when
explicitely (triple-)clicking its circular double-arrow (how's that
thingy called BTW?) in the Utils category.


Tried it, including changing XWin Server to
C:\cygwin\bin\run2.exe /usr/bin/startxwin.bat


That was a misunderstanding. I didn't mean to use ``run2'' instead of 
``run'' but to verify that the version of the *package* 'run2' (containing 
``checkX'') is the most recent one. Did you do that?


Asks
   Lothar


--
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/

Re: xterm doesn't open on start (was: checkX problems)

[Lothar Brendel]

Timares, Brian (Patriot) wrote:

[...]


Nothing works.  1.7 doesn't work for me out-of-the-box (yes, I ripped
it all out and tried it fresh :-)

I open a DOS box and check processes and see bash running with an l or
a 1 in the left columnn, but nothing appears.  If I launch an Xterm
it opens up.  It seems some of the login thing happen, but when I add
in my ssh-agent starting script, since it requires input, it fails
(http://mah.everybody.org/docs/ssh is the script I use).

Any other ideas?


Doen't look like the issue 
http://cygwin.com/ml/cygwin-xfree/2009-11/msg00174.html to me.


My guess: It's the old checkX-problem again because you're using version 
0.3.0-1 of the run2-package. Do to some reason unknown to me, that's the 
default version. But we need 0.3.1-1, which you only get when explicitely 
(triple-)clicking its circular double-arrow (how's that thingy called BTW?) 
in the Utils category.


Maybe Chuck can tell why we don't get the new version as default.

Ciao
   Lothar


--
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/

Re: Xterm hangs with latest Cygwin (-62?)

[Corinna Vinschen]

On Oct  5 17:46, Yaakov S wrote:
> On 05/10/2009 13:47, Corinna Vinschen wrote:
>> --- sys.c.ORIG   2009-10-05 19:23:58.0 +0200
>> +++ sys.c2009-10-05 19:18:34.0 +0200
>> @@ -408,7 +408,11 @@ openTty(char *line)
>>   int rc;
>>   int tty = -1;
>>
>> +#ifdef __CYGWIN__
>> +tty = open(line, O_RDWR);
>> +#else
>>   tty = open(line, O_RDWR | O_NOCTTY);
>> +#endif
>
> For portability, perhaps this should also be #ifdef TIOCSCTTY, if these two 
> sections go hand-in-hand?

Sure, sounds much better than #ifdef __CYGWIN__.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
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/

Re: Xterm hangs with latest Cygwin (-62?)

[Corinna Vinschen]

On Oct  5 23:47, Christopher Faylor wrote:
> On Mon, Oct 05, 2009 at 05:46:21PM -0500, Yaakov (Cygwin/X) wrote:
> >On 05/10/2009 13:47, Corinna Vinschen wrote:
> >> And here's the problem.  Cygwin doesn't have TIOCSCTTY, and the only way
> >> to make a terminal a controlling tty in Cygwin is to call open() on it,
> >> which tcsh misses to do.  Bash, however, calls open("/dev/tty", O_RDWR),
> >> so bash doesn't have this problem.
> >
> >Out of curiosity, what about implementing TIOCSCTTY?
> 
> It's something that we really should do.  I'll put it on my todo list.

Cool.  TIOCNOTTY would probably be helpful as well.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
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/