Re: fastpath 0 -> xterm?
Tom Roche wrote: Tom Roche Mon, Jun 29, 2009 at 02:29:30PM -0400 Since I'm not seeing this in the FAQ, I wanted to propose the following item: what would be required to go "from zero to xterm"? I.e. from a Cygwin-less windows box (windows >= 2k) to getting a Cygwin/X xterm up on one's screen? Christopher Faylor Mon, 29 Jun 2009 16:45:18 -0400 You do understand what the "F" in FAQ stands for, right? I suspect folks frequently ask, "Just how much pain will this involve?" You may have noted that other projects frequently seek to demonstrate how easy it is to setup and do some simple task. That may well be true but the guideline we use for Cygwin is how often a question comes up on the list. If a question doesn't come on the list or doesn't come up often, that doesn't mean it's not a valid question or wouldn't be a good thing to document somewhere (like perhaps the User's Guide). It just means that it hasn't passed the test to make it into the FAQ. We'd like the FAQ to be targeted so that it's not overwhelming to look through when trying to find a quick answer to a common question. Certainly one could argue that it's already passed that point but if one did make that argument, it would be a reason for trimming the FAQ of things that aren't deemed necessary anymore rather than expanding its charter. ;-) -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 429-6305 - FAX Holliston, MA 01746 -- 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: fastpath 0 -> xterm?
Tom Roche Mon, Jun 29, 2009 at 02:29:30PM -0400 >> Since I'm not seeing this in the FAQ, I wanted to propose the >> following item: what would be required to go "from zero to xterm"? >> I.e. from a Cygwin-less windows box (windows >= 2k) to getting a >> Cygwin/X xterm up on one's screen? Christopher Faylor Mon, 29 Jun 2009 16:45:18 -0400 > You do understand what the "F" in FAQ stands for, right? I suspect folks frequently ask, "Just how much pain will this involve?" You may have noted that other projects frequently seek to demonstrate how easy it is to setup and do some simple task. -- 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/
[1.7] Call for Testing - Accelerated GL (AIGLX) for the Cygwin/X X server
I've made a git repo available on freedesktop.org which contains the work I've been doing to add hardware-accelerated indirect GLX to the Cygwin/X server, which is basically a complete rewrite as the code has rusted severely due to server changes since the last time it was touched. This can be built using the instructions from my previous mail [1], substituting the following git commands to checkout from the cygwin-aiglx branch $ git clone git://anongit.freedesktop.org/~jturney/xserver $ cd xserver $ git checkout -b cygwin-aiglx origin/cygwin-aiglx As this work is based on the server-1.6-branch (with all the cygwin patches applied), in order to build this, you will need the various updated dependencies for that, which have recently been released for Cygwin 1.7 Some mesa demos seem to work for me, I'm really interested in this stage in discovering if it works at all for other people (especially since I probably get to deal with some graphics-card vendor specific issues at some stage). I don't think we're at the stage of trying real applications yet :-) Notes: * At the moment, testing with remote Linux clients is easier (see below), but it seems that mesa's libGL prefers to use client-side swrast and transfer the image to the server using xlib. To force the use of GLX so rendering is indirect (takes place on the server), and thus can be accelerated, set the environment variable LIBGL_ALWAYS_INDIRECT. * For local clients, Cygwin's current libGL is built --with-driver=x11, but the code to use GLX in that driver looks like it's been disabled since 2005, so it *always* uses client-side swrast and transfers the image using xlib, and there is no option to make it use indirect (server-side) rendering. I have a separate patch-set to make it possible to build a Cygwin libGL --with-driver=dri --with-dri-driver=swrast, so that LIBGL_ALWAYS_INDIRECT can be used, as above. As the mesa patch-set is really ugly at the moment, and as a convenience, pointing 1.7's setup.exe at http://www.dronecode.org.uk/cygwin/ should enable you to install an updated libGL1 package built with those patches (the source is also available if you wish to see the gruesome details). There's also an additional mesademos package which contains a large number of GL test programs included with the mesa source which are not normally shipped. * You need to provide the command line option '-wgl' to the X server to turn on the code which uses native Windows OpenGL to implement GLX. If you don't use this option to turn the code on, you will carry on using software rendering. * If you have followed the above instructions successfully, 'glxinfo | grep OpenGL' should return something mentioning your graphics card vendor. If it mentions Mesa, you still have software rendering * As before, only multiwindow/mwextwm modes are supported. Software rendering is always used on screens which do not have 1 native window per X window. There's no way I know of to tell the native OpenGL to transform/clip to the portion of the native window occupied by the X window in the single root native window modes. * Known issues: pixmap drawables don't have the right contents when read by XGetImage. Don't even think of using this on a multi-monitor system :-) * Not working: overlays, pixmap textures, multisample do not work, and those features should not be offered by the server. It looks like it should be possible to implement some of these using various WGL extensions, but I'd like to test the core a bit first... http://www.dronecode.org.uk/glxgears_is_not_a_benchmark_3.png [1] http://cygwin.com/ml/cygwin-xfree/2009-06/msg00076.html -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Proposed patch to system.XWinrc
Jon TURNEY wrote:
jose isaias cabrera wrote:
"Ken Brown" wrote...
What's the reason for launching everything using sh rather than bash?
If I'm reading the bash documentation correctly, it means that
~/.bash_profile won't get executed (though it would get executed if
it were renamed ~/.profile).
I've always wondered the same thing...
Always assuming that /bin/bash exists, or that /bin/sh is bash is
probably bad style for portability across unicies.
However, in this specific case, it's probably ok.
I guess what I should have said is that only the first style point is relevant
here, and is a non-issue if we arrange for the X server to explicitly depend
on bash.
So, attached patch changes X server to start processes using '/bin/bash -l
-c'. setup.hint should also be changed to add bash to the X server's requires:
This will give a 'consistent user experience' in a default install as the
prompt in an xterm will then be the same as in a DOS shell or mintty window :-)
>From 566f2f023e8c30de7629c7b65a28c45bdc012378 Mon Sep 17 00:00:00 2001
From: Jon TURNEY
Date: Tue, 30 Jun 2009 17:42:39 +0100
Subject: [PATCH] Execute commands using a login bash shell
Change executing commands in XWinrc from using '/bin/sh -c' to using '/bin/bash
-l -c'
Tidy up system.Xwinrc, give xterm a scroll bar
(after applying this patch, setup.hint should be changed to add bash to X
server's dependencies)
(orginally from a patch by Ken Brown )
---
hw/xwin/_usr_X11R6_lib_X11_system.XWinrc |7 +--
hw/xwin/winprefs.c |5 +++--
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/hw/xwin/_usr_X11R6_lib_X11_system.XWinrc
b/hw/xwin/_usr_X11R6_lib_X11_system.XWinrc
index 2360bfc..8e74d0c 100644
--- a/hw/xwin/_usr_X11R6_lib_X11_system.XWinrc
+++ b/hw/xwin/_usr_X11R6_lib_X11_system.XWinrc
@@ -18,6 +18,9 @@
# ^^ This command will have any "%display%"
# string replaced with the proper display
# variable (i.e. 127.0.0.1:.0)
+# (This should only rarely be needed as
+# the DISPLAY environment variable is also
+# set correctly)
# or MENU
# or ALWAYSONTOP
# ^^ Sets the window to display above all others
@@ -79,8 +82,8 @@
// Make some menus...
menu apps {
- xterm exec"xterm"
- "Emacs" exec"emacs"
+ xterm exec"xterm -sb"
+ "Emacs" exec"emacs"
notepad execnotepad
xload exec"xload -display %display%" # Comment
}
diff --git a/hw/xwin/winprefs.c b/hw/xwin/winprefs.c
index c5fd7eb..6d7073d 100644
--- a/hw/xwin/winprefs.c
+++ b/hw/xwin/winprefs.c
@@ -371,8 +371,9 @@ HandleCustomWM_COMMAND (unsigned long hwndIn,
/* Disassociate any TTYs */
setsid();
- execl ("/bin/sh",
-"/bin/sh",
+ execl ("/bin/bash",
+"/bin/bash",
+"-l",
"-c",
m->menuItem[j].param,
NULL);
--
1.6.3.2
--
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/
