[ANNOUNCEMENT] Updated: GNOME 2.30.2 platform
The GNOME platform libraries have been updated to the latest 2.30.2 stable release. This is the last scheduled release for GNOME 2.x. GNOME 3.0 debuts this fall with a number of changes to the library stack; further details of that transition will be announced at a later time. -- CYGWIN-XFREE-ANNOUNCE UNSUBSCRIBE INFO == If you want to unsubscribe from the cygwin-xfree-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-xfree-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: XTerm scrollbar issue
On Wed, 30 Jun 2010, Thomas Dickey wrote: On Wed, 30 Jun 2010, webmaster wrote: All releases of xterm newer that 229 (i.e. since June '08) have a broken scrollbar. It never bothered me enough to post a message, but I've been setting up some new systems and have found it annoying to dig up xterm-229 and manually install it. These images show what the scrollbar used to look like (and what it still looks like in all recent Linux distributions, even with latest xterm builds): Problems like that shown with the scrollbar are usually a compile-time mismatch on floating-point. There's a configure option for xterm to address this (--enable-narrowproto or --disable-narrowproto), since the mismatch is not detectable via automatic checks. The issue is documented in xterm's INSTALL file. Packagers have to essentially ensure that the prototype for XawScrollbarSetThumb is compiled properly. For instance, the package for xterm in Debian uses --enable-narrowproto That turns on a #define for NARROWPROTO which may be missing (or not not coordinated with Xfuncproto.h, which in turn sets #defines used in Xaw, to choose between a "float" and a "double" for the type of one of its parameters). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Slow response to keypresses in xorg-server-1.8.0-1
On 7/1/2010 4:49 PM, Leigh Orf wrote: Hi, just joined the list. I updated to the latest cygwin today and was having the same problem with X just freezing up in the background. Your fix did the trick. I am profoundly grateful, it was making me batty. Since I've never overwritten an installed binary with cygwin before, wondering whether I will run into any problems later when I need to update. I presume the binary from the patched code won't make it to the mirrors for a while? 'setup.exe' will dutifully update it when a new package with an updated version is available. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Slow response to keypresses in xorg-server-1.8.0-1
--- Mer 30/6/10, Jon TURNEY ha scritto: > Anyhow, I've cooked up a small additional change which > should prevent this > blocking behaviour and uploaded a build [2]. It seems to > resolve the problem > in this specific case. Perhaps you could try it out and see > if it helps? > > [1] http://cygwin.com/ml/cygwin-xfree/2010-02/msg00124.html > [2] ftp://cygwin.com/pub/cygwinx/XWin.20100630-git-bc2f74e105146c36.exe.bz2 > > -- > Jon TURNEY > Volunteer Cygwin/X X Server maintainer Jon, the new version has much more responsiveness than 1.8.0-1 the ALT-TAB switch is fluent now. Regards Marco -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Slow response to keypresses in xorg-server-1.8.0-1
Hi, just joined the list. I updated to the latest cygwin today and was having the same problem with X just freezing up in the background. Your fix did the trick. I am profoundly grateful, it was making me batty. Since I've never overwritten an installed binary with cygwin before, wondering whether I will run into any problems later when I need to update. I presume the binary from the patched code won't make it to the mirrors for a while? Thanks, Leigh -- Leigh Orf Associate Professor of Atmospheric Science Room 130G Engineering and Technology Department of Geology and Meteorology Central Michigan University Mount Pleasant, MI 48859 (989)774-1923 Amateur radio callsign: KG4ULP -- 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: fatal error
On 25/06/2010 10:12, Miroslav Iliaš wrote: /var/log/XWin.0.log attached [ 2936.391] (EE) XKB: Could not invoke xkbcomp [ 2936.391] (EE) XKB: Couldn't compile keymap [ 2936.391] XKB: Failed to compile keymap [ 2936.391] Keyboard initialization failed. This could be a missing or incorrect setup of xkeyboard-config. [ 2936.391] Fatal server error: [ 2936.391] Failed to activate core devices. Can you run /usr/bin/xkbcomp from bash? If no, your installation of xkbcomp is broken somehow. Try 'cycheck /usr/bin/xkbcomp'. If yes, you probably have some kind of BLODA [1] problem. [1] http://cygwin.com/faq/faq.using.html#faq.using.bloda -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Using the Canadian Multilingual Standard keyboard with Windows XP
On 03/06/2010 21:17, Young, George wrote: Using Windows XP and cygwin started with the command %RUN% XWin -multiwindow -clipboard -silent-dup-error -xkblayout ca -xkbvariant multix -xkbmodel pc104 If the Windows keyboard is set to US, cygwin works fine. If the Windows keyboard is set to Canadian Multilingual Standard, cygwin doesn't get the RightAlt and RightControl inputs. I couldn't reproduce this. Checking with xev, the right alt and right control keys generate key events when the Windows keyboard layout is Canadian Multilingual Standard, although it seems that right control generates the same X keysym as left control with that layout for some reason. Can you clarify how you are checking for the keypresses? Please attach your /var/log/XWin.0.log as well. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Problem when trying to use -nolock Option
On 01/07/2010 06:53, Mathias Friesenbichler wrote: Hi, Thanks for the reply. But you didn’t get my problem. We are several users running X servers over several computers, but starting the X from the same Installation on the network. I see. You didn't mention this before. I don't think that's a supported way of running cygwin. Things would probably work better if you set the mount table for each computer so it had /tmp mounted on a local disk, rather than having them all share one. So the local Computer doesn’t know anything about the other users and therefore we have written a program that manages this problem for us. This program gives each user a unique display number. The problem now is that if I use the “-nolock” option it does the same as if I don’t use it. It also creates those lockfiles. So what can I do to fix this? The "/tmp/.X11-unix/Xn" files are not lock files. They are unix domain sockets. You could avoid them being created by using '-nolisten unix', which probably avoids this specific problem. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
[PATCH] Update mapping for Canadian keyboard layouts
0x0c0c "Canadian French (legacy)" => layout ca variant fr-legacy
0x1009 "Canadian French" => layout ca variant fr
0x00011009 "Canadian Multilingual Standard" => layout ca variant multix
Signed-off-by: Jon TURNEY
---
hw/xwin/winlayouts.h | 192 ++
1 files changed, 6 insertions(+), 186 deletions(-)
diff --git a/hw/xwin/winlayouts.h b/hw/xwin/winlayouts.h
index d1d21a1..724465f 100644
--- a/hw/xwin/winlayouts.h
+++ b/hw/xwin/winlayouts.h
@@ -55,13 +55,15 @@ WinKBLayoutRec winKBLayouts[] =
{0x10409, -1, "pc105", "dvorak", NULL, NULL, "English (USA, Dvorak)"},
{0x20409, -1, "pc105", "us_intl", NULL, NULL, "English (USA,
International)"},
{ 0x809, -1, "pc105", "gb", NULL, NULL, "English (United Kingdom)"},
+{ 0x1009, -1, "pc105", "ca", "fr", NULL, "French (Canada)"},
+{0x11009, -1, "pc105", "ca", "multix", NULL, "Candian Multilingual
Standard"},
{ 0x1809, -1, "pc105", "ie", NULL, NULL, "Irish"},
{ 0x40a, -1, "pc105", "es", NULL, NULL, "Spanish (Spain, Traditional
Sort)"},
{ 0x80a, -1, "pc105", "latam", NULL, NULL, "Latin American"},
{ 0x40b, -1, "pc105", "fi", NULL, NULL, "Finnish"},
{ 0x40c, -1, "pc105", "fr", NULL, NULL, "French (Standard)"},
{ 0x80c, -1, "pc105", "be", NULL, NULL, "French (Belgian)"},
-{ 0xc0c, -1, "pc105", "ca", "fr", NULL, "French (Canada)"},
+{ 0xc0c, -1, "pc105", "ca", "fr-legacy", NULL, "French (Canada)
(Legacy)"},
{ 0x100c, -1, "pc105", "ch", "fr", NULL, "French (Switzerland)"},
{ 0x40d, -1, "pc105", "il", NULL, NULL, "Hebrew"},
{ 0x40e, -1, "pc105", "hu", NULL, NULL, "Hungarian"},
@@ -85,189 +87,7 @@ WinKBLayoutRec winKBLayouts[] =
{ -1, -1, NULL,NULL, NULL, NULL, NULL}
};
-/* Listing of language codes from MSDN */
/*
-Support ID XKBLanguage
-
- ?0x Language Neutral
- ?0x0400 Process or User Default Language
- ?0x0800 System Default Language
-0x0401 Arabic (Saudi Arabia)
-0x0801 Arabic (Iraq)
-0x0c01 Arabic (Egypt)
-0x1001 Arabic (Libya)
-0x1401 Arabic (Algeria)
-0x1801 Arabic (Morocco)
-0x1c01 Arabic (Tunisia)
-0x2001 Arabic (Oman)
-0x2401 Arabic (Yemen)
-0x2801 Arabic (Syria)
-0x2c01 Arabic (Jordan)
-0x3001 Arabic (Lebanon)
-0x3401 Arabic (Kuwait)
-0x3801 Arabic (U.A.E.)
-0x3c01 Arabic (Bahrain)
-0x4001 Arabic (Qatar)
-Arabic (102) AZERTY
-0x0402 Bulgarian
-0x0403 Catalan
-0x0404 Chinese (Taiwan)
-0x0804 Chinese (PRC)
-0x0c04 Chinese (Hong Kong SAR, PRC)
-0x1004 Chinese (Singapore)
-0x1404 Chinese (Macao SAR) (98/ME,2K/XP)
- X0x0405 cz Czech
- Xcz_qwerty Czech (QWERTY)
-Czech (Programmers)
- X0x0406 dk Danish
- X0x0407 de German (Standard)
- X0x0807 de_CH German (Switzerland)
-0x0c07 German (Austria)
-0x1007 German (Luxembourg)
-0x1407 German (Liechtenstein)
-0x0408 Greek
- X0x0409 us English (United States)
- X0x0809 gb English (United Kingdom)
-0x0c09 English (Australian)
-0x1009 English (Canadian)
-0x1409 English (New Zealand)
- X0x1809 ie English (Ireland)
-0x1c09 English (South Africa)
-0x2009 English (Jamaica)
-0x2409 English (Caribbean)
-0x2809 English (Belize)
-0x2c09 English (Trinidad)
-0x3009 English (Zimbabwe) (98/ME,2K/XP)
-0x3409 English (Philippines) (98/ME,2K/XP)
- X0x040a es Spanish (Spain, Traditional Sort)
-0x080a Spanish (Mexican)
-0x0c0a Spanish (Spain, Modern Sort)
-0x100a Spanish (Guatemala)
-0x140a Spanish (Costa Rica)
-0x180a Spanish (Panama)
-0x1c0a Spanish (Dominican Republic)
-0x200a Spanish (Venezuela)
-0x240a Spanish (Colombia)
-0x280a Spanish (Peru)
-0x2c0a Spanish (Argentin
Re: Keyboard and start options problems
On 13/04/2010 15:30, Denis Beauchemin wrote:
Le 2010-04-13 09:54, Jon TURNEY a écrit :
On 07/04/2010 20:04, Denis Beauchemin wrote:
My French-Canadian keyboard is not recognized:
2010-04-06 14:42:35 (--) winConfigKeyboard - Layout: "1009"
(1009)
2010-04-06 14:42:35 (EE) Keyboardlayout "Canadian French" (1009)
is unknown
2010-04-06 14:42:35 Rules = "base" Model = "pc105" Layout = "us"
Variant = "" Options = ""
I was going to add this to the list of automatically recognized
layouts, but there's something I don't quite understand here. Perhaps
you can help clear up the confusion so I can do that?
According to the list of locale IDs [2], 0x0c0c is "Canadian French"
(for which we already automatically select the XKB layout ca variant
fr) and 0x1009 is "Canadian English".
Assuming that is correct, at the very least, it looks like the middle
line of the log output where we map the locale ID to keyboard layout
name is wrong somehow.
Is it the case that you have multiple keyboard layouts installed?
Is it really the case that 0x1009 should be mapped to ca-fr? Is ca-en
more appropriate, but you happen to want to use ca-fr?
[1] http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-submit-layout
[2] http://msdn.microsoft.com/en-us/library/0h88fahh%28VS.85%29.aspx
Jon,
You are correct in assuming I have both keyboards installed. I usually
use the French-Canadian keyboard in all apps except xterms where I
prefer a US keyboard. So the default behaviour I am seeing is pretty
much the one I would like to use, except that I sometimes want to write
French comments in my scripts and I then need the French-Canadian
keyboard layout in my xterm.
On the Microsoft site
(http://msdn.microsoft.com/fr-fr/goglobal/bb964651%28en-us%29.aspx), the
right keyboard is the Canadian French.
Okay, after looking into this a bit more, it seems I was looking at the wrong
table, for locale identifiers rather than input locale identifiers.
Checking [1], it seems clear that 0x1009 ('Canadian French') should map to
layout ca variant fr and 0x0c0c (which is described as 'Canadian French
(legacy)') to layout ca variant fr-legacy. So I'll update the keyboard layout
mapping table appropriately. I'll also add the 0x11009 ('Canadian Multilingual
Standard') mapped to layout ca variant multix, which has been discussed elsewhere.
[1] http://technet.microsoft.com/en-us/library/cc766503%28WS.10%29.aspx
I tried "setxkbmap ca" to switch to the French-Canada keyboard layout
and it was perfect in the original xterm that starts-up with Cygwin/X.
But all other xterms I launched from this one didn't forward the
keyboard layout correctly and the only key that still worked was the
"é". All characters built using one of the dead-keys just produced the
plain character without any accent.
If I didn't provide all the information you require, don't hesitate to
ask for more.
I couldn't reproduce this, but I'm not sure I'm trying the right thing.
Could you give me a step-by-step guide, including what keyboard layout you
have selected in Windows, and what compose sequences you are trying that don't
work?
--
Jon TURNEY
Volunteer Cygwin/X X Server maintainer
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
