Re: XFree86 command line installation

[Igor Pechtchanski]

Karthik,

Reposting the same question every 24 hours will not get you closer to the
answer.

On Wed, 27 Jul 2005, Rajagopalan, Karthik wrote:

> Hi,
>
> This is a question about Cygwin-XFree86 installation.

To dispell a myth, there is no such thing as a separate XFree86
installation.  There is a Cygwin installer, named setup.exe, which can be
used to install *any* Cygwin packages, including the Cygwin/X ones.

Which, BTW, makes this question less appropriate for the cygwin-xfree
list, and more appropriate for the main Cygwin list, which is where I'm
redirecting this reply.  Please remove cygwin-xfree from further
discussion unless it comes to Cygwin/X-specific points.

> I am trying to install XFree86 from command line in silent mode without
> any user interface.

Another note: the Cygwin/X implementation has switched from the XFree86
codebase to the X.org codebase a long while ago.  I suspect you want to
install the current versions of the X packages.  Calling them XFree86 is
likely to result in confusion.

> But on using the command structure
>
> setup.exe -L -R "c:\test\xfree86" -q -l "c:\cygwin" -n -5
>
> I am seeing the progress bar dialog. Is it not possible to install
> completely in silent mode?

No, it is currently not possible.  The Cygwin installer is a graphical
application.  You can run it in unattended mode, but you cannot tell it to
not create a Window.

That said, there may be other tools that allow opening a GUI application
without a window.  You could use one of those tools to invoke setup.exe,
which will hide the main window.  Before you ask, I'm not aware of any
Cygwin tools that would do this.  I'd suggest checking the MS Knowledge
Base.

HTH,
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA

--
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: Xfree86 Removed Packages

[Alexander Gottwald]

Aicha Said(ACES) wrote:

> Dear all,
>
> I have installed cygwin but I realised that all Xfree86 package has been
> removed, I didn't pay to much attention to that considering that X11 was 
> there.
> But when I type the startx command I only have a black X window coming up,
> which doesn't seem right, as I had installed it before and it use to be green
> and white and with multiple windows, this one is just a prompt in black with
> yellow font.
> Also I am trying to install ns-2 on this platform and the fact that some of 
> the
> xfree libraries are not installed seems to be causing problems.  How coud I
> install Xfree separatly from cygwin?

install the xorg-x11-* packages. Selecting xorg-x11-base and X-startup-scripts
should be sufficient


NP: VNV Nation - Kingdom
-- 
 [EMAIL PROTECTED]
 http://www.gotti.org   ICQ: 126018723

Re: XFree86-base-4.3.0-3

[Frédéric L. W. Meunier]

On Sun, 14 Mar 2004, Harold L Hunt II wrote:

> Frédéric L. W. Meunier wrote:
>
> > On Sun, 14 Mar 2004, Frédéric L. W. Meunier wrote:
> >
> > libintl and
> >>libintl1 removed, and libintl2 added ?
> >
> > gettext too ? It isn't needed at runtime.
>
> I'll need a more thorough investigation before I touch these.
> I wasn't able to find anything using libintl* at all during
> my initial investigation, but I would appreciate it if you
> would look into it further and tell us what your method was
> (e.g. run cygpath against *.exe and *.dll in the bin package
> and report which of the three are referenced and which are
> not).  Same for gettext... I thought there was a script or
> something that used it and people were complaining a long
> time ago that it wasn't being installed automatically.
> Search the mailing list archives, it is probably one of the
> only messages referencing gettext.

It was just a guess. Since all packages were updated in 2003,
libintl and libintl1 are from 2001, and libintl2 from 2002 and
2003, I thought it you needed libintl, the latter would be the
requirement. But you're right. Here nothing returns it.
Actually, I don't do a full install, and the only things still
using libintl1 are: textutils grep findutils. Guess what ?
They're all from 2002.

And the only packages with a requirement for gettext are
mod_php4 and XFree86-base.

-- 
http://www.pervalidus.net/contact.html

Re: XFree86-base-4.3.0-3

[Harold L Hunt II]

Frédéric L. W. Meunier wrote:

On Sun, 14 Mar 2004, Frédéric L. W. Meunier wrote:


setup.hint:

requires: cygwin cygipc expat termcap libncurses6 terminfo zlib
gettext libintl libintl1 ash pcre XFree86-bin XFree86-etc
XFree86-lib XFree86-fenc XFree86-fnts XFree86-startup-scripts
XFree86-xserv
Shouldn't libncurses6 be replaced by libncurses7,
That much I believe and have changed in the new release of -bin.  I also 
moved most of the requirements that were specific to -bin from -base to 
-bin.  There probably remains some work to be done on this.

libintl and
libintl1 removed, and libintl2 added ?
gettext too ? It isn't needed at runtime.
I'll need a more thorough investigation before I touch these.  I wasn't 
able to find anything using libintl* at all during my initial 
investigation, but I would appreciate it if you would look into it 
further and tell us what your method was (e.g. run cygpath against *.exe 
and *.dll in the bin package and report which of the three are 
referenced and which are not).  Same for gettext... I thought there was 
a script or something that used it and people were complaining a long 
time ago that it wasn't being installed automatically.  Search the 
mailing list archives, it is probably one of the only messages 
referencing gettext.

The same in "Runtime requirements"  and "Build requirements"
for XFree86-base-4.3.0.README.
Again, fixed libncurses, but leaving the others alone unless we change them.

You know, now that the source packages are available, feel free to send 
me a comprehensive patch against the *.hint files that fixes this 
properly.  It is difficult when someone asks me to make one change 
because it often ends up requiring that I change several .hint files. 
So, if you would like it to be improved, then put the time into doing 
the job right and send me the diff... otherwise I am likely to keep 
screwing it up as I make little changes.

Harold

Re: XFree86-base-4.3.0-3

[Frédéric L. W. Meunier]

On Sun, 14 Mar 2004, Frédéric L. W. Meunier wrote:

> setup.hint:
>
> requires: cygwin cygipc expat termcap libncurses6 terminfo zlib
> gettext libintl libintl1 ash pcre XFree86-bin XFree86-etc
> XFree86-lib XFree86-fenc XFree86-fnts XFree86-startup-scripts
> XFree86-xserv
>
> Shouldn't libncurses6 be replaced by libncurses7, libintl and
> libintl1 removed, and libintl2 added ?

gettext too ? It isn't needed at runtime.

> The same in "Runtime requirements"  and "Build requirements"
> for XFree86-base-4.3.0.README.

-- 
http://www.pervalidus.net/contact.html

Re: XFree86-xserv-4.3.0-51 Performance Improvement

[Takuma Murakami]

That is just a starting point of my optimization.
4.3.0-52 release should be more impressive :)

Takuma Murakami


> Takuma Murakami made an improvement to the multi-window code in the 
> 4.3.0-51 release that restricts redraws to only the changed portions of 
> windows.  My earlier review of the original code made me believe that 
> the code was redrawing the entire contents of each window, regardless of 
> whether they had changed any or not, so I believe that Takuma's change 
> is correct.  In addition, I tested Takuma's change on a program that was 
> notorious for exhibiting bad performance in multi-window mode: xfig. 
> 4.3.0-50 requires 7 seconds to start xfig and there is lots of screen 
> flashing during that startup process; other X Servers on Windows did not 
> have this problem.  4.3.0-51 takes 2 seconds to start xfig and there is 
> no longer any screen flashing.
> 
> Takuma's changes are great!  :)
> 
> Harold

Re: XFree86-xserv-4.3.0-47 copy/paste trouble and BadAtom.

[Alexander Gottwald]

Harold L Hunt II wrote:

> I was wondering if this change in behavior meant that our multi-window
> window manager would be unable to connect to the server when an ssh
> session had been opened on the local machine already.  I did some
> testing but was not able to cause this to happen.  In any case, my great
> ideas for what was causing this problem are useless :)

More explanation i got from http://www.xfree86.org/~herrb/security.pdf

Any "normal" xclient connects in trusted mode. But openssh now connects
in untrusted mode. This is for "security" reasons. I'll describe later
why I think it's useless.

In untrusted mode some calls (esp. GetProperty and SetProperty) will fail.
This can be configured in /usr/X11R6/lib/X11/xserver/SecurityPolicy.


# Allow reading of application resources, but not writing.
property RESOURCE_MANAGER   rootar iw
property SCREEN_RESOURCES   rootar iw

# Ignore attempts to use cut buffers.  Giving errors causes apps to crash,
# and allowing access may give away too much information.
property CUT_BUFFER0rootirw
property CUT_BUFFER1rootirw


The CUT_BUFFER entries may explain why the problems with copy&paste started.

One way to solve the new problems is to modify the SecurityPolicy and
distribute it with the xserver. But this is complicated because
a) we have to figure out all properties which are safe to export
b) we may get responsible and sued for any security problem we create with
   these changes.

The other way is to enable X11ForwardTrusted by default. But again it is
(in my opinion) "dangerous" to explicitly disable a security method.

But anyway. I think the change to untrusted clients is very shortminded.

Most users will get annoyed with not working software and skip the whole
X11Forwarding issue and use "xhost +" again. This is a severe loss of
security.

If a lot of software requires access to properties which are blocked in
untrusted mode then most people will enable the switch. Only a few will
ever want the clients to connect in untrusted mode.

bye
ago

NP: grauzone.04-02-15
-- 
 [EMAIL PROTECTED]
 http://www.gotti.org   ICQ: 126018723

Re: XFree86-xserv-4.3.0-47 copy/paste trouble and BadAtom.

[Harold L Hunt II]

Alexander,

Alexander Gottwald wrote:

Virgilio, Vincent wrote:


when using ssh and X-forwarding (now with ForwardX11Trusted = yes)? It
looks like I have cookies in the right place. xauth report the same ones
on both the local and remote machine. Though, I have gnawing concerns
about the host part of the display name in those cookies; the
(alphabetic) cases do not match. Hum. I should try to share cookies
again (xauth extract, scp, xauth merge).


It is an issue how the xserver handles untrusted clients. Until openssh
3.8 all clients forwarded by ssh were trusted by default. Now they are
untrusted by default.
Wow, good thing I haven't commented on this yet.  I upgraded to OpenSSH 
3.8 when it came out and since then have noticed that all of my ssh 
connections (even those done by cvs) were enabling X11 forwarding by 
default.  I thought this was interesting, particularly since it wasn't 
mentioned in the release notes.  I was just about to describe how this 
change was made in OpenSSH 3.8 and how I am really smart because I am 
the only one that noticed it... then I realized:

1) My ssh_config is modified to enable X11Forwarding (I don't have to 
use -X, but I always do because I had forgotten that I changed this 
default).

2) I had installed SFU 3.5 at about the same time that I upgraded to 
OpenSSH 3.8.  Turns out that SFU 3.5 adds DISPLAY=127.0.0.1:0.0 to the 
global environment variables.

The combination of these two meant that ssh was acting as if it was 
getting passed a -X and it had a valid DISPLAY value at all times, so it 
was enabling X11 forwarding at all times.

I was wondering if this change in behavior meant that our multi-window 
window manager would be unable to connect to the server when an ssh 
session had been opened on the local machine already.  I did some 
testing but was not able to cause this to happen.  In any case, my great 
ideas for what was causing this problem are useless :)

Harold

Re: XFree86-xserv-4.3.0-47 copy/paste trouble and BadAtom.

[Alexander Gottwald]

Virgilio, Vincent wrote:

> when using ssh and X-forwarding (now with ForwardX11Trusted = yes)? It
> looks like I have cookies in the right place. xauth report the same ones
> on both the local and remote machine. Though, I have gnawing concerns
> about the host part of the display name in those cookies; the
> (alphabetic) cases do not match. Hum. I should try to share cookies
> again (xauth extract, scp, xauth merge).

It is an issue how the xserver handles untrusted clients. Until openssh
3.8 all clients forwarded by ssh were trusted by default. Now they are
untrusted by default.

I have no complete overview what the X11 Security Extension works and
which functions are prohibited but I'll take a look and try to match
this with the described error pattern.

Stay tuned.
ago
-- 
 [EMAIL PROTECTED]
 http://www.gotti.org   ICQ: 126018723

RE: XFree86-xserv-4.3.0-47 copy/paste trouble and BadAtom.

[Andrew Braverman]

That solved my problem as well.  Thanks.

-Andy

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Igor Pechtchanski
> Sent: Thursday, February 26, 2004 3:01 PM
> To: [EMAIL PROTECTED]
> Cc: Keith Thompson
> Subject: Re: XFree86-xserv-4.3.0-47 copy/paste trouble and BadAtom.
> 
> 
> On Thu, 26 Feb 2004, Keith Thompson wrote:
> 
> > It looks like the problem has to do with the new OpenSSH package.
> >
> > I tried logging into my Solaris box using SecureCRT, a 
> Windows SSH client,
> > and then starting up an xterm from there; cut-and-paste 
> worked correctly.
> >
> > Now I've re-upgraded all the XFree86 packages and 
> downgraded OpenSSH to
> > OpenSSH_3.7.1p2, and cut-and-paste still works correctly.
> >
> > It looks like there's a problem with X forwarding in the new OpenSSH
> > package.
> 
> >From the new OpenSSH-3.8p1-1 announcement:
> 
> * ssh(1) now uses untrusted cookies for X11-Forwarding.
>   Some X11 applications might need full access to the X11 server,
>   see ForwardX11Trusted in ssh(1) and xauth(1) for more information.
> 
> Haven't looked further...
>   Igor
> -- 
>   http://cs.nyu.edu/~pechtcha/
>   |\  _,,,---,,_  [EMAIL PROTECTED]
> ZZZzz /,`.-'`'-.  ;-;;,_  [EMAIL PROTECTED]
>  |,4-  ) )-,_. ,\ (  `'-' Igor Pechtchanski, Ph.D.
> '---''(_/--'  `-'\_) fL   a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!
> 
> "I have since come to realize that being between your mentor 
> and his route
> to the bathroom is a major career booster."  -- Patrick Naughton
> 
> 

Re: XFree86-xserv-4.3.0-47 copy/paste trouble and BadAtom.

[Virgilio, Vincent]

Keith and Igor, thanks for this thread

http://cygwin.com/ml/cygwin-xfree/2004-02/msg00288.html.

The reasoning is still beyond my ken, mostly because I haven't yet
digested the right set of man pages.

Nonetheless, it solved my problem, as described in

http://cygwin.com/ml/cygwin-xfree/2004-02/msg00262.html,

which was my just dessert for wielding Cygwin setup.exe so freely.

(I'm not on the cygwin-xfree list anymore, hence the links instead of a
simpler 'reply'.)

Incidentally, should I be seeing

Warning: No xauth data; using fake authentication data for X11
forwarding.

when using ssh and X-forwarding (now with ForwardX11Trusted = yes)? It
looks like I have cookies in the right place. xauth report the same ones
on both the local and remote machine. Though, I have gnawing concerns
about the host part of the display name in those cookies; the
(alphabetic) cases do not match. Hum. I should try to share cookies
again (xauth extract, scp, xauth merge).

Ultimately, the above message is only unaesthetic; I haven't noticed
that it impacts performance.

Thanks and regards,

Vince Virgilio


This email and any files transmitted with it are proprietary and intended solely for 
the use of the individual or entity to whom they are addressed. If you have received 
this email
in error please notify the sender. Please note that any views or opinions presented in 
this email are solely those of the author and do not necessarily represent those of 
ITT Industries, Inc.
The recipient should check this email and any attachments for the presence of viruses. 
ITT Industries accepts no liability for any damage caused by any virus transmitted by 
this
email.

Re: XFree86-xserv-4.3.0-47 copy/paste trouble and BadAtom.

[Keith Thompson]

On Thu, Feb 26, 2004 at 03:00:42PM -0500, Igor Pechtchanski wrote:
> On Thu, 26 Feb 2004, Keith Thompson wrote:
> 
> > It looks like the problem has to do with the new OpenSSH package.
> >
> > I tried logging into my Solaris box using SecureCRT, a Windows SSH client,
> > and then starting up an xterm from there; cut-and-paste worked correctly.
> >
> > Now I've re-upgraded all the XFree86 packages and downgraded OpenSSH to
> > OpenSSH_3.7.1p2, and cut-and-paste still works correctly.
> >
> > It looks like there's a problem with X forwarding in the new OpenSSH
> > package.
> 
> >From the new OpenSSH-3.8p1-1 announcement:
> 
> * ssh(1) now uses untrusted cookies for X11-Forwarding.
>   Some X11 applications might need full access to the X11 server,
>   see ForwardX11Trusted in ssh(1) and xauth(1) for more information.

Thanks.  Adding
ForwardX11Trusted yes
to my $HOME/.ssh/config did the trick.

(Oddly, I never saw the problem on my Windows 2000 system, only on
Windows XP.)

-- 
Keith Thompson (The_Other_Keith) [EMAIL PROTECTED]  
San Diego Supercomputer Center   <*>  
Schroedinger does Shakespeare: "To be *and* not to be"

Re: XFree86-xserv-4.3.0-47 copy/paste trouble and BadAtom.

[Keith Thompson]

It looks like the problem has to do with the new OpenSSH package.

I tried logging into my Solaris box using SecureCRT, a Windows SSH client,
and then starting up an xterm from there; cut-and-paste worked correctly.

Now I've re-upgraded all the XFree86 packages and downgraded OpenSSH to
OpenSSH_3.7.1p2, and cut-and-paste still works correctly.

It looks like there's a problem with X forwarding in the new OpenSSH
package.

-- 
Keith Thompson (The_Other_Keith) [EMAIL PROTECTED]  
San Diego Supercomputer Center   <*>  
Schroedinger does Shakespeare: "To be *and* not to be"

Re: XFree86-xserv-4.3.0-47 copy/paste trouble and BadAtom.

[Igor Pechtchanski]

On Thu, 26 Feb 2004, Keith Thompson wrote:

> It looks like the problem has to do with the new OpenSSH package.
>
> I tried logging into my Solaris box using SecureCRT, a Windows SSH client,
> and then starting up an xterm from there; cut-and-paste worked correctly.
>
> Now I've re-upgraded all the XFree86 packages and downgraded OpenSSH to
> OpenSSH_3.7.1p2, and cut-and-paste still works correctly.
>
> It looks like there's a problem with X forwarding in the new OpenSSH
> package.

>From the new OpenSSH-3.8p1-1 announcement:

* ssh(1) now uses untrusted cookies for X11-Forwarding.
  Some X11 applications might need full access to the X11 server,
  see ForwardX11Trusted in ssh(1) and xauth(1) for more information.

Haven't looked further...
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

Re: XFree86-xserv-4.3.0-47 copy/paste trouble and BadAtom.

[Keith Thompson]

Another couple of data points:

I don't need so many xterms to reproduce the problem.  I can just ssh
from baldur (in a non-xterm window) to elmak, then run a single xterm
from there, and I see the same symptom.

If I run rxvt rather than xterm, I get:

rxvt: XError: Request: 18 . 0, Error: 5

emacs (in X mode) gives me a segmentation fault.

xedit gives me the same error as xterm.

-- 
Keith Thompson (The_Other_Keith) [EMAIL PROTECTED]  
San Diego Supercomputer Center   <*>  
Schroedinger does Shakespeare: "To be *and* not to be"

Re: XFree86-xserv-4.3.0-47 copy/paste trouble and BadAtom.

[Keith Thompson]

In my previous message, I missed a major piece of the puzzle.

The xterm windows that are dying mysteriously are running on a Solaris
system, not on my laptop under Cygwin.

Here's the scenario.  My laptop is "baldur" (IBM Thinkpad T40, Windows
XP, Cygwin); my Sun workstation is "elmak" (Sun Blade 100, Solaris 8).

On Baldur, I run the Hummingbird Exceed version 7 X server and the fvwm2
window manager (neither of which seems to be relevant).  From an xterm
window on baldur, I run

xterm -e ssh elmak &

This gives me a shell on elmak running in an xterm window on baldur.
With OpenSSH X11 forwarding, I have $DISPLAY set to 'elmak:7.0'.

On elmak, I run

xterm &

Now I have a second shell on elmak, this one in an xterm window running
on elmak but displayed on baldur.  No further forwarding is needed,
so the new shell also has $DISPLAY set to 'elmak:7.0'.

I can run X clients, such as xlogo, from any of these three windows,
and they display properly.

In the first two xterm windows, I can cut-and-paste.  In the third (the
Solaris xterm), if I try to highlight a region of text, the xterm dies
as soon as I release the mouse button, and the parent window gets:

xterm:  warning, error event receieved:
X Error of failed request:  BadAtom (invalid Atom parameter)
  Major opcode of failed request:  18 (X_ChangeProperty)
  Atom id in failed request:  0xb6
  Serial number of failed request:  277
  Current serial number in output stream:  279

This problem first showed up in the last few days, when I updated a
bunch of XFree86 packages through the Cygwin setup utility.

This isn't specific to Solaris.  I get the same symptom with an
xterm running on a variety of systems, including Red Hat with
XFree86-4.3.0-2.90.55, AIX, and SunOS 4.1.3 with X11R6.3.

-- 
Keith Thompson (The_Other_Keith) [EMAIL PROTECTED]  
San Diego Supercomputer Center   <*>  
Schroedinger does Shakespeare: "To be *and* not to be"

Re: XFree86-xserv-4.3.0-47 copy/paste trouble and BadAtom.

[Keith Thompson]

"Virgilio, Vincent"  writes:
> I just updated to XFree86-xserv-4.3.0-47 from -46, and now have two
> problems:
> 
> 1. Clipboard integration is weakened in both 'twm' and multiwindow. I
> can copy/paste between X indows, but not between X and Windows (!).
> 
> 2. Tk/tcl widgets fail. I run one remotely for local display, and then
> see in the remote window:
> 
> X Error of failed request: BadAtom (invalid Atom parameter)
>   Major opcode of failed request: 18 (X_ChangeProperty)
>   Atom id in failed request: 0x114
>   Serial number of failed request: 370
>   Current serial number in output stream: 372
> 
> (I had to type that in by hand because of problem #1)
> 
> I'm not complaining: cygwin-xfree86 is still a great product. I thought
> this report might be helpful to the developers, if it's not just me.

It's not just you, and it's not the server.

I'm running Cygwin under Windows XP on an IBM Thinkpad T40.  I'm not
using the Cygwin X server; instead, I'm using the Hummingbird Exceed
server, version 7.  I'm running multiple xterm windows; my window manager
is fvwm2.  I've seen the same error using the Cygwin XFree86 server.

Just now, I tried to cut some text from an xterm window.  When I released
the mouse button, the xterm window died.  The parent window had an error
message identical to the one above (except that the atom id and serial
numbers were different).

I've tried backtracking to an older version of xterm, but so far I
haven't been able to correct the problem.  I have the latest versions
of just about everything, except that I've downgraded XFree86-bin from
4.3.0-9 to 4.3.0-8.

Here's the output of "cygcheck -c | grep XFree86":

XFree86-base4.3.0-1OK
XFree86-bin 4.3.0-8OK
XFree86-bin-icons   4.3.0-6OK
XFree86-doc 4.3.0-1OK
XFree86-etc 4.3.0-6OK
XFree86-f1004.2.0-3OK
XFree86-fcyr4.2.0-3OK
XFree86-fenc4.2.0-3OK
XFree86-fnts4.2.0-3OK
XFree86-fscl4.2.0-3OK
XFree86-fsrv4.3.0-7OK
XFree86-html4.3.0-1OK
XFree86-jdoc4.3.0-1OK
XFree86-lib 4.3.0-1OK
XFree86-lib-compat  4.3.0-2OK
XFree86-man 4.3.0-3OK
XFree86-nest4.3.0-5OK
XFree86-prog4.3.0-13   OK
XFree86-prt 4.3.0-5OK
XFree86-ps  4.3.0-1OK
XFree86-startup-scripts 4.2.0-5OK
XFree86-vfb 4.3.0-5OK
XFree86-xserv   4.3.0-47   OK
XFree86-xwinclip4.3.0-2OK

-- 
Keith Thompson (The_Other_Keith) [EMAIL PROTECTED]  
San Diego Supercomputer Center   <*>  
Schroedinger does Shakespeare: "To be *and* not to be"

Re: XFree86-xserv-4.3.0-46 'test' release

[Andreas Seidl]

Harold L Hunt II wrote:

mirrors.kernel.org has it already.

I just marked 4.3.0-46 as 'curr' instead of 'test'.
FWIW, -46 worked for me.

Andreas.

Re: XFree86-xserv-4.3.0-46 'test' release

[Harold L Hunt II]

mirrors.kernel.org has it already.

I just marked 4.3.0-46 as 'curr' instead of 'test'.

Harold

Andreas Seidl wrote:

Harold L Hunt II wrote:

I just posted XFree86-xserv-4.3.0-46 as a 'test' package.  Please try 
this package if you are having problems with segfaults in 
XFree86-xserv-4.3.0-45.  The only difference between these two 
packages is that in -46 I did a 'make clean && make' in 
xc/programs/Xserver/hw/xwin, rather than just a 'make' on the updated 
files.  Please report if -46 fixes your problems.


Is there already a mirror in setup.exe which has it?

Andreas.

Re: XFree86-xserv-4.3.0-46 'test' release

[Andreas Seidl]

Harold L Hunt II wrote:

I just posted XFree86-xserv-4.3.0-46 as a 'test' package.  Please try 
this package if you are having problems with segfaults in 
XFree86-xserv-4.3.0-45.  The only difference between these two packages 
is that in -46 I did a 'make clean && make' in 
xc/programs/Xserver/hw/xwin, rather than just a 'make' on the updated 
files.  Please report if -46 fixes your problems.
Is there already a mirror in setup.exe which has it?

Andreas.

Re: XFree86-xserv-4.3.0-40

[Walter Haidinger]

On Mon, 12 Jan 2004, Harold L Hunt II wrote:

> The clipboard code has been released in the new 'curr' version of
> XFree86-xserv-4.3.0-40.

I'm glad to report that clipboard cut&paste from/to Win32/X11 works now
under XP+SP1. Btw, AltGr works also too with recent OS (not Solaris 2.6).

Walter

[results] Re: XFree86-xserv-4.3.0-40

[Sylvain Petreolle]

> 4) Add the '-clipboard' command-line parameter to the line that
> launches
> XWin.exe.  For example, change 'XWin -multiwindow' to 'XWin
> -multiwindow
> -clipboard'.
OS : XP Home SP1 / French

Ran :
export DISPLAY=:0
XWin -clipboard& ; twm& ; xterm&

Windows to X11: ok.
X11 to Windows : ok.

Ran :
XWin -multiwindow -clipboard&
xterm&

Windows to X11: ok.
X11 to Windows : ok.


=
Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net)
 ICQ #170597259
Say NO to software patents
Dites NON aux brevets logiciels

"What if tomorrow the War could be over ?" Morpheus, in "Reloaded".

_
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com

Re: XFree86-xserv-4.3.0-38 test results

[Harold L Hunt II]

Andrew,

Andrew Braverman wrote:
[...]  For now, I would just drop the xhost command from
your startup file.


No problem.  I can deal with it as long as you are aware of the issue.
Okay.  I think it needs to be fixed eventually so that the problem is 
not repeatedly reported.

On a different note, I have noticed that the X clipboard
will transfer to

windows as long as the data is highlighted.  Once the data
is unhighlighted

(i.e. typing "clear") the text is still in the X buffer
(middle button or

shift insert pastes correctly), but the windows clipboard is empty.
That is an interesting point that I had thought of, but didn't really
want to think hard about :)  I spent about 12 hours coding this up...
everytime I thought I had it, I realized that more basic changes were
needed in the clipboard code.  Now I have it working, I believe.


It seems to work now.  Thanks.
No problem.

I have made your request work only for the PRIMARY and CLIPBOARD
selections.  It won't matter if the X client still has data in the
SECONDARY selection, because we do not monitor that selection.  So,
don't complain if you can still paste in one or two X apps but not in
Win32 :)


I try not to COMPLAIN about anything. :-)  Seriously, though - I do realize
how much time and energy are put into this project by the few core people
and though I will report issues I see or ask questions, I will never
complain about what is or is not done.  You guys do too much work to deserve
that.  One of these days, I will make enough time to make some contributions
of my own - and then I MIGHT have a right to complain a little.  You guys
have done a wonderful job, and as many have said before, we appreciate your
work.  Thank you.
Sorry.  My "complain" should be read as more of a "I am already aware of 
this problem, so it doesn't have to be mentiond" and it was really 
written for other readers, not for you.  I don't think you are 
complaining :)  It is just that if others see this in the future, I 
don't want them saying "me too" if they notice this problem.

OS: Windows XP

Language: English

Win32->X11 Copy and Paste: Worked

X11->Win32 Copy and Paste: Worked

Xdmcp: Did Not Try
Thanks for testing!

Harold

Re: XFree86-xserv-4.3.0-38 Request for Test Results

[Walter Haidinger]

On Mon, 12 Jan 2004, Benjamin Riefenstahl wrote:

> This one is probably ERROR_INVALID_HANDLE (6).  Walter, you could
> could verify this by running "net helpmsg 6" in a DOS box and see if
> that gives the same text.

It says "The handle is invalid". That is, same error message but in 
English this time. Odd.

Walter

Re: XFree86-xserv-4.3.0-38 Request for Test Results

[Walter Haidinger]

On Mon, 12 Jan 2004, Harold L Hunt II wrote:

> I still need to see the XWin.log to make sure that the clipboard client 
> started properly.  I am waiting to release until I solve your problem, 
> so please send it soon.

Just sent it to your private address!
Why didn't you say that I'd post it anyways?

Walter

Re: XFree86-xserv-4.3.0-38 Request for Test Results

[Kensuke Matsuzaki]

Walter and Harold,

FormatMessage translates.

MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT)
should be 
MAKELANGID(LANG_ENGLISH,SUBLANG_ENGLISH_US)
by the thought of sending log. I thought it is better for user to read.

--
Kensuke Matsuzaki
mailto:[EMAIL PROTECTED]
http://peppermint.jp

Re: XFree86-xserv-4.3.0-38 Request for Test Results

[Benjamin Riefenstahl]

Hi Harold, Walter,


> Walter Haidinger wrote:
>> winTopLevelWindowProc - BitBlt failed: Das Handle ist ungültig

Harold L Hunt II <[EMAIL PROTECTED]> writes:
> I have not localized the error messages to German.

That part of the error message looks like it was converted from a
Windows error code with the FormatMessage API.  FormatMessage is
localized (for those kind of log messages it's a good idea to output
the original error number, too).

This one is probably ERROR_INVALID_HANDLE (6).  Walter, you could
could verify this by running "net helpmsg 6" in a DOS box and see if
that gives the same text.


benny

Re: XFree86-xserv-4.3.0-38 Request for Test Results

[Harold L Hunt II]

Walter,

Walter Haidinger wrote:
On Mon, 12 Jan 2004, Harold L Hunt II wrote:


Walter,

I have not localized the error messages to German.  Did you translate 
that yourself or are you running some other person's compilation of 
XWin.exe?


No, I've _not_ done any localization - I've copied the line "as is" and
I've downloaded -38 using setup.exe from mirror ftp.univie.ac.at today.
Please note that the error message is mixed english/german. Perhaps the
trailing part originates from German Windows XP? Just a guess, though.
Oops, you are right.  We query Win32 for the error message; that part is 
in German.

In fact, there is no other errline but the one below after the X-Server 
logs that it has started up:
I still need to see the XWin.log to make sure that the clipboard client 
started properly.  I am waiting to release until I solve your problem, 
so please send it soon.

Harold

Re: XFree86-xserv-4.3.0-38 Request for Test Results

[Benjamin Riefenstahl]

Hi Harold,


  OS:
Windows 2000, SP4

  Language:
English, German keyboard

  Win32->X11 Copy and Paste, X11->Win32 Copy and Paste: 
Latin-1 works

Non-Latin-1 (Unicode) doesn't work (doesn't work with xwinclip
either, though)

  Xdmcp: 
Did Not Try


benny

Re: XFree86-xserv-4.3.0-38 Request for Test Results

[Walter Haidinger]

On Mon, 12 Jan 2004, Harold L Hunt II wrote:

> Walter,
> 
> I have not localized the error messages to German.  Did you translate 
> that yourself or are you running some other person's compilation of 
> XWin.exe?

No, I've _not_ done any localization - I've copied the line "as is" and
I've downloaded -38 using setup.exe from mirror ftp.univie.ac.at today.

Please note that the error message is mixed english/german. Perhaps the
trailing part originates from German Windows XP? Just a guess, though.

In fact, there is no other errline but the one below after the X-Server 
logs that it has started up:
...
WinInitMultiWindowWM - XOpenDisplay () returned and successfully opened
the display.
winTopLevelWindowProc - BitBlt failed: Das Handle ist ungültig

winTopLevelWindowProc - BitBlt failed: Das Handle ist ungültig

winTopLevelWindowProc - BitBlt failed: Das Handle ist ungültig
...

Walter
 

Re: XFree86-xserv-4.3.0-38 Request for Test Results

[Harold L Hunt II]

Walter,

I have not localized the error messages to German.  Did you translate 
that yourself or are you running some other person's compilation of 
XWin.exe?

If you did the translation yourself, please send in /tmp/XWin.log.  I 
need to see what messages are missing, not just what is there.

Harold

Walter Haidinger wrote:

On Mon, 12 Jan 2004, Harold L Hunt II wrote:


Walter,

Can you send in your /tmp/XWin.log from a time when this fails?


There is just one (german) message indicating that the handle is invalid 
(ungültig in German):
winTopLevelWindowProc - BitBlt failed: Das Handle ist ungültig

Please note that it is like if X11 and Win32 clipboards are totally
distinct, i.e. in can cut&paste X11<->X11 windows but not to or from Win32
windows.
Walter

Re: XFree86-xserv-4.3.0-38 Request for Test Results crash

[Holger Krull]

How do i test server reset?
I've just logged out from my xdmcp session. wdm then displays the login screen again.
That leads to a server crash here.
The login screen reappears, but the moment i type in the password it ends.
This happens when no clipboard selection was done and when the clipboard 
was last copyied in X11.
If i put something in the clipboard in win before logoff, i'm able to 
relogin.

  Holger

XWin.log from crash with selection in X11:

ddxProcessArgument - Initializing default screens
winInitializeDefaultScreens - w 1280 h 960
winInitializeDefaultScreens - Returning
OsVendorInit - Creating bogus screen 0
(EE) Unable to locate/open config file
InitOutput - Error reading config file
winDetectSupportedEngines - Windows NT/2000/XP
winDetectSupportedEngines - DirectDraw installed
winDetectSupportedEngines - Allowing PrimaryDD
winDetectSupportedEngines - DirectDraw4 installed
winDetectSupportedEngines - Returning, supported engines 001f
InitOutput - g_iNumScreens: 1 iMaxConsecutiveScreen: 1
winScreenInit - dwWidth: 1280 dwHeight: 960
winSetEngine - Using Shadow DirectDraw NonLocking
winAdjustVideoModeShadowDDNL - Using Windows display depth of 32 bits 
per pixel
winCreateBoundingWindowWindowed - User w: 1280 h: 960
winCreateBoundingWindowWindowed - Current w: 1280 h: 960
winAdjustForAutoHide - Original WorkArea: 0 0 926 1280
winAdjustForAutoHide - Adjusted WorkArea: 0 0 926 1280
winCreateBoundingWindowWindowed - WindowClient w 1274 h 895 r 1274 l 0 b 
895 t 0
winCreateBoundingWindowWindowed -  Returning
winCreatePrimarySurfaceShadowDDNL - Creating primary surface
winCreatePrimarySurfaceShadowDDNL - Created primary surface
winCreatePrimarySurfaceShadowDDNL - Attached clipper to primary surface
winAllocateFBShadowDDNL - lPitch: 5096
winAllocateFBShadowDDNL - Created shadow pitch: 5096
winAllocateFBShadowDDNL - Created shadow stride: 1274
winFinishScreenInitFB - Masks: 00ff ff00 00ff
winInitVisualsShadowDDNL - Masks 00ff ff00 00ff BPRGB 8 d 24 
bpp 32
winCreateDefColormap - Deferring to fbCreateDefColormap ()
winFinishScreenInitFB - returning
winScreenInit - returning
InitOutput - Returning.
MIT-SHM extension disabled due to lack of kernel support
XFree86-Bigfont extension local-client optimization disabled due to lack 
of shared memory support in the kernel
(--) Setting autorepeat to delay=500, rate=31
(--) winConfigKeyboard - Layout: "0407" (0407)
(--) Using preset keyboard for "German (Germany)" (407), type "4"
(EE) No primary keyboard configured
(==) Using compiletime defaults for keyboard
Rules = "xfree86" Model = "pc105" Layout = "de" Variant = "(null)" 
Options = "(null)"
Error opening keymap file de, reverting to defaults
winPointerWarpCursor - Discarding first warp: 637 447
winBlockHandler - Releasing pmServerStarted
winBlockHandler - pthread_mutex_unlock () returned
winProcEstablishConnection - Hello
winProcEstablishConnection - Xdmcp enabled, waiting to start clipboard 
client until fourth call.
winProcEstablishConnection - Hello
winProcEstablishConnection - Xdmcp enabled, waiting to start clipboard 
client until fourth call.
winProcEstablishConnection - Hello
winProcEstablishConnection - Xdmcp enabled, waiting to start clipboard 
client until fourth call.
winInitClipboard ()
winProcQueryTree - winInitClipboard returned.
winClipboardProc - Hello
DetectUnicodeSupport - Windows NT/2000/XP
winClipboardProc - Calling setlocale ()
winClipboardProc - setlocale () returned
winClipboardProc - XInitThreads () returned.
winClipboardProc - DISPLAY=127.0.0.1:0.0
winProcEstablishConnection - Hello
winProcEstablishConnection - Clipboard client already launched, returning.
winClipboardProc - XOpenDisplay () returned and successfully opened the 
display.
winClipboardWindowProc - WM_CREATE
winClipboardWindowProc - WM_DRAWCLIPBOARD - Initializing - Returning.
winProcSetSelectionOwner - Clipboard not yet started, aborting.
winProcSetSelectionOwner - Clipboard not yet started, aborting.
winClipboardWindowProc - WM_DRAWCLIPBOARD - Reasserted ownership of PRIMARY
winClipboardWindowProc - WM_DRAWCLIPBOARD - Reasserted ownership of 
CLIPBOARD
winProcSetSelectionOwner - We changed ownership, aborting.
winProcSetSelectionOwner - We changed ownership, aborting.
OsVendorReset - Hello
winClipboardWindowProc - WM_DESTROY
winClipboardProc - winClipboardFlushWindowsMessageQueue trapped WM_QUIT 
message, exiting main loop.
OsVendorReset - Clipboard thread has exited.
(EE) Unable to locate/open config file
InitOutput - Error reading config file
winDetectSupportedEngines - Windows NT/2000/XP
winDetectSupportedEngines - DirectDraw installed
winDetectSupportedEngines - Allowing PrimaryDD
winDetectSupportedEngines - DirectDraw4 installed
winDetectSupportedEngines - Returning, supported engines 001f
InitOutput - g_iNumScreens: 1 iMaxConsecutiveScreen: 1
winScreenInit - dwWidth: 1274 dwHeight: 895
winSetEngine - Using Shadow DirectDraw NonLocking
winCreateBoundingWindowWindowed - User w

Re: XFree86-xserv-4.3.0-38 Request for Test Results

[Walter Haidinger]

On Mon, 12 Jan 2004, Harold L Hunt II wrote:

> Walter,
> 
> Can you send in your /tmp/XWin.log from a time when this fails?

There is just one (german) message indicating that the handle is invalid 
(ungültig in German):
winTopLevelWindowProc - BitBlt failed: Das Handle ist ungültig

Please note that it is like if X11 and Win32 clipboards are totally
distinct, i.e. in can cut&paste X11<->X11 windows but not to or from Win32
windows.

Walter

Re: XFree86-xserv-4.3.0-38 Request for Test Results

[Dr. Volker Zell]

> "Harold" == Harold L Hunt writes:

Harold> Please send in those test results for the XFree86-xserv-4.3.0-38
Harold> clipboard functionality as soon as possible.  I want positive results
Harold> (at least five of them) as well as negative.  Use the format below for
Harold> your test results if you find it useful:

Windows 2000
Language: English
Win32-> X11 Copy and Paste: Worked
X11-> Win32 Copy and Paste: Worked
Xdmcp: Did Not Try

Ciao
  Volker

Re: XFree86-xserv-4.3.0-38 Request for Test Results [from Holger Krull]

[Alexander Gottwald]

On Mon, 12 Jan 2004, Holger Krull wrote:

> How do i test server reset?

I've just logged out from my xdmcp session. wdm then displays the login screen again.

bye
ago
-- 
 [EMAIL PROTECTED] 
 http://www.gotti.org   ICQ: 126018723

Re: XFree86-xserv-4.3.0-38 Request for Test Results [from Holger Krull]

[Alexander Gottwald]

On Mon, 12 Jan 2004, Harold L Hunt II wrote:

> Do you mean that something bad happens if you copy an image to the Win32 
> clipboard, then cause the X Server to reset?  What happens?  Does the 
> clipboard integration stop working?  Does the server crash?

The server crashes (does not startup again)

bye
ago
-- 
 [EMAIL PROTECTED] 
 http://www.gotti.org   ICQ: 126018723

Re: XFree86-xserv-4.3.0-38 Request for Test Results

[Harold L Hunt II]

Walter,

Can you send in your /tmp/XWin.log from a time when this fails?

Harold

Walter Haidinger wrote:
On Mon, 12 Jan 2004, Harold L Hunt II wrote:


Please send in those test results for the XFree86-xserv-4.3.0-38 
clipboard functionality as soon as possible.  I want positive results 
(at least five of them) as well as negative.  Use the format below for 
your test results if you find it useful:


Well, here's a negative: :-(

OS: Windows XP with SP1 and TweakUI
Language: German
Win32->X11 Copy and Paste: Did Not Work
X11->Win32 Copy and Paste: Did Not Work
Xdmcp: Did Not Try
This is odd, I remember that the clipboard used to work...

I run this to finally start the X-Server (from startxwin.bat):
start XWin -multiwindow -clipboard -xf86config 
  C:\cygwin\etc\X11\XF86Config

Walter

Re: XFree86-xserv-4.3.0-38 Request for Test Results [from Holger Krull]

[Holger Krull]

> I can't reproduce this: OpenOffice 1.1 pasted  correctly.
> Also kedit, kmail, mozilla, xterm.
kedit,kmail,xterm and mozilla work. Maybe a local problem with my 
OpenOffice.

> System is win2000 and XDMCP to debian 3.0

Win2000 and XDMCP to Suse 9.0 here.

> Server reset worked in with text copied in X11,

How do i test server reset?

   Holger

Re: XFree86-xserv-4.3.0-38 Request for Test Results

[Walter Haidinger]

On Mon, 12 Jan 2004, Harold L Hunt II wrote:

> Please send in those test results for the XFree86-xserv-4.3.0-38 
> clipboard functionality as soon as possible.  I want positive results 
> (at least five of them) as well as negative.  Use the format below for 
> your test results if you find it useful:

Well, here's a negative: :-(

OS: Windows XP with SP1 and TweakUI
Language: German
Win32->X11 Copy and Paste: Did Not Work
X11->Win32 Copy and Paste: Did Not Work
Xdmcp: Did Not Try

This is odd, I remember that the clipboard used to work...

I run this to finally start the X-Server (from startxwin.bat):
start XWin -multiwindow -clipboard -xf86config 
  C:\cygwin\etc\X11\XF86Config

Walter

Re: XFree86-xserv-4.3.0-38 Request for Test Results [from Holger Krull]

[Harold L Hunt II]

Alexander Gottwald wrote:

Win32->X11 Copy and Paste: Worked,
except for äöüß? (Umlaute, sz, Euro)
the transfer of these characters works if they are paste to a terminal, 
other programs show varying
success. OpenOffice doesn't like Umlaute but takes the Euro. Kate (KDE 
Editor) pastes Umlaute but
not the Euro Symbol.


I can't reproduce this: 
OpenOffice 1.1 pasted äöüß? correctly.
Also kedit, kmail, mozilla, xterm.

System is win2000 and XDMCP to debian 3.0

Server reset worked in with text copied in X11, copied in Win32 but not with
image copied in Win32 (not a big problem).
Do you mean that something bad happens if you copy an image to the Win32 
clipboard, then cause the X Server to reset?  What happens?  Does the 
clipboard integration stop working?  Does the server crash?

Harold

Re: XFree86-xserv-4.3.0-38 Request for Test Results [from Holger Krull]

[Alexander Gottwald]

On Mon, 12 Jan 2004, Harold L Hunt II wrote:

> The following is from Holger Krull:
> 
> OS: Windows 2000
> Language: German
> Xdmcp: Worked
> X11->Win32 Copy and Paste: Worked

Same for me.

> Win32->X11 Copy and Paste: Worked,
> except for äöüß? (Umlaute, sz, Euro)
> the transfer of these characters works if they are paste to a terminal, 
> other programs show varying
> success. OpenOffice doesn't like Umlaute but takes the Euro. Kate (KDE 
> Editor) pastes Umlaute but
> not the Euro Symbol.

I can't reproduce this: 
OpenOffice 1.1 pasted äöüß? correctly.
Also kedit, kmail, mozilla, xterm.

System is win2000 and XDMCP to debian 3.0

Server reset worked in with text copied in X11, copied in Win32 but not with
image copied in Win32 (not a big problem).

bye
ago
-- 
 [EMAIL PROTECTED] 
 http://www.gotti.org   ICQ: 126018723

Re: XFree86-xserv-4.3.0-38 Request for Test Results [from Holger Krull]

[Harold L Hunt II]

The following is from Holger Krull:

OS: Windows 2000
Language: German
Xdmcp: Worked
X11->Win32 Copy and Paste: Worked
Win32->X11 Copy and Paste: Worked,
except for äöü߀ (Umlaute, sz, Euro)
the transfer of these characters works if they are paste to a terminal, 
other programs show varying
success. OpenOffice doesn't like Umlaute but takes the Euro. Kate (KDE 
Editor) pastes Umlaute but
not the Euro Symbol.

   Holger

Re: XFree86-xserv-4.3.0-37

[Holger Krull]

Harold L Hunt II schrieb:
A new 'test' version has been posted with many changes to the clipboard
support.
Works, no problem found.
Thank you for your work.
   Holger

Re: XFree86-xserv-4.3.0-35

[Harold L Hunt II]

Holger,

Holger Krull wrote:

Hello,
the previous problem is gone, now large amount of text can be 
transfered. Really great.
I wasn't able to duplicate that particular bug anyhow... so it is good 
that it is not happening for you anymore :)

A small qirk is left, if i copy a graphic in Windows and try to paste it 
X11 OpenOffice it get the message that the desired format isn't 
available in the clipboard (no surprise here).
Hmm... that is because I need to release ownership of the X11 selections 
(if the clipboard client currently owns the selections) the first time 
that some unsupported format is copied to the Win32 clipboard.  That way 
no X Client will request the clipboard contents from us when the Win32 
clipboard does not contain text.

I missed that one when I decided what fixes need to be made.  I guess I 
will have to fix this now too :)  It will be tough to get it right 
though, because the current code has a lot of special values used to 
make sure that two functions don't get in an infinite loop of disowning 
and re-owning selections and the clipboard.  I have to be very careful 
to make sure that any side-effects from further changes do not cause 
infinite loops.

But after that the Windows clipboard is blocked (no copy, no paste, only 
error messages) until i put something in the X11 clipboard. Maybe this 
the same problem you didn't want to be mentioned until someone found a 
solution.
Nope, what you describe is different than what I said not to complain 
about.  What was happening here is that I called OpenClipboard, then 
checked IsClipboardFormatAvailable and aborted without calling 
CloseClipboard if the desired format was not available.  That left the 
Win32 clipboard locked and prevented other apps from changing it.  Our 
app could call OpenClipboard though, so that is why selecting something 
in X11 fixed the problem.  This problem should not happen when the above 
fix is implemented, but I think it is really worth fixing this right now 
since it is so simple and will prevent really bad behavior.  So, I am 
posting 4.3.0-36 right now.

Harold

Re: XFree86-xserv-4.3.0-35

[Holger Krull]

Hello,
the previous problem is gone, now large amount of text can be transfered. Really great.
A small qirk is left, if i copy a graphic in Windows and try to paste it X11 OpenOffice it get the 
message that the desired format isn't available in the clipboard (no surprise here).
But after that the Windows clipboard is blocked (no copy, no paste, only error messages) until i put 
something in the X11 clipboard. Maybe this the same problem you didn't want to be mentioned until 
someone found a solution.

Bye
  Holger

Re: XFree86-xserv-4.3.0-34 crash

[Harold L Hunt II]

Ãyvind,

Ãyvind Harboe wrote:

This crash seems to be very similar to what I've seen in previous releases. I have the
impression that it happens most often when I select a message in Evolution.
I believe that the crash is happening because there are no checks to 
make sure that the clipboards are only synchronized when supported 
formats (text and Unicode text) are being copied to the clipboard.

In other words, if you try to copy an image in X11 we will grab 
ownership of the Win32 clipboard and advertise that we have text ready 
to paste on the Win32 clipboard.  We will also grab ownership of the 
PRIMARY and CLIPBOARD selections in X11 when you copy an image in Win32 
and we will attempt to request the clipboard data in CF_TEXT or 
CF_UNICODETEXT formats when that data is pasted in X11; obviously, this 
does not work.

I do not believe that there were ever any reals checks to prevent this 
from happening before... or maybe it just worked out that checks were 
not needed as a side effect of how the previous system worked.

In any case, I am writing up a list of things that need to be done to 
ensure that we only synchronize the Win32 and X11 clipboards when 
supported formats (text and Unicode text) are being advertised on either 
clipboard.  In all other cases we need to keep the Win32 and X11 
clipboards independent of each other so that they don't try to transfer 
unsupported formats between each other.

This will probably be posted as XFree86-xserv-4.3.0-35 later today or in 
a few days.

Thanks for testing,

Harold

Re: XFree86-xserv-4.3.0-34

[Holger Krull]

Harold L Hunt II schrieb:

 > Please test the new release and report your results.  See the change log
or the cygwin-xfree-announce mailing list archives for details on what 
was changed.
Hello,
the -clipboard feature now works here in general, but i noticed the when trying to copy and paste 
from X11 openoffice 1.1.0 on linux to windows notepad. If i try to transfer a large amount of lines 
(>5) the end gets cut of in Windows. Somtimes clipboard will stop working after repeated transfers 
from Windows to X11 and back, but i have not found a way to exactly reproduce this.

Thy XWin.log after such a failed attempt looks like:

ddxProcessArgument - Initializing default screens
winInitializeDefaultScreens - w 1280 h 960
winInitializeDefaultScreens - Returning
OsVendorInit - Creating bogus screen 0
(EE) Unable to locate/open config file
InitOutput - Error reading config file
winDetectSupportedEngines - Windows NT/2000/XP
winDetectSupportedEngines - DirectDraw installed
winDetectSupportedEngines - Allowing PrimaryDD
winDetectSupportedEngines - DirectDraw4 installed
winDetectSupportedEngines - Returning, supported engines 001f
InitOutput - g_iNumScreens: 1 iMaxConsecutiveScreen: 1
winScreenInit - dwWidth: 1280 dwHeight: 960
winSetEngine - Using Shadow DirectDraw NonLocking
winAdjustVideoModeShadowDDNL - Using Windows display depth of 32 bits per pixel
winCreateBoundingWindowWindowed - User w: 1280 h: 960
winCreateBoundingWindowWindowed - Current w: 1280 h: 960
winAdjustForAutoHide - Original WorkArea: 0 0 926 1280
winAdjustForAutoHide - Adjusted WorkArea: 0 0 926 1280
winCreateBoundingWindowWindowed - WindowClient w 1274 h 895 r 1274 l 0 b 895 t 0
winCreateBoundingWindowWindowed -  Returning
winCreatePrimarySurfaceShadowDDNL - Creating primary surface
winCreatePrimarySurfaceShadowDDNL - Created primary surface
winCreatePrimarySurfaceShadowDDNL - Attached clipper to primary surface
winAllocateFBShadowDDNL - lPitch: 5096
winAllocateFBShadowDDNL - Created shadow pitch: 5096
winAllocateFBShadowDDNL - Created shadow stride: 1274
winFinishScreenInitFB - Masks: 00ff ff00 00ff
winInitVisualsShadowDDNL - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32
winCreateDefColormap - Deferring to fbCreateDefColormap ()
winFinishScreenInitFB - returning
winScreenInit - returning
InitOutput - Returning.
MIT-SHM extension disabled due to lack of kernel support
XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in 
the kernel
(--) Setting autorepeat to delay=500, rate=31
(--) winConfigKeyboard - Layout: "0407" (0407)
(--) Using preset keyboard for "German (Germany)" (407), type "4"
(EE) No primary keyboard configured
(==) Using compiletime defaults for keyboard
Rules = "xfree86" Model = "pc105" Layout = "de" Variant = "(null)" Options = "(null)"
Error opening keymap file de, reverting to defaults
winPointerWarpCursor - Discarding first warp: 637 447
winBlockHandler - Releasing pmServerStarted
winBlockHandler - pthread_mutex_unlock () returned
winProcEstablishConnection - Hello
winProcEstablishConnection - Xdmcp enabled, waiting to start clipboard client until fourth call.
winProcEstablishConnection - Hello
winProcEstablishConnection - Xdmcp enabled, waiting to start clipboard client until fourth call.
winProcEstablishConnection - Hello
winProcEstablishConnection - Xdmcp enabled, waiting to start clipboard client until fourth call.
winInitClipboard ()
winProcQueryTree - winInitClipboard returned.
winClipboardProc - Hello
DetectUnicodeSupport - Windows NT/2000/XP
winClipboardProc - Calling setlocale ()
winClipboardProc - setlocale () returned
winClipboardProc - XInitThreads () returned.
winClipboardProc - DISPLAY=127.0.0.1:0.0
winProcEstablishConnection - Hello
winProcEstablishConnection - Clipboard client already launched, returning.
winClipboardProc - XOpenDisplay () returned and successfully opened the display.
winClipboardWindowProc - WM_CREATE
winClipboardWindowProc - WM_DRAWCLIPBOARD - Initializing - Returning.
winClipboardWindowProc - WM_DRAWCLIPBOARD - We own the clipboard, returning.
winClipboardFlushXEvents - SelectionNotify - ATOM: PRIMARY
winClipboardWindowProc - WM_DRAWCLIPBOARD - Reasserted ownership of PRIMARY
winClipboardWindowProc - WM_DRAWCLIPBOARD - Reasserted ownership of CLIPBOARD
winProcSetSelectionOwner - We changed ownership, aborting.
winClipboardFlushXEvents - SelectionRequest - GetClipboardData () failed: 

Re: Xfree86/cygwin and speed

[Takuma Murakami]

Have you tried 'ssh -C'?

Takuma Murakami ([EMAIL PROTECTED])

Re: Xfree86/cygwin and speed

[Harold L Hunt II]

Alexander Gottwald wrote:
On Fri, 9 Jan 2004 [EMAIL PROTECTED] wrote:


Hello all,

I've got a question about speeding up application performance when using Xfree86 and Cygwin. Here's my configuration:

Linux box connected by 100 Mbps Ethernet to router.
Windows machine connecting wirelessly at 11 Mbps (802.11b) to router.
Cygwin with Xfree86 set up on Windows machine, X11 forwarding set up on Linux box. I connect from Windows machine to Linux box with Cygwin using ssh tunnelling. I can successfully run the Linux application remotely. All is pretty good.

Trouble is, the application is The GIMP, and it is painfully slow on the Windows machine. Redrawing the image occurs in slow motion, and every time I move a dialog box, I've got to wait an eternity for the image to fill in. 

Here's my question: How can I speed this up? Or, rather, where's the bottleneck?

-Is it the 11Mbps wireless connection, in which case I'll think more deeply about shelling out for 802.11g equipment?
Yes, the problem is the wireless link.  802.11g is sufficiently fast to 
display images in Cygwin/X while 802.11b is not.  I use 802.11g at home 
all the time to get an Xdmcp session on my Linux machine and it is 
slower than 100 Mbps Ethernet, but it is fast enough to do what I need 
to do.  Dropping to 802.11b would not be acceptable for me.

Hope that helps,

Harold

Re: Xfree86/cygwin and speed

[Alexander Gottwald]

On Fri, 9 Jan 2004 [EMAIL PROTECTED] wrote:

> Hello all,
> 
> I've got a question about speeding up application performance when using Xfree86 and 
> Cygwin. Here's my configuration:
> 
> Linux box connected by 100 Mbps Ethernet to router.
> Windows machine connecting wirelessly at 11 Mbps (802.11b) to router.
> 
> Cygwin with Xfree86 set up on Windows machine, X11 forwarding set up on Linux box. I 
> connect from Windows machine to Linux box with Cygwin using ssh tunnelling. I can 
> successfully run the Linux application remotely. All is pretty good.
> 
> Trouble is, the application is The GIMP, and it is painfully slow on the Windows 
> machine. Redrawing the image occurs in slow motion, and every time I move a dialog 
> box, I've got to wait an eternity for the image to fill in. 
> 
> Here's my question: How can I speed this up? Or, rather, where's the bottleneck?
> 
> -Is it the 11Mbps wireless connection, in which case I'll think more deeply about 
> shelling out for 802.11g equipment?
> 
> Any insight would be most appreciated.

It is mainly the slow wireless lan connection. X11 must transport a lot of 
image data and this is always a pain on slow (<100 MBit) connections.

Try connecting the windows machine with cable and compare the results.

bye
ago
-- 
 [EMAIL PROTECTED] 
 http://www.gotti.org   ICQ: 126018723

Re: XFree86-xserv-4.3.0-33 release pending

[Holger Krull]

Hi again,

The current triggers I am using work fine with my KDM implementation, 
but they appear not to work with your XDM implementation.  So, I will 
just for info, xdm here is in reality a kdm (as far as i know). It is a Suse 9.0 with kde installed.

  Holger

Re: XFree86-xserv-4.3.0-33 release pending

[Harold L Hunt II]

Holger,

Holger Krull wrote:

Hello,
i installed the -33 Version and the -clipboard feature doesn't work.
I started with xwin +kb -xkbmap de -query murpel -from 192.168.1.2 -fp 
tcp/192.168.1.1:7100 -dpi 100 -once -clipboard

What's different here? Xwinclip still works but needs -ac.
Thanks, the log file was very useful.

What is happening is that we have to wait to start the clipboard client 
until XDM has finished killing any connected clients.  There is not a 
well-defined event that I can use to track this, so I have to try to 
find an artifact of the startup process that works with most XDM/KDM/GDM 
implementations.

The current triggers I am using work fine with my KDM implementation, 
but they appear not to work with your XDM implementation.  So, I will 
have to tweak the triggers a bit to see if I can make them more robust.

Thanks for the report.  Patiently wait for 4.3.0-34.

Thanks,

Harold

Re: XFree86-xserv-4.3.0-33 release pending

[Holger Krull]

Hello,
i installed the -33 Version and the -clipboard feature doesn't work.
I started with xwin +kb -xkbmap de -query murpel -from 192.168.1.2 -fp tcp/192.168.1.1:7100 -dpi 100 
-once -clipboard

What's different here? Xwinclip still works but needs -ac.

The XWin.log says

ddxProcessArgument - Initializing default screens
winInitializeDefaultScreens - w 1280 h 960
winInitializeDefaultScreens - Returning
OsVendorInit - Creating bogus screen 0
(EE) Unable to locate/open config file
InitOutput - Error reading config file
winDetectSupportedEngines - Windows NT/2000/XP
winDetectSupportedEngines - DirectDraw installed
winDetectSupportedEngines - Allowing PrimaryDD
winDetectSupportedEngines - DirectDraw4 installed
winDetectSupportedEngines - Returning, supported engines 001f
InitOutput - g_iNumScreens: 1 iMaxConsecutiveScreen: 1
winScreenInit - dwWidth: 1280 dwHeight: 960
winSetEngine - Using Shadow DirectDraw NonLocking
winAdjustVideoModeShadowDDNL - Using Windows display depth of 32 bits per pixel
winCreateBoundingWindowWindowed - User w: 1280 h: 960
winCreateBoundingWindowWindowed - Current w: 1280 h: 960
winAdjustForAutoHide - Original WorkArea: 0 0 926 1280
winAdjustForAutoHide - Adjusted WorkArea: 0 0 926 1280
winCreateBoundingWindowWindowed - WindowClient w 1274 h 895 r 1274 l 0 b 895 t 0
winCreateBoundingWindowWindowed -  Returning
winCreatePrimarySurfaceShadowDDNL - Creating primary surface
winCreatePrimarySurfaceShadowDDNL - Created primary surface
winCreatePrimarySurfaceShadowDDNL - Attached clipper to primary surface
winAllocateFBShadowDDNL - lPitch: 5096
winAllocateFBShadowDDNL - Created shadow pitch: 5096
winAllocateFBShadowDDNL - Created shadow stride: 1274
winFinishScreenInitFB - Masks: 00ff ff00 00ff
winInitVisualsShadowDDNL - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32
winCreateDefColormap - Deferring to fbCreateDefColormap ()
winFinishScreenInitFB - returning
winScreenInit - returning
InitOutput - Returning.
MIT-SHM extension disabled due to lack of kernel support
XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in 
the kernel
(--) Setting autorepeat to delay=500, rate=31
(--) winConfigKeyboard - Layout: "0407" (0407)
(--) Using preset keyboard for "German (Germany)" (407), type "4"
(EE) No primary keyboard configured
(==) Using compiletime defaults for keyboard
Rules = "xfree86" Model = "pc105" Layout = "de" Variant = "(null)" Options = "(null)"
Error opening keymap file de, reverting to defaults
winPointerWarpCursor - Discarding first warp: 637 447
winBlockHandler - Releasing pmServerStarted
winBlockHandler - pthread_mutex_unlock () returned
winProcEstablishConnection - Hello
winProcEstablishConnection - Xdmcp enabled, waiting to start clipboard client until third call.
winProcEstablishConnection - Hello
winProcEstablishConnection - Xdmcp enabled, waiting to start clipboard client until third call.
winProcEstablishConnection - Hello
winInitClipboard ()
winProcEstablishConnection - winInitClipboard returned.
winClipboardProc - Hello
DetectUnicodeSupport - Windows NT/2000/XP
winClipboardProc - Calling setlocale ()
winClipboardProc - setlocale () returned
winClipboardProc - XInitThreads () returned.
winClipboardProc - DISPLAY=127.0.0.1:0.0
winClipboardProc - XOpenDisplay () returned and successfully opened the display.
winClipboardWindowProc - WM_CREATE
winClipboardWindowProc - WM_DRAWCLIPBOARD - Initializing - Returning.

winProcSetSelectionOwner - Clipboard not yet started.

winProcSetSelectionOwner - Clipboard not yet started.

winProcQueryTree - Clipboard client already launched, returning.

winClipboardIOErrorHandler!

winClipboardProc - setjmp returned for IO Error Handler.
winProcSetSelectionOwner - No valid clipboard window handle.

Re: XFree86-xserv-4.3.0-33 clipboard problem

[Harold L Hunt II]

Ãyvind,

We would need to see an XWin.log from such a session.

Harold

Ãyvind Harboe wrote:

I just ran into a problem:

After working with XWin for a while(30 minutes), the clipboard
integration stopped working.
No crash.

I could no longer copy from windows and paste in Evolution.

When I shut down XWin and restarted XWin + Evolution, paste to Evolution
worked again.
Ãyvind

Re: XFree86-xserv-4.3.0-33 release pending

[Harold L Hunt II]

Takuma,

Please rerun setup.exe and install the XFree86-xserv-4.3.0-33 package 
again.  It was updated after you first downloaded it.

Harold

Takuma Murakami wrote:

Dear Kensuke,


Couldn't you copy and paste Japanese text in above condition?

X app -> Win apps that use unicode(IE, Notepade etc)
X app -> Win apps that don't use unicode(Meadow, Hidemaru etc)
Either of those two fail in my environment(Windows XP).
With -nounicodeclipboard, unicode apps fail. And without it, non-unicode apps
fail


I have tested further on the issue.  I use Emacs for X app
and Hidemaru for Win app.  All software run on local
machine (WinXP).
For X -> Win cases, it seems working perfectly.
For Win -> X cases, problems happen.  For some characters,
the pasted part is shown in a little strange font and I
cannot save the file.  Note that, I can still read the
pasted part.  It's in different font (might be Unicode
font?) but represents the same character.  Furthermore,
some characters are converted perfectly, that is, I can
save it.
I have done the same test using IE instead of Hidemaru
for comparison between Unicode and non-Unicode apps
but noticed no difference.
I also compared Shift-JIS and EUC and again noticed
no difference.
Thank you for all your works and hope this helps.

Takuma Murakami ([EMAIL PROTECTED])

Re: XFree86-xserv-4.3.0-33 release pending

[Kensuke Matsuzaki]

Hi Takuma,

> I have tested further on the issue.  I use Emacs for X app
> and Hidemaru for Win app.  All software run on local
> machine (WinXP).

Sorry, Hidemaru 4.04 and IE are same behavior. I used 3.05.


> For Win -> X cases, problems happen.  For some characters,
> the pasted part is shown in a little strange font and I
> cannot save the file.  Note that, I can still read the
> pasted part.  It's in different font (might be Unicode
> font?) but represents the same character.  Furthermore,
> some characters are converted perfectly, that is, I can
> save it.

This is different problme that I said, and other version
XWin have same problem.
Maybe no problem with -nounicodeclipboard option.

-- 
Kensuke Matsuzaki
mailto:[EMAIL PROTECTED]
http://peppermint.jp

Re: XFree86-xserv-4.3.0-33 release pending

[Takuma Murakami]

Dear Kensuke,

> Couldn't you copy and paste Japanese text in above condition?
> 
> X app -> Win apps that use unicode(IE, Notepade etc)
> X app -> Win apps that don't use unicode(Meadow, Hidemaru etc)
> 
> 
> Either of those two fail in my environment(Windows XP).
> With -nounicodeclipboard, unicode apps fail. And without it, non-unicode apps
> fail

I have tested further on the issue.  I use Emacs for X app
and Hidemaru for Win app.  All software run on local
machine (WinXP).

For X -> Win cases, it seems working perfectly.
For Win -> X cases, problems happen.  For some characters,
the pasted part is shown in a little strange font and I
cannot save the file.  Note that, I can still read the
pasted part.  It's in different font (might be Unicode
font?) but represents the same character.  Furthermore,
some characters are converted perfectly, that is, I can
save it.

I have done the same test using IE instead of Hidemaru
for comparison between Unicode and non-Unicode apps
but noticed no difference.

I also compared Shift-JIS and EUC and again noticed
no difference.

Thank you for all your works and hope this helps.

Takuma Murakami ([EMAIL PROTECTED])

Re: XFree86-xserv-4.3.0-33 release pending

[Kensuke Matsuzaki]

Takuma,

> It works quite well in my environment.
> 
> The test includes:
> local X apps <-> local Windows apps
> local {X|Win} apps <-> ssh-forwarded X apps
> local {X|Win} apps <-> XDMCP session
> X apps: rxvt, xterm, emacs
> Win apps: editors
> all data is plain text.
> 
> Additionally, even Japanese texts with different
> encodings are correctly copied & pasted.

Couldn't you copy and paste Japanese text in above condition?

X app -> Win apps that use unicode(IE, Notepade etc)
X app -> Win apps that don't use unicode(Meadow, Hidemaru etc)


Either of those two fail in my environment(Windows XP).
With -nounicodeclipboard, unicode apps fail. And without it, non-unicode apps
fail.

-- 
Kensuke Matsuzaki
mailto:[EMAIL PROTECTED]
http://peppermint.jp

Re: XFree86-xserv-4.3.0-33 release pending

[Harold L Hunt II]

Takuma,

Thanks for the feedback.  Kensuke is reporting some trouble with Unicode 
text conversion.  There may be some bugs on NT-based platforms that 
support Unicode.

I have posted the 4.3.0-33 release and marked it as 'test' until we can 
confirm whether it has new problems with Unicode or if the problems 
already existed.

Thanks for testing,

Harold

Takuma Murakami wrote:

It works quite well in my environment.

The test includes:
local X apps <-> local Windows apps
local {X|Win} apps <-> ssh-forwarded X apps
local {X|Win} apps <-> XDMCP session
X apps: rxvt, xterm, emacs
Win apps: editors
all data is plain text.
Additionally, even Japanese texts with different
encodings are correctly copied & pasted.
Thank you very much for the wonderful improvement.

Takuma Murakami ([EMAIL PROTECTED])

Re: XFree86-xserv-4.3.0-33 release pending

[Takuma Murakami]

It works quite well in my environment.

The test includes:
local X apps <-> local Windows apps
local {X|Win} apps <-> ssh-forwarded X apps
local {X|Win} apps <-> XDMCP session
X apps: rxvt, xterm, emacs
Win apps: editors
all data is plain text.

Additionally, even Japanese texts with different
encodings are correctly copied & pasted.

Thank you very much for the wonderful improvement.

Takuma Murakami ([EMAIL PROTECTED])

RE: XFree86-xserv-4.3.0-32 tests

[Andrew Braverman]

Just to follow up on this, I found this morning that this does not happen
all the time.  If I start the server and the new code is working, selecting
text with the mouse leaves data selected (inverse video) and none of these
things happen (there is still some debug logging, but much less).  At other
times, selected text has the inverse video go away (like used to happen) and
the three things I listed here happen.  I expect, based upon Harold's
comments about fixing a bunch of things, that this will go away in his next
release, but figured I would mention it as a data point anyway.

- Andy

> -Original Message-
> From: Andrew Braverman [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, January 06, 2004 1:45 PM
> To: '[EMAIL PROTECTED]'
> Subject: XFree86-xserv-4.3.0-32 tests
>
>
> I tried this version and it solves the problem that I saw
> yesterday with -31.  I have, however, found a few issues that
> I thought you should at least be aware of.
>
>   1. XWin is taking a lot more system resources than it
> usually does.  This may be related to
>   2. XWin is doing a lot of debug logging to XWin.log.  I
> understand that this may be on purpose, but figured I would
> mention it.
>   3. I do not know if it was this version or something
> just before, but my autorepeat does not seem to work (even
> though xset q shows it on).
>
> Thanks again for the wonderful work you are doing.
>

Re: XFree86-xserv-4.3.0-32 tests

[Harold L Hunt II]

Ãyvind,

I wouldn't worry too much about it... I am in the middle of completely 
reworking the clipboard shutdown code.  The crashes will be fixed when I 
am through with it, so I don't particularly need details about any 
current crashes in -32 anymore.

Thanks for testing,

Harold

Ãyvind Harboe wrote:
I've now seen the xwinclip: xwin.exe crash on exit with 
4.3.0-32 as well. It was an access violation to address 1.

Is this a known problem?

If not, does anyone have any pointers on how to create a useful bug report?

One idea I had was to somehow invoke GDB once the OK Cancel access violation requester
pops up, but I've no idea on how to go about this?
A fixed sequence of steps to reproduce the problem has eluded me, hence my 
interest in a postmortem approach.

Ãyvind

Re: XFree86 4.3.0 and AltGr

[Harold L Hunt II]

Can somebody confirm for me whether or not this fixes the AltGr problems 
for them with TweakUI?

Harold

Harold L Hunt II wrote:

Okay, XFree86-xserv-4.3.0-29 has just been posted.  Please try it and 
somebody please tell me whether it fixes the problem for them or not.

Harold

Harold L Hunt II wrote:

I believe I have found just the right amount of magic to fix this once 
and for all.  Please stay tuned to test the new release.

Harold

Philippe Auclair wrote:

Hi,

Gosh, what an exciting thread about "Proper attribution of patches"!

Now, to the point... As many Europeans, as Michael Lipp said, "I 
stumbled
over the not-working AltGr" (I have a French keyboard, and a Windows XP
box).

After various unsuccessful tries with XF86Config, I had a good look 
at the
results of xev. The xev downloaded with Cygwin XFree, and xev on Sun 
Solaris
give similar results: when I press the single key AltGr, xev says:
KeyPress event, serial 18, synthetic NO, window 0xc1,
root 0x3a, subw 0x0, time 2826093, (105,60), root:(899,527),
state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 characters:  ""

KeyPress event, serial 18, synthetic NO, window 0xc1,
root 0x3a, subw 0x0, time 2826093, (105,60), root:(899,527),
state 0x14, keycode 113 (keysym 0xfe03, ISO_Level3_Shift), 
same_screen
YES,
XLookupString gives 0 characters:  ""

I then tried xmodmap with the following commands:
clear Mod5
keycode 113 = Mode_switch
add Mod3 = Mode_switch
-> result when pressing AltGr: keycode 37 (Control_L) + keycode 113
(Mode_switch)
Of course, xterm or emacs don't understand... OK, well is there an 
unused
key at the bottom of the keyboard?
XFree doesn't see the "Windows " key at all, but I have a key which, 
when
pressed in a Windows application, does the same as right click. xev sees
this key as keycode 101. So I feed this into xmodmap:
clear Mod5
keycode 101 = Mode_switch
add Mod3 = Mode_switch
keycode 10 = ampersand 1
keycode 11 = eacute 2 asciitilde
keycode 12 = quotedbl 3 numbersign
keycode 13 = apostrophe 4 braceleft
keycode 14 = parenleft 5 bracketleft
keycode 15 = minus 6 bar
keycode 16 = egrave 7 grave
keycode 17 = underscore 8 backslash
keycode 18 = ccedilla 9 asciicircum
keycode 19 = agrave 0 at
keycode 20 = parenright degree bracketright
keycode 21 = equal plus braceright

Bingo! xterm and emacs work!  Except I use this odd key instead of 
AltGr,
which I *REALLY* would prefer.

Hope this helps...

Philippe Auclair
**
Institut National de la Recherche Agronomique
Unité Centrale Informatique de Jouy
Domaine de Vilvert, 78352 Jouy-en-Josas CEDEX, France
[EMAIL PROTECTED]
tel +33 1 34 65 26 95, fax +33 1 34 65 24 03
**

Re: XFree86 4.3.0 and AltGr

[Harold L Hunt II]

Okay, XFree86-xserv-4.3.0-29 has just been posted.  Please try it and 
somebody please tell me whether it fixes the problem for them or not.

Harold

Harold L Hunt II wrote:

I believe I have found just the right amount of magic to fix this once 
and for all.  Please stay tuned to test the new release.

Harold

Philippe Auclair wrote:

Hi,

Gosh, what an exciting thread about "Proper attribution of patches"!

Now, to the point... As many Europeans, as Michael Lipp said, "I stumbled
over the not-working AltGr" (I have a French keyboard, and a Windows XP
box).
After various unsuccessful tries with XF86Config, I had a good look at 
the
results of xev. The xev downloaded with Cygwin XFree, and xev on Sun 
Solaris
give similar results: when I press the single key AltGr, xev says:
KeyPress event, serial 18, synthetic NO, window 0xc1,
root 0x3a, subw 0x0, time 2826093, (105,60), root:(899,527),
state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 characters:  ""

KeyPress event, serial 18, synthetic NO, window 0xc1,
root 0x3a, subw 0x0, time 2826093, (105,60), root:(899,527),
state 0x14, keycode 113 (keysym 0xfe03, ISO_Level3_Shift), 
same_screen
YES,
XLookupString gives 0 characters:  ""

I then tried xmodmap with the following commands:
clear Mod5
keycode 113 = Mode_switch
add Mod3 = Mode_switch
-> result when pressing AltGr: keycode 37 (Control_L) + keycode 113
(Mode_switch)
Of course, xterm or emacs don't understand... OK, well is there an unused
key at the bottom of the keyboard?
XFree doesn't see the "Windows " key at all, but I have a key which, when
pressed in a Windows application, does the same as right click. xev sees
this key as keycode 101. So I feed this into xmodmap:
clear Mod5
keycode 101 = Mode_switch
add Mod3 = Mode_switch
keycode 10 = ampersand 1
keycode 11 = eacute 2 asciitilde
keycode 12 = quotedbl 3 numbersign
keycode 13 = apostrophe 4 braceleft
keycode 14 = parenleft 5 bracketleft
keycode 15 = minus 6 bar
keycode 16 = egrave 7 grave
keycode 17 = underscore 8 backslash
keycode 18 = ccedilla 9 asciicircum
keycode 19 = agrave 0 at
keycode 20 = parenright degree bracketright
keycode 21 = equal plus braceright
Bingo! xterm and emacs work!  Except I use this odd key instead of AltGr,
which I *REALLY* would prefer.
Hope this helps...

Philippe Auclair
**
Institut National de la Recherche Agronomique
Unité Centrale Informatique de Jouy
Domaine de Vilvert, 78352 Jouy-en-Josas CEDEX, France
[EMAIL PROTECTED]
tel +33 1 34 65 26 95, fax +33 1 34 65 24 03
**

Re: XFree86 4.3.0 and AltGr

[Harold L Hunt II]

I believe I have found just the right amount of magic to fix this once 
and for all.  Please stay tuned to test the new release.

Harold

Philippe Auclair wrote:

Hi,

Gosh, what an exciting thread about "Proper attribution of patches"!

Now, to the point... As many Europeans, as Michael Lipp said, "I stumbled
over the not-working AltGr" (I have a French keyboard, and a Windows XP
box).
After various unsuccessful tries with XF86Config, I had a good look at the
results of xev. The xev downloaded with Cygwin XFree, and xev on Sun Solaris
give similar results: when I press the single key AltGr, xev says:
KeyPress event, serial 18, synthetic NO, window 0xc1,
root 0x3a, subw 0x0, time 2826093, (105,60), root:(899,527),
state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 characters:  ""
KeyPress event, serial 18, synthetic NO, window 0xc1,
root 0x3a, subw 0x0, time 2826093, (105,60), root:(899,527),
state 0x14, keycode 113 (keysym 0xfe03, ISO_Level3_Shift), same_screen
YES,
XLookupString gives 0 characters:  ""
I then tried xmodmap with the following commands:
clear Mod5
keycode 113 = Mode_switch
add Mod3 = Mode_switch
-> result when pressing AltGr: keycode 37 (Control_L) + keycode 113
(Mode_switch)
Of course, xterm or emacs don't understand... OK, well is there an unused
key at the bottom of the keyboard?
XFree doesn't see the "Windows " key at all, but I have a key which, when
pressed in a Windows application, does the same as right click. xev sees
this key as keycode 101. So I feed this into xmodmap:
clear Mod5
keycode 101 = Mode_switch
add Mod3 = Mode_switch
keycode 10 = ampersand 1
keycode 11 = eacute 2 asciitilde
keycode 12 = quotedbl 3 numbersign
keycode 13 = apostrophe 4 braceleft
keycode 14 = parenleft 5 bracketleft
keycode 15 = minus 6 bar
keycode 16 = egrave 7 grave
keycode 17 = underscore 8 backslash
keycode 18 = ccedilla 9 asciicircum
keycode 19 = agrave 0 at
keycode 20 = parenright degree bracketright
keycode 21 = equal plus braceright
Bingo! xterm and emacs work!  Except I use this odd key instead of AltGr,
which I *REALLY* would prefer.
Hope this helps...

Philippe Auclair
**
Institut National de la Recherche Agronomique
Unité Centrale Informatique de Jouy
Domaine de Vilvert, 78352 Jouy-en-Josas CEDEX, France
[EMAIL PROTECTED]
tel +33 1 34 65 26 95, fax +33 1 34 65 24 03
**

Re: XFree86 4.3.0 and AltGr

[Harold L Hunt II]

Do you have any Windows Power Toys (e.g. TweakUI) installed?

Harold

Philippe Auclair wrote:

Hi,

Gosh, what an exciting thread about "Proper attribution of patches"!

Now, to the point... As many Europeans, as Michael Lipp said, "I stumbled
over the not-working AltGr" (I have a French keyboard, and a Windows XP
box).
After various unsuccessful tries with XF86Config, I had a good look at the
results of xev. The xev downloaded with Cygwin XFree, and xev on Sun Solaris
give similar results: when I press the single key AltGr, xev says:
KeyPress event, serial 18, synthetic NO, window 0xc1,
root 0x3a, subw 0x0, time 2826093, (105,60), root:(899,527),
state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 characters:  ""
KeyPress event, serial 18, synthetic NO, window 0xc1,
root 0x3a, subw 0x0, time 2826093, (105,60), root:(899,527),
state 0x14, keycode 113 (keysym 0xfe03, ISO_Level3_Shift), same_screen
YES,
XLookupString gives 0 characters:  ""
I then tried xmodmap with the following commands:
clear Mod5
keycode 113 = Mode_switch
add Mod3 = Mode_switch
-> result when pressing AltGr: keycode 37 (Control_L) + keycode 113
(Mode_switch)
Of course, xterm or emacs don't understand... OK, well is there an unused
key at the bottom of the keyboard?
XFree doesn't see the "Windows " key at all, but I have a key which, when
pressed in a Windows application, does the same as right click. xev sees
this key as keycode 101. So I feed this into xmodmap:
clear Mod5
keycode 101 = Mode_switch
add Mod3 = Mode_switch
keycode 10 = ampersand 1
keycode 11 = eacute 2 asciitilde
keycode 12 = quotedbl 3 numbersign
keycode 13 = apostrophe 4 braceleft
keycode 14 = parenleft 5 bracketleft
keycode 15 = minus 6 bar
keycode 16 = egrave 7 grave
keycode 17 = underscore 8 backslash
keycode 18 = ccedilla 9 asciicircum
keycode 19 = agrave 0 at
keycode 20 = parenright degree bracketright
keycode 21 = equal plus braceright
Bingo! xterm and emacs work!  Except I use this odd key instead of AltGr,
which I *REALLY* would prefer.
Hope this helps...

Philippe Auclair
**
Institut National de la Recherche Agronomique
Unité Centrale Informatique de Jouy
Domaine de Vilvert, 78352 Jouy-en-Josas CEDEX, France
[EMAIL PROTECTED]
tel +33 1 34 65 26 95, fax +33 1 34 65 24 03
**

Re: XFree86 4.3.0 and AltGr

[Philippe Auclair]

Hi,

Gosh, what an exciting thread about "Proper attribution of patches"!

Now, to the point... As many Europeans, as Michael Lipp said, "I stumbled
over the not-working AltGr" (I have a French keyboard, and a Windows XP
box).

After various unsuccessful tries with XF86Config, I had a good look at the
results of xev. The xev downloaded with Cygwin XFree, and xev on Sun Solaris
give similar results: when I press the single key AltGr, xev says:
KeyPress event, serial 18, synthetic NO, window 0xc1,
root 0x3a, subw 0x0, time 2826093, (105,60), root:(899,527),
state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 characters:  ""

KeyPress event, serial 18, synthetic NO, window 0xc1,
root 0x3a, subw 0x0, time 2826093, (105,60), root:(899,527),
state 0x14, keycode 113 (keysym 0xfe03, ISO_Level3_Shift), same_screen
YES,
XLookupString gives 0 characters:  ""

I then tried xmodmap with the following commands:
clear Mod5
keycode 113 = Mode_switch
add Mod3 = Mode_switch

-> result when pressing AltGr: keycode 37 (Control_L) + keycode 113
(Mode_switch)

Of course, xterm or emacs don't understand... OK, well is there an unused
key at the bottom of the keyboard?
XFree doesn't see the "Windows " key at all, but I have a key which, when
pressed in a Windows application, does the same as right click. xev sees
this key as keycode 101. So I feed this into xmodmap:
clear Mod5
keycode 101 = Mode_switch
add Mod3 = Mode_switch
keycode 10 = ampersand 1
keycode 11 = eacute 2 asciitilde
keycode 12 = quotedbl 3 numbersign
keycode 13 = apostrophe 4 braceleft
keycode 14 = parenleft 5 bracketleft
keycode 15 = minus 6 bar
keycode 16 = egrave 7 grave
keycode 17 = underscore 8 backslash
keycode 18 = ccedilla 9 asciicircum
keycode 19 = agrave 0 at
keycode 20 = parenright degree bracketright
keycode 21 = equal plus braceright

Bingo! xterm and emacs work!  Except I use this odd key instead of AltGr,
which I *REALLY* would prefer.

Hope this helps...

Philippe Auclair
**
Institut National de la Recherche Agronomique
Unité Centrale Informatique de Jouy
Domaine de Vilvert, 78352 Jouy-en-Josas CEDEX, France
[EMAIL PROTECTED]
tel +33 1 34 65 26 95, fax +33 1 34 65 24 03
**

Re: XFree86-bin-4.3.0-7 xterm keyboard focus problems

[Harold L Hunt II]

Brian Ford wrote:

Igor,

This has been reported several times before.  Although, you have probably
contributed a more detailed analysis.
I don't know if xterm should depend on Xaw, but I do know that Xaw needs a
hack similar to the lesstif one for VendorShell (from memory).  Or maybe
it was Xaw3d that needs that.
Sorry to be so nebulous.  I thought this info might tickle someones memory
or fancy.
Right, the root problem is the switch from static Xt/Xaw to shared 
Xt/Xaw.  Brian is right, we need a fix for VenderShell, just like we did 
for lesstif about two or three weeks ago.  We need it fast too, based on 
the frequency of this bug being reported.

Harold

Re: XFree86-bin-4.3.0-7 xterm keyboard focus problems

[Brian Ford]

Igor,

This has been reported several times before.  Although, you have probably
contributed a more detailed analysis.

I don't know if xterm should depend on Xaw, but I do know that Xaw needs a
hack similar to the lesstif one for VendorShell (from memory).  Or maybe
it was Xaw3d that needs that.

Sorry to be so nebulous.  I thought this info might tickle someones memory
or fancy.

On Tue, 11 Nov 2003, Igor Pechtchanski wrote:

> Hi, all,
>
> I noticed that the xterm executable that comes with the 4.3.0-7 version of
> XFree86-bin has problems with keyboard focus.  After the mouse pointer
> entered and left the window once, the keyboard input is ignored unless the
> mouse pointer is in the window.  The window apparently keeps the focus,
> but no keyboard input is processed.  Other executables don't suffer from
> this problem, and extracting the xterm from XFree86-bin-4.3.0-4 fixes it.
> I've tried running this with Exceed and also remotely on Linux through
> ssh.  FWIW, here are the relevant files:
>
> $ ls -l /usr/X11R6/bin/xterm-*
> -r-xr-xr-x+   1 igor Users  262656 Oct 30 11:14 
> /usr/X11R6/bin/xterm-4.3.0-7.exe
> -rwx--x--x1 igor Administ   804352 Sep 20 14:52 
> /usr/X11R6/bin/xterm-4.3.0-4.exe
>
> The second file is manually extracted from the XFree86-bin-4.3.0-4
> tarball.  The reported version numbers are identical:
>
> $ xterm-4.3.0-7.exe -version
> XFree86 4.2.99.903(174)
> $ xterm-4.3.0-4 -version
> XFree86 4.2.99.903(174)
>
> The latter version seems to depend on three extra DLLs:
>
> $ cygcheck /usr/X11R6/bin/xterm-4.3.0-7.exe | sort -b > /tmp/a7
> $ cygcheck /usr/X11R6/bin/xterm-4.3.0-4.exe | sort -b > /tmp/a4
> $ diff -I xterm -w /tmp/a4 /tmp/a7
> 4a5
> >   C:/cygwin/usr/X11R6/bin\cygXaw-7.dll
> 6a8
> > C:/cygwin/usr/X11R6/bin\cygXmu-6.dll
> 7a10
> >   C:/cygwin/usr/X11R6/bin\cygXt-6.dll
>
> I think libXt used to be linked in statically, but I don't recall xterm
> being dependent on libXaw before.
>
> xterm is the only executable that seems to have changed behavior in my
> case (xev, for example, works fine, i.e., respects the window manager's
> focus policy).  I suspect this new dependence on libXaw is the culprit, as
> other Xaw-enabled apps (xfig, editres, etc) are notorious for having a
> mind of their own when it comes to keyboard focus.
>
> Can anyone confirm/deny this?  If an unwanted dependence on libXaw was
> introduced in the xterm build, can it please be removed somehow?
> Thanks,
>   Igor
>

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444

Re: xfree86 fails to see/render TrueType fonts

[Christopher Faylor]

On Tue, Nov 11, 2003 at 08:26:20AM -0800, Michael Bax wrote:
>XFree86 fails to render TTF fonts on my computer.  This is true for the
>bundled fonts/TTF/* as well as the Windows fonts.

This is not the right mailing list for cygwin-xfree observations.

Redirecting.

>There are two problems:
>
>1. XFree86 does not appear to include the X11 fonts/TTF directory in the
>font path by default.  This can be shown by removing the Luxi fonts in the
>fonts/Type1 directory and rehashing.  The server should use the TTF versions
>instead, but it does not see these fonts at all.  This can be fixed using
>xset fp+, but surely the TTF font directory should be included in the path
>by default?
>
>2. After xset fp+ and rehash, the TrueType fonts are listed in e.g.
>xfontsel.  However, they are not rendered (or are rendered blank)!  The same
>is true for my custom-installed TrueType fonts.  They worked in XFree86 3.x,
>however, using the same installation procedure.
>
>Other fonts are fine, but all TrueType fonts are effectively invisible.
>
>This is on a fresh installation of Cygwin DLL 1.5.5-1 running on Windows
>2000 SP4, with XFree86-bin-4.3.0-6.
>
>Cheers
>Michael

Re: [XFree86] screen redraw problem

[J S]

Thanks Mark,

Unfortunately that didn't make any difference.

   Maybe your app is expecting backing store.  You can start XFree86
with backing store "startx -- +bs".
			Mark.

On Wed, 5 Nov 2003, J S wrote:

> Is there anymore information I need to add to this post? I would really 
like
> to get some help with it. The logs don't seem to be showing anything. 
I've
> tried setting different color depths, and screen resolutions but to no
> avail.
>
> Hi,
>
> I have an application which has some boxes in the window. The window 
itself
> is scrollable. When I scroll down -  no problem, but when I scroll up 
the
> boxes turn into long vertical bars. This problem doesn't happen with 
Exceed,
> but on XFree86 (both Linux XFree86 and Cygwin-XFree) it does.
>
> Can anyone advise me whether this is a bug, or is there some setting I 
need
> to add? Let me know if you need anymore information.
>
> Thanks for any help.
>
> JS.
>
> _
> Stay in touch with absent friends - get MSN Messenger
> http://www.msn.co.uk/messenger
>
> ___
> XFree86 mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/xfree86
>

_
Sign-up for a FREE BT Broadband connection today! 
http://www.msn.co.uk/specials/btbroadband

Re: [XFree86] screen redraw problem

[Mark Vojkovich]

   Maybe your app is expecting backing store.  You can start XFree86
with backing store "startx -- +bs".  

Mark.

On Wed, 5 Nov 2003, J S wrote:

> Is there anymore information I need to add to this post? I would really like 
> to get some help with it. The logs don't seem to be showing anything. I've 
> tried setting different color depths, and screen resolutions but to no 
> avail.
> 
> Hi,
> 
> I have an application which has some boxes in the window. The window itself
> is scrollable. When I scroll down -  no problem, but when I scroll up the
> boxes turn into long vertical bars. This problem doesn't happen with Exceed,
> but on XFree86 (both Linux XFree86 and Cygwin-XFree) it does.
> 
> Can anyone advise me whether this is a bug, or is there some setting I need
> to add? Let me know if you need anymore information.
> 
> Thanks for any help.
> 
> JS.
> 
> _
> Stay in touch with absent friends - get MSN Messenger 
> http://www.msn.co.uk/messenger
> 
> ___
> XFree86 mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/xfree86
> 

Re: XFree86 for cygwin installation hanging - a clarification

[Harold L Hunt II]

Paul,

Did you see my reply?  I said to skip the XFree86-bin-icons package as a 
work-around or to delete a particular file.  Please read the reply and 
let me know if it helps:

http://cygwin.com/ml/cygwin-xfree/2003-10/msg00332.html

Also, you want the XFree86-startup-scripts package, and you want to use 
startxwin.bat to start XWin.exe.  Please see the following User's Guide 
section:

http://xfree86.cygwin.com/docs/ug/using.html#using-starting-bat

Hope that helps,

Harold

Paul Thomas wrote:

Hello once more,

The problem with the XFree85 install is associated with the 
XFree-bin-icons package.  If I eliminate that from the list of packages, 
I get a sufficiently complete installation that I can at least run 
Nedit.  XWin still produces a background and nothing else.

Yours

Paul Thomas

Hello,

I have been trying to load XFree86 for Cygwin, using the Cygwin web 
installation.  I have a Compaq Athlon 1700 based machine, running 
Windows XP home edition.

Cygwin itself is fine.  All components run perfectly, except XFree86 and 
anything that depends on it.  The download ends in a message that it is 
unable to find file ""; pressing OK gets the installation underway but 
it then hangs at varying points in the installation.  I have uninstalled 
before each attempt. Also, when I shut down Windows, the post-install 
programme is still running and has to be stopped.   Invoking XWin, with 
any combination of arguments results in the background coming up but 
nothing else.

What should I do?  Try downloading and installing from hard disk?

Thank you in advance for any advice that you can give me.

Paul Thomas

Re: XFree86 for cygwin installation hanging

[Brian Ford]

On Mon, 27 Oct 2003, Paul Thomas wrote:

> Invoking XWin, with any combination of arguments results in the
> background coming up but nothing else.
>
FYI, this is normal behavior.

You need to launch a window manager (like twm) unless you are using the
-multiwindow switch.  Then, you might also want to launch a client or two
(like xterm).

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444

Re: XFree86 for cygwin installation hanging

[Harold L Hunt II]

Paul,

It sounds like you may need to try another mirror.

Also, you are probably having a problem with the XFree86-bin-icons 
package, which was fixed by the bash-2.05b-16 release.

However, you may still have problems due to the ordering in which 
postinstall scripts are running and depending on whether your mirror has 
bash-2.05b-16 yet (it should, it has been a few days).

I would recommend deleting the c:\cygwin directory (or wherever you 
installed), selecting another mirror, downloading and installing again. 
 This time, let it install the base set of packages first.  Then, go 
back and pick the extras you want.  Be sure to leave XFree86-bin-icons 
until everything else is working.

Good luck,

Harold

Paul Thomas wrote:

Hello,

I have been trying to load XFree86 for Cygwin, using the Cygwin web 
installation.  I have a Compaq Athlon 1700 based machine, running 
Windows XP home edition.

Cygwin itself is fine.  All components run perfectly, except XFree86 and 
anything that depends on it.  The download ends in a message that it is 
unable to find file ""; pressing OK gets the installation underway but 
it then hangs at varying points in the installation.  I have uninstalled 
before each attempt. Also, when I shut down Windows, the post-install 
programme is still running and has to be stopped.   Invoking XWin, with 
any combination of arguments results in the background coming up but 
nothing else.

What should I do?  Try downloading and installing from hard disk?

Thank you in advance for any advice that you can give me.

Paul Thomas

Re: XFree86-bin-icons

[Igor Pechtchanski]

Harold,

I have suggested to the original poster to follow up on cygwin-xfree;
apparently he never did.

You can ignore the "No package" message -- when I inserted the postinstall
progress page into setup, setup tried to keep track of the postinstall
scripts in the newly installed packages, and run them first, and then run
all the scripts that were left in /etc/postinstall (with the "No package"
designation, indicating that they didn't belong to any package).
Apparently, something went wrong with the tracking code, and all the
scripts were discovered only when browsing the /etc/postinstall
directory (alternatively, my code could be looking in the wrong place for
the associated package name).  Either way, I haven't had the time to
investigate it, and it seems harmless enough for now to not be at the top
of my TODO list.  Hope this explains it adequately.

If you want to track what's going on in the hanging script in more detail,
change the #! line at the top of the script to "bash -x" (or "sh -x").
Then look at /var/log/setup.log.full for the script output.  Similarly for
the preremove script.
Igor

On Mon, 29 Sep 2003, Harold L Hunt II wrote:

> [Discussion on this issue is now taking place where it should have in
> the first place: cygwin-xfree.  Please follow the cygwin-xfree mailing
> list for further posts.]
>
> Igor,
>
> Okay, that explains why I couldn't find the message in cygwin-xfree.  I
> really wish someone would have redirected the question over here... I
> never saw it.
>
>  > FWIW, you can force the order of execution of the XFree86-bin-icons.sh
>  > postinstall script by making the package dependent on XFree86-bin and
>  > others, but that would most likely defeat the purpose of the package.
>
> Thanks.  I actually did that just now, right before you suggested it.
> However, I didn't know that it would force the order of post-install
> script execution; that is a nice side-effect.  The bin-icons package
> should logically depend on the bin package.  People can manually
> unselect it if they want to.
>
> >The XFree86-bin-icons package is buggy.  It's basically a postinstall
> >script that tries to create icons for the X programs that are installed
> >on your machine.  The problem is that it tries to create them in the
> >Start Menu for "All Users" without checking whether the current user can
> >write to it.
>
> That's not entirely true.  For example, my account has Administrator
> priveleges on my machine, the script runs fine when I launch it from a
> bash prompt; so file permissions are not an issue.
>
> >I'm not quite sure why it hangs for you, but you can try
> >runnning that script manually via "bash -x" and seeing where it hangs.
>
> It doesn't hang when you do this.
>
> Something strange is going on here... setup.exe says "Running: No
> Package /etc/postinstal/XFree86-bin-icons".  What is up with the "No
> Package"?  Is that indicating the real problem?
>
> Another thing is that an Uninstall of XFree86-bin-icons also hangs when
> it tries to run the preremove script.  Yet, running the preremove script
> by hand never causes any problems (e.g. bash -x
> /etc/preremove/XFree86-bin-icons.sh).
>
> What gives?
>
> Harold

-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

Re: XFree86-bin-icons

[Harold L Hunt II]

[Discussion on this issue is now taking place where it should have in 
the first place: cygwin-xfree.  Please follow the cygwin-xfree mailing 
list for further posts.]

Igor,

Okay, that explains why I couldn't find the message in cygwin-xfree.  I 
really wish someone would have redirected the question over here... I 
never saw it.

> FWIW, you can force the order of execution of the XFree86-bin-icons.sh
> postinstall script by making the package dependent on XFree86-bin and
> others, but that would most likely defeat the purpose of the package.
Thanks.  I actually did that just now, right before you suggested it. 
However, I didn't know that it would force the order of post-install 
script execution; that is a nice side-effect.  The bin-icons package 
should logically depend on the bin package.  People can manually 
unselect it if they want to.


The XFree86-bin-icons package is buggy.  It's basically a postinstall
script that tries to create icons for the X programs that are installed
on your machine.  The problem is that it tries to create them in the
Start Menu for "All Users" without checking whether the current user can
write to it.
That's not entirely true.  For example, my account has Administrator 
priveleges on my machine, the script runs fine when I launch it from a 
bash prompt; so file permissions are not an issue.

I'm not quite sure why it hangs for you, but you can try
runnning that script manually via "bash -x" and seeing where it hangs.
It doesn't hang when you do this.

Something strange is going on here... setup.exe says "Running: No 
Package /etc/postinstal/XFree86-bin-icons".  What is up with the "No 
Package"?  Is that indicating the real problem?

Another thing is that an Uninstall of XFree86-bin-icons also hangs when 
it tries to run the preremove script.  Yet, running the preremove script 
by hand never causes any problems (e.g. bash -x 
/etc/preremove/XFree86-bin-icons.sh).

What gives?

Harold

Re: XFree86-bin-icons

[Igor Pechtchanski]

Harold,

Well, the original (that Mark quoted) was on the cygwin@ list, namely
.

FWIW, you can force the order of execution of the XFree86-bin-icons.sh
postinstall script by making the package dependent on XFree86-bin and
others, but that would most likely defeat the purpose of the package.
Igor

On Mon, 29 Sep 2003, Harold L Hunt II wrote:

> Igor,
>
> You wrote the original message in this thread, correct?  Was it sent to
> cygwin-xfree, cygwin, or cygwin-apps?  I am asking only because I can't
> find a log of it anywhere... was it eaten by the mail server?
>
> Actually, there is another bug in XFree86-bin-icons, that is, it doesn't
> usually create icons for any package except emacs unless it is run
> manually from the command-line.  I haven't looked into this enough to
> see if it only happens on fresh installs (implying that the problem is
> probably that XFree86-bin hasn't been installed yet) or if it happens
> all the time.  That bug needs to be fixed before any sort of permissions
> bug.  As is, it is pretty worthless.
>
> Harold
>
> Igor Pechtchanski wrote:
>
> > Mark,
> >
> > Please don't send personal e-mail on Cygwin issues unless specifically
> > requested.  Also, please make sure your mailer honors the Reply-To:
> > header.  I'm forwarding this reply to the appropriate list.
> >
> > More inline below.
> >
> > On Mon, 29 Sep 2003, Mark Anderson wrote:
> >
> >
> >>Igor;
> >>I am writing to you in reference to this posting.
> >>
> >>
> >>> The XFree86-bin-icons package is buggy.  It's basically a postinstall
> >>>script that tries to create icons for the X programs that are installed
> >>>on your machine.  The problem is that it tries to create them in the
> >>>Start Menu for "All Users" without checking whether the current user can
> >>>write to it.  I'm not quite sure why it hangs for you, but you can try
> >>>runnning that script manually via "bash -x" and seeing where it hangs.
> >>>If you do investigate, please post your findings to the cygwin-xfree
> >>>list.  If you don't want to bother, simply do not install the
> >>>XFree86-bin-icons package (all it does is provide the Start Menu icons
> >>>-- not essential).
> >>>Igor
> >>>P.S. Note to setup developers (myself included -- just want to get this
> >>>into the archives for now): even though postinstall scripts are not
> >>>interactive, their output *is* logged, so they should print something
> >>>that tracks their progress (maybe even be run with the -x flag, but
> >>>that's probably overkill).  We should put some words to that effect on
> >>>the setup.html page.
> >>
> >>Thanks but I have a few issues also.
> >>1 I do not know how to manually run this with the -x flag what are the
> >>steps, and where do I get the package?
> >
> >
> > This wasn't a note for you, it was for setup developers.  FWIW, you can
> > run the script using "sh -x /etc/postinstall/XFree86-bin-icons.sh".
> >
> >
> >>2 setup.exe will not let me UN-CHOOSE this option I have run this in
> >>skip uninstall I have selected the package and removed the checkbox and
> >>SETUP.EXE still hangs on XFree86-bin-icons. Since setup has uninstalled
> >>everything and I can not get past XFree86-bin-icons, cygwin wont run. IF
> >>I try to mess around I may be able to get the basic cygwin to run.
> >>
> >>HELP
> >>Thank
> >>Mark Anderson
> >
> >
> > I don't understand what you're trying to say here.  You should be able to
> > simply unselect the package from the list of currently installed ones
> > using setup.  If you still have trouble, simply erase
> > /etc/postinstall/XFree86-bin-icons.sh (you can even do it using Windows
> > Explorer), and don't reinstall the XFree86-bin-icons package.
> >   Igor

-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

Re: XFree86-bin-icons

[Harold L Hunt II]

Igor,

You wrote the original message in this thread, correct?  Was it sent to 
cygwin-xfree, cygwin, or cygwin-apps?  I am asking only because I can't 
find a log of it anywhere... was it eaten by the mail server?

Actually, there is another bug in XFree86-bin-icons, that is, it doesn't 
usually create icons for any package except emacs unless it is run 
manually from the command-line.  I haven't looked into this enough to 
see if it only happens on fresh installs (implying that the problem is 
probably that XFree86-bin hasn't been installed yet) or if it happens 
all the time.  That bug needs to be fixed before any sort of permissions 
bug.  As is, it is pretty worthless.

Harold

Igor Pechtchanski wrote:

Mark,

Please don't send personal e-mail on Cygwin issues unless specifically
requested.  Also, please make sure your mailer honors the Reply-To:
header.  I'm forwarding this reply to the appropriate list.
More inline below.

On Mon, 29 Sep 2003, Mark Anderson wrote:


Igor;
I am writing to you in reference to this posting.

The XFree86-bin-icons package is buggy.  It's basically a postinstall
script that tries to create icons for the X programs that are installed
on your machine.  The problem is that it tries to create them in the
Start Menu for "All Users" without checking whether the current user can
write to it.  I'm not quite sure why it hangs for you, but you can try
runnning that script manually via "bash -x" and seeing where it hangs.
If you do investigate, please post your findings to the cygwin-xfree
list.  If you don't want to bother, simply do not install the
XFree86-bin-icons package (all it does is provide the Start Menu icons
-- not essential).
   Igor
P.S. Note to setup developers (myself included -- just want to get this
into the archives for now): even though postinstall scripts are not
interactive, their output *is* logged, so they should print something
that tracks their progress (maybe even be run with the -x flag, but
that's probably overkill).  We should put some words to that effect on
the setup.html page.
Thanks but I have a few issues also.
1 I do not know how to manually run this with the -x flag what are the
steps, and where do I get the package?


This wasn't a note for you, it was for setup developers.  FWIW, you can
run the script using "sh -x /etc/postinstall/XFree86-bin-icons.sh".

2 setup.exe will not let me UN-CHOOSE this option I have run this in
skip uninstall I have selected the package and removed the checkbox and
SETUP.EXE still hangs on XFree86-bin-icons. Since setup has uninstalled
everything and I can not get past XFree86-bin-icons, cygwin wont run. IF
I try to mess around I may be able to get the basic cygwin to run.
HELP
Thank
Mark Anderson


I don't understand what you're trying to say here.  You should be able to
simply unselect the package from the list of currently installed ones
using setup.  If you still have trouble, simply erase
/etc/postinstall/XFree86-bin-icons.sh (you can even do it using Windows
Explorer), and don't reinstall the XFree86-bin-icons package.
Igor

Re: XFree86-bin-icons

[Igor Pechtchanski]

Mark,

Please don't send personal e-mail on Cygwin issues unless specifically
requested.  Also, please make sure your mailer honors the Reply-To:
header.  I'm forwarding this reply to the appropriate list.

More inline below.

On Mon, 29 Sep 2003, Mark Anderson wrote:

> Igor;
> I am writing to you in reference to this posting.
>
>>  The XFree86-bin-icons package is buggy.  It's basically a postinstall
>> script that tries to create icons for the X programs that are installed
>> on your machine.  The problem is that it tries to create them in the
>> Start Menu for "All Users" without checking whether the current user can
>> write to it.  I'm not quite sure why it hangs for you, but you can try
>> runnning that script manually via "bash -x" and seeing where it hangs.
>> If you do investigate, please post your findings to the cygwin-xfree
>> list.  If you don't want to bother, simply do not install the
>> XFree86-bin-icons package (all it does is provide the Start Menu icons
>> -- not essential).
>> Igor
>> P.S. Note to setup developers (myself included -- just want to get this
>> into the archives for now): even though postinstall scripts are not
>> interactive, their output *is* logged, so they should print something
>> that tracks their progress (maybe even be run with the -x flag, but
>> that's probably overkill).  We should put some words to that effect on
>> the setup.html page.
>
> Thanks but I have a few issues also.
> 1 I do not know how to manually run this with the -x flag what are the
> steps, and where do I get the package?

This wasn't a note for you, it was for setup developers.  FWIW, you can
run the script using "sh -x /etc/postinstall/XFree86-bin-icons.sh".

> 2 setup.exe will not let me UN-CHOOSE this option I have run this in
> skip uninstall I have selected the package and removed the checkbox and
> SETUP.EXE still hangs on XFree86-bin-icons. Since setup has uninstalled
> everything and I can not get past XFree86-bin-icons, cygwin wont run. IF
> I try to mess around I may be able to get the basic cygwin to run.
>
> HELP
> Thank
> Mark Anderson

I don't understand what you're trying to say here.  You should be able to
simply unselect the package from the list of currently installed ones
using setup.  If you still have trouble, simply erase
/etc/postinstall/XFree86-bin-icons.sh (you can even do it using Windows
Explorer), and don't reinstall the XFree86-bin-icons package.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

Re: Xfree86 is slow! with software like MATLAB

[Holger Vogt]

Hi all,

Another reply to Harold's question:

> So, are the fast apps non-OpenGL and the slow apps OpenGL?

Thae layout editor MAGIC, compiled with Cygwin 
(http://bach.ece.jhu.edu/~tim/programs/magic/windows/windows.html) and 
using OpenGL is totally slow (unusable) in -multiwindow mode, but o.k. 
in -rootless.

Regards

Holger

Re: Xfree86 is slow! with software like MATLAB

[g . macaulay]

On 27 Sep 2003 at 18:19, Milos Komarcevic wrote:

> On Thu, 2003-09-25 at 23:29, Alexander Gottwald wrote:
> > [EMAIL PROTECTED] wrote:
> > 
> > > does not show such a marked difference. One point of difference is that the
> > > Matlab GUI is written entirely in Java, while the other program uses GTK.
> > 
> > With Swing (JFC)? Swing is the most stupid GUI I've ever seen. It draws all
> > components to a local buffer and transfers these buffers as bitmap to the
> > xserver. Most likely this transfer is much slower than a simple "draw a gray
> > rect at 127,86" and "draw text at 129, 88" as GTK and any other "normal" X11
> > does its drawing.

I don't know whether Matlab uses Swing or not. In any case, as Harold 
suggested, the Matlab GUI runs much faster when Cygwin/XFree86 is run in single 
window mode.

Matlab has two graphical bits - the main window where one types commands, 
clicks on buttons and uses menus, etc, and the figure windows that display 
graphs, etc. The first are done using Java while the second are done using 
OpenGL or some other X toolkit (sometimes it looks to be just transferring a 
bitmap from the X client to the X server). The speedup in the first case is 
remarkable when moving from multi to single window mode in Cygwin/XFree86 - 
from taking several seconds to redraw the buttons in the button bar to nearly 
instant. The speedup for the figures is much less - things happen in about 70% 
of the time. 

So in reply to Harold's question:

> So, are the fast apps non-OpenGL and the slow apps OpenGL?,

the answer is no - the slow part of Matlab is not the OpenGL part, but the Java 
part.

Note also that the difference for the figure window drawing (OpenGL) times 
between Cygwin/XFree86 and Xwin32 are minimal, but are quite large for the 
command window (Java) when in multi-window mode.


Regards

Gavin

 
> Don't know much about toolkits, but even xfig (or LyX) for Cygwin runs
> slow locally on Cygwin/XFree86 in comparison to XWin32, so I think
> Harold is 100% on it with the Native GDI engine (no speed issues when
> run in rootless+twm)

Re: Xfree86 is slow! with software like MATLAB

[Milos Komarcevic]

On Thu, 2003-09-25 at 23:29, Alexander Gottwald wrote:
> [EMAIL PROTECTED] wrote:
> 
> > does not show such a marked difference. One point of difference is that the
> > Matlab GUI is written entirely in Java, while the other program uses GTK.
> 
> With Swing (JFC)? Swing is the most stupid GUI I've ever seen. It draws all
> components to a local buffer and transfers these buffers as bitmap to the
> xserver. Most likely this transfer is much slower than a simple "draw a gray
> rect at 127,86" and "draw text at 129, 88" as GTK and any other "normal"
> X11 does its drawing.

Don't know much about toolkits, but even xfig (or LyX) for Cygwin runs
slow locally on Cygwin/XFree86 in comparison to XWin32, so I think
Harold is 100% on it with the Native GDI engine (no speed issues when
run in rootless+twm)

Best regards to all,

Milos

Re: Xfree86 is slow! with software like MATLAB

[Alexander Gottwald]

[EMAIL PROTECTED] wrote:

> does not show such a marked difference. One point of difference is that the
> Matlab GUI is written entirely in Java, while the other program uses GTK.

With Swing (JFC)? Swing is the most stupid GUI I've ever seen. It draws all
components to a local buffer and transfers these buffers as bitmap to the
xserver. Most likely this transfer is much slower than a simple "draw a gray
rect at 127,86" and "draw text at 129, 88" as GTK and any other "normal"
X11 does its drawing.

bye
ago
-- 
 [EMAIL PROTECTED]
 http://www.gotti.org   ICQ: 126018723

Re: Xfree86 is slow! with software like MATLAB

[Harold L Hunt II]

Gavin,

I forgot to mention something that is becoming apparent now:

Matlab may be using OpenGL, which is implemented in software in 
Cygwin/XFree86.  Thus, OpenGL is extremely slow in Cygwin/XFree86.  Some 
of the commercial X Servers for Windows have an accelerated 
implementation of OpenGL that basically passes off the calls to the 
Win32 OpenGL layer.  This was also implemented in X on X (XFree86 for 
Mac OS X), so a reference implementation is available if someone wanted 
to look into doing this.

So, are the fast apps non-OpenGL and the slow apps OpenGL?

Harold

[EMAIL PROTECTED] wrote:
Harold & Mark,

To contribute to the discussion:

I see the same problem when running Matlab. In my case Matlab is run on a 
Compaq/HP Tru64 computer with the GUI displayed on my Windows PC running 
cygwin/xfree in multiwindow mode. I also have a commercial X server (xwin32) 
available on my PC. Display of Matlab graphics, or even updating of the icons 
in Matlab window menubar are considerably slower when running via cygwin/xfree -
 the graphics benchmarks that Matlab provide run approximately 100 times slower 
under cygwin/xfree than under xwin32. Trials of other commercial X servers 
indicated that some are slow and some are quick, probably due to the reason 
given by Harold.

An in-house, graphically intensive, X program run under the same setup as above 
does not show such a marked difference. One point of difference is that the 
Matlab GUI is written entirely in Java, while the other program uses GTK.

Regards

Gavin

On 24 Sep 2003 at 22:27, Harold L Hunt II wrote:


Mark,

Using the default -multiwindow mode (with the integrated window manager) 
is slower than all of the other modes.

You can run XWin from startxwin.bat instead with:

XWin -rootless

Then you need to start a window manager like 'twm':

run twm

Cygwin/XFree86 works by drawing to an offscreen framebuffer (using the 
primary CPU), then transferring updated portions of the offscreen 
framebuffer to the screen.  Work has begun, and is also essentially 
stalled, on the "Native GDI" engine for Cygwin/XFree86 that translates 
each X graphics call to a GDI graphics call; this has the advantage of 
utilizing the power of the graphics processing unit (GPU).  Exceed and 
possibly other commercial X Servers do something similar to the Native 
GDI engine and are thus faster.

On a side note, the speed of your graphics card and the quality of its 
drivers are very important for the performance of Cygwin/XFree86.  A two 
or three year old ATI or NVIDIA PCI (AGP is better) graphics card will 
be substantially faster than a 5 year old PCI graphics card from a 
no-name vendor.  On the other hand, I use a 5 year old Diamond PCI 
graphics card and it works just fine.

That's about it.

Harold

Mark Jones wrote:

I have tried using XFree86 (linux and cygwin) for Cygwin's XFree86 and 
Linux's XFree86 and have found it to be extremely slow at refreshing the
screen making it nearly impossible to use MATLAB's editor reasonably. 
However, using a MS Windows emulator like Xoftware or Hummingbird's Exceed
provides extremely fast response such that it is useable with various programs
including MATLAB.  Is there a valid reason for this?  Is it being addressed?

Thanks,

Mark

Re: Xfree86 is slow! with software like MATLAB

[g . macaulay]

Harold & Mark,

To contribute to the discussion:

I see the same problem when running Matlab. In my case Matlab is run on a 
Compaq/HP Tru64 computer with the GUI displayed on my Windows PC running 
cygwin/xfree in multiwindow mode. I also have a commercial X server (xwin32) 
available on my PC. Display of Matlab graphics, or even updating of the icons 
in Matlab window menubar are considerably slower when running via cygwin/xfree -
 the graphics benchmarks that Matlab provide run approximately 100 times slower 
under cygwin/xfree than under xwin32. Trials of other commercial X servers 
indicated that some are slow and some are quick, probably due to the reason 
given by Harold.

An in-house, graphically intensive, X program run under the same setup as above 
does not show such a marked difference. One point of difference is that the 
Matlab GUI is written entirely in Java, while the other program uses GTK.

Regards

Gavin

On 24 Sep 2003 at 22:27, Harold L Hunt II wrote:

> Mark,
> 
> Using the default -multiwindow mode (with the integrated window manager) 
> is slower than all of the other modes.
> 
> You can run XWin from startxwin.bat instead with:
> 
> XWin -rootless
> 
> Then you need to start a window manager like 'twm':
> 
> run twm
> 
> 
> Cygwin/XFree86 works by drawing to an offscreen framebuffer (using the 
> primary CPU), then transferring updated portions of the offscreen 
> framebuffer to the screen.  Work has begun, and is also essentially 
> stalled, on the "Native GDI" engine for Cygwin/XFree86 that translates 
> each X graphics call to a GDI graphics call; this has the advantage of 
> utilizing the power of the graphics processing unit (GPU).  Exceed and 
> possibly other commercial X Servers do something similar to the Native 
> GDI engine and are thus faster.
> 
> On a side note, the speed of your graphics card and the quality of its 
> drivers are very important for the performance of Cygwin/XFree86.  A two 
> or three year old ATI or NVIDIA PCI (AGP is better) graphics card will 
> be substantially faster than a 5 year old PCI graphics card from a 
> no-name vendor.  On the other hand, I use a 5 year old Diamond PCI 
> graphics card and it works just fine.
> 
> That's about it.
> 
> Harold
> 
> Mark Jones wrote:
> > I have tried using XFree86 (linux and cygwin) for Cygwin's XFree86 and 
> > Linux's XFree86 and have found it to be extremely slow at refreshing the
> > screen making it nearly impossible to use MATLAB's editor reasonably. 
> > However, using a MS Windows emulator like Xoftware or Hummingbird's Exceed
> > provides extremely fast response such that it is useable with various programs
> > including MATLAB.  Is there a valid reason for this?  Is it being addressed?
> > 
> > Thanks,
> > 
> > Mark
> > 
> 
> 

Re: xfree86 cut/copy/paste

[Igor Pechtchanski]

Redirecting to the correct list and replying.  Please remove  from further discussion on this topic.

On Thu, 25 Sep 2003, Bill McCormick wrote:

> Hello,
>
> Is there cut/copy/paste functionality with xfree86 (using windows clipboard)
> like there is with rxvt?
>
> I'm sure this has come up before but I can't seem to find it.
>
> Thanks,
> Bill

Bill,

Try giving a "-clipboard" argument to XWin.exe, or use the "xwinclip"
utility (although the latter is outdated, IIRC).  Search the cygwin-xfree
list archives for either "clipboard" or "xwinclip" for more details.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

Re: Xfree86 is slow! with software like MATLAB

[Harold L Hunt II]

Mark,

Mark Jones wrote:

At 10:17 PM 9/24/2003, Mark Jones wrote:

I have tried using XFree86 (linux and cygwin) for Cygwin's XFree86 and 
Linux's XFree86 and have found it to be extremely slow at refreshing 
the screen making it nearly impossible to use MATLAB's editor 
reasonably.  However, using a MS Windows emulator like Xoftware or 
Hummingbird's Exceed provides extremely fast response such that it is 
useable with various programs including MATLAB.  Is there a valid 
reason for this?  Is it being addressed?


Also, I am speaking strictly about remote display, not about MATLAB with 
XFree86 on a local Linux box.  Sitting at a Linux XFree86 box it is 
plenty fast, but remotely it is not fast at all, which makes me wonder why.
That is an interesting clarification that you made... it really confuses 
your original question quite nicely.

MATLAB isn't available as an X app on top of Windows, so you obviously 
must be running it remotely.  In addition, XFree86 for Linux and 
Cygwin/XFree86 are completely unrelated as far as performance is concerned.

Are you still also saying that the same remote app (MATLAB) displays 
more quickly using Exceed than it does with Cygwin/XFree86?  If so, then 
my original reply (which you didn't have yet when you wrote your first 
reply) still applies.

Harold

Re: Xfree86 is slow! with software like MATLAB

[Harold L Hunt II]

Mark,

Using the default -multiwindow mode (with the integrated window manager) 
is slower than all of the other modes.

You can run XWin from startxwin.bat instead with:

XWin -rootless

Then you need to start a window manager like 'twm':

run twm

Cygwin/XFree86 works by drawing to an offscreen framebuffer (using the 
primary CPU), then transferring updated portions of the offscreen 
framebuffer to the screen.  Work has begun, and is also essentially 
stalled, on the "Native GDI" engine for Cygwin/XFree86 that translates 
each X graphics call to a GDI graphics call; this has the advantage of 
utilizing the power of the graphics processing unit (GPU).  Exceed and 
possibly other commercial X Servers do something similar to the Native 
GDI engine and are thus faster.

On a side note, the speed of your graphics card and the quality of its 
drivers are very important for the performance of Cygwin/XFree86.  A two 
or three year old ATI or NVIDIA PCI (AGP is better) graphics card will 
be substantially faster than a 5 year old PCI graphics card from a 
no-name vendor.  On the other hand, I use a 5 year old Diamond PCI 
graphics card and it works just fine.

That's about it.

Harold

Mark Jones wrote:
I have tried using XFree86 (linux and cygwin) for Cygwin's XFree86 and 
Linux's XFree86 and have found it to be extremely slow at refreshing the 
screen making it nearly impossible to use MATLAB's editor reasonably.  
However, using a MS Windows emulator like Xoftware or Hummingbird's 
Exceed provides extremely fast response such that it is useable with 
various programs including MATLAB.  Is there a valid reason for this?  
Is it being addressed?

Thanks,

Mark

Re: Xfree86 is slow! with software like MATLAB

[Mark Jones]

At 10:17 PM 9/24/2003, Mark Jones wrote:
I have tried using XFree86 (linux and cygwin) for Cygwin's XFree86 and 
Linux's XFree86 and have found it to be extremely slow at refreshing the 
screen making it nearly impossible to use MATLAB's editor 
reasonably.  However, using a MS Windows emulator like Xoftware or 
Hummingbird's Exceed provides extremely fast response such that it is 
useable with various programs including MATLAB.  Is there a valid reason 
for this?  Is it being addressed?
Also, I am speaking strictly about remote display, not about MATLAB with 
XFree86 on a local Linux box.  Sitting at a Linux XFree86 box it is plenty 
fast, but remotely it is not fast at all, which makes me wonder why.

Mark

Re: XFree86 goes into stasis when NetMeeting is running

[Jeffrey C Honig]

Using -engine 1 solves my problem with NetMeeting.

Thanks.

Jeff

-- 
Jeffrey C. Honig <[EMAIL PROTECTED]>
http://www.honig.net/jch
GnuPG ID:14E29E13 

Re: XFree86 goes into stasis when NetMeeting is running

[Harold L Hunt II]

Jeffrey,

Netmeeting and Cygwin/XFree86 in fullscreen mode both need an exclusive 
lock on DirectDraw.  At least, that is what makes sense to me.  One way 
around this is to use the "-engine 1" command-line parameter for 
XWin.exe.  This will tell XWin.exe to use the GDI based (i.e. 
non-DirectDraw) engine to draw its graphics.  You will notice it is a 
little more sluggish than the DirectDraw engine (which is used by 
default), but it will solve your problems with NetMeeting.

Let us know if this works for you,

Harold

Jeffrey C Honig wrote:
I've recently switched back to Cygwin/XFree86 from Exceed (ugh) and
rediscovered a problem.
I'm running XFree86 with -fullscreen on my Win2k laptop.  Whenever I
start NetMeeting to join a call, XFree86 will no longer display until I
exit NetMeeting.  If I use Alt-Tab to switch to XFree86, it will not be
restored.  As soon as I exit NetMeeting I am able to switch to XFree86
again.
What gives?

Thanks.

Jeff

Re: XFree86 goes into stasis when NetMeeting is running

[Jeffrey C Honig]

> Try adding "-engine 1" to the XWin command line which should use GDI
> calls instead of DirectX calls to draw.  NetMeeting probably grabs the
> surface and doesn't release it until you quit.

I'll try it.

What are the pros and cons of using GDI instead of DirectX?

Thanks.

Jeff

-- 
Jeffrey C. Honig <[EMAIL PROTECTED]>
http://www.honig.net/jch
GnuPG ID:14E29E13 

Re: XFree86 goes into stasis when NetMeeting is running

[Earle F. Philhower III]

Howdy...

At 09:25 PM 9/13/2003 -0400, Jeffrey C. Honig <[EMAIL PROTECTED]> wrote:
I've recently switched back to Cygwin/XFree86 from Exceed (ugh) and
rediscovered a problem.
I'm running XFree86 with -fullscreen on my Win2k laptop.  Whenever I
start NetMeeting to join a call, XFree86 will no longer display until I
exit NetMeeting.  If I use Alt-Tab to switch to XFree86, it will not be
restored.  As soon as I exit NetMeeting I am able to switch to XFree86
again.
What gives?
Try adding "-engine 1" to the XWin command line which should use GDI
calls instead of DirectX calls to draw.  NetMeeting probably grabs the
surface and doesn't release it until you quit.
-Earle F. Philhower, III
 [EMAIL PROTECTED]
 cdrlabel - ZipLabel - FlpLabel
 http://www.cdrlabel.com

Re: XFree86-xserv 4.3.0-3 crashing Win2k

[Steinar Bang]

> Steinar Bang <[EMAIL PROTECTED]>:

> Platform: Intel PIII, Win2k professional,
> XFree86-xserv 4.3.0-3

> Now I've crashed Win2k twice in one day, by opening the RMBM on the
> icon in the tool tray, and selecting "Exit".

Make that "thrice".

> The first time it happened I had the root window visible, but the
> second time I did not have the root window visible, and all X
> windows were closed.

This was with the root window invisible and all X windows closed.

Re: XFree86-xserv 4.3.0-3 crashing Win2k

[Steinar Bang]

> Steinar Bang <[EMAIL PROTECTED]>:

> Harold L Hunt II <[EMAIL PROTECTED]>:
>> Steinar,
>> XFree86-xserv-4.3.0-3 is Test95.

>> So, no, your bug is not fixed in Test95.

>> Besides, your bug seems to occur when you simply click on the tray
>> icon, before you even get a menu, correct?

> Nope.  It happens after I've selected "Exit".

Ie. after I've first selected "Exit" in the RMBM on the X icon in the
tooltray, and then clicked on the "Exit" button in the dialog that
opens. 

Re: XFree86-xserv 4.3.0-3 crashing Win2k

[Rodrigo Medina]

 Harold  wrote:
> You guys don't happen to be running on machines with two CPUs or a
> Pentium 4 3.0+ GHz with HyperThreading enabled, do you?

> Harold

I would like to have such machines! I am running window95
with an old Pentium.

$cat /proc/cpuinfo
processor   : 0
vendor id   : GenuineIntel
type: primary processor
cpu family  : 5
model   : 4
model name  : unknown
stepping: 3
brand id: 0
cpu count   : 0
apic id : 0
fpu : yes
flags   : fpu vme de pse tsc msr mce cx8 mmx

Rodrigo

Re: XFree86-xserv 4.3.0-3 crashing Win2k

[Harold L Hunt II]

You guys don't happen to be running on machines with two CPUs or a 
Pentium 4 3.0+ GHz with HyperThreading enabled, do you?

Harold

Rodrigo Medina wrote:

Hi,
I want to report a XWin failure, I think related to the problem
discussed in this thread.
My instalation:
$cat /proc/version
CYGWIN_95-4.0 1.3.22(0.78/3/2) 2003-03-18 09:20
Version of XFree86-xserv : 4.3.0-3

The problem appears only with the -multiwindow option.

$XWin -multiwindow &
[1] 996399
$xterm &
[2] 627351
The xterm functions perfectly well.
Then I close xterm with exit.
$
[2]+  Donexterm
Now I close the X server by clicking Exit in the button on the taskbar.

An alert window of WINDOWS appears telling that XWin has executed an invalid
instruction an that the PC should be rebooted. Details:
XWIN provocó un fallo de pila en el módulo KERNEL32.DLL de 014f:bff725c5.
Registros:
EAX=002a0037 CS=014f EIP=bff725c5 EFLGS=0287
EBX=fe6a9000 SS=0157 ESP=0173e04e EBP=0173e062
ECX=815e28fc DS=0157 ESI=0173e072 FS=0eaf
EDX=815e28fc ES=0157 EDI=815e28fc GS=0df6
Bytes en CS:EIP:
6a ff e8 d0 85 01 00 eb e7 55 8b ec 56 57 53 8b
Volcado de pila:
fe6a9000 815e290c 0173e072 e0b00173 3ec40173 0173e0bc bff7294f 815e28fc
0173e072 012f7a98 01870028 e0df0002 0173 e090 0173 ebd6
In the rxvt window from which XWin was started one gets a message:
$
winMutliWindowWMIOErrorHandler!
[1]+  DoneXWin -multiwindow
$
I have attached the /tmp/XWin.log  file.

If XWin is started and then closed, without running any Xwindow application,
there is no problem. I attach the XWin.log also for this case.
$XWin -multiwindow &
[1] 3623471
$
[1]+  DoneXWin -multiwindow
$
I hope that this information could be useful.
 
Rodrigo Medina

Re: XFree86-xserv 4.3.0-3 crashing Win2k

[Steinar Bang]

> Harold L Hunt II <[EMAIL PROTECTED]>:

> You guys don't happen to be running on machines with two CPUs or a
> Pentium 4 3.0+ GHz with HyperThreading enabled, do you?

Nope.  Single CPU PIII 700MHz, with Windows 2000, 5.00.2195, SP2.

Re: XFree86-xserv 4.3.0-3 crashing Win2k

[Steinar Bang]

> Harold L Hunt II <[EMAIL PROTECTED]>:

> Steinar,
> XFree86-xserv-4.3.0-3 is Test95.

> So, no, your bug is not fixed in Test95.

> Besides, your bug seems to occur when you simply click on the tray
> icon, before you even get a menu, correct?

Nope.  It happens after I've selected "Exit".