Re: AW: AW: 'de' keyboard layout issues
On 03/10/2011 12:27, Paul Maier wrote: In Windows, all blind keys followed by a space result in that character. Same in XWin, but with one exception: dead-´ plus space gives ' instead of ´. Please check out my patch for that. [...] for files /usr/share/x11/locale/iso8859-1/Compose and /usr/share/x11/locale/iso8859-15/Compose. This patch makes sense to me, but doesn't seem to go far enough. Since the compose sequences are selected by the locale, this fixes things if LANG=de_DE.iso8859-1 or LANG=de_DE.iso8859-15, but not if LANG=de_DE.UTF-8. I'll try to take another look when I'm back from my holiday :-) Sorry, I lost track of this issue. agreed, my patch is a partial solution. Is there an issue tracker in use, where we can put my patch and the idea behind it? I would suggest you mail a patch to libX11 to the xorg-devel list [1],[2]. agreed. But isn't a partial fix better than no fix? 8-) I can't really evaluate if this change is correct or not, which is why I suggest you take it to the xorg-devel list. For example, after reading [3], I'm wondering if the reason for this behaviour is that typists had the habit of pressing the acute key for an apostrophe. On the one hand, it's been this way for at least 5 years, so people may be used to this behaviour. On the other hand, it's inconsistent with the rule that dead_foo space produces foo, and inconsistent across locales what this sequence produces: jon@byron /jhbuild/checkout/xorg/lib/libX11/nls master $ grep -r ^dead_acute space * el_GR.UTF-8/Compose.pre:dead_acute space: ΄ U0384 en_US.UTF-8/Compose.pre:dead_acute space: ' apostrophe # APOSTROPHE fi_FI.UTF-8/Compose.pre:dead_acute space: ´ # ACUTE ACCENT iso8859-1/Compose.pre:dead_acute space : ' apostrophe iso8859-14/Compose.pre:dead_acute space : ' apostrophe iso8859-15/Compose.pre:dead_acute space : ' apostrophe iso8859-2/Compose.pre:dead_acute space : \264 acute iso8859-3/Compose.pre:dead_acute space : ' apostrophe iso8859-7/Compose.pre:dead_acute space : \264 acute iso8859-9/Compose.pre:dead_acute space : ' apostrophe iso8859-9e/Compose.pre:dead_acute space : ' apostrophe pt_BR.UTF-8/Compose.pre:dead_acute space: ' apostrophe vi_VN.tcvn/Compose.pre:dead_acute space : ' apostrophe vi_VN.viscii/Compose.pre:dead_acute space : ' apostrophe [1] http://lists.x.org/mailman/listinfo/xorg-devel [2] http://www.x.org/wiki/DeveloperStart [3] http://www.cl.cam.ac.uk/~mgk25/ucs/apostrophe.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: AW: AW: possible to run XWin as windows service?
On 28/07/2012 14:08, Paul Maier wrote: The cygwin program run.exe is designed to do just that. It's what I use for this purpose :-) ... thank you for your input. 8-) I was using run.exe too. run.exe used to hide the window and the task bar entry. But since my upgrade from Cygwin 1.7.9 to 1.7.15, run.exe only hides the window but not the task bar entry, when invoked from the Startup menu in some cases. This seems buggy, see my thread: http://cygwin.com/ml/cygwin/2012-07/msg00473.html But I don't have the impression that a developer accepted this as bug. Do you have a suggestion how to avoid this situation? You might try the patched run from [1] and see if that improves matters. -- 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/
AW: AW: possible to run XWin as windows service?
The cygwin program run.exe is designed to do just that. It's what I use for this purpose :-) ... Hi Eliot, thank you for your input. 8-) I was using run.exe too. run.exe used to hide the window and the task bar entry. But since my upgrade from Cygwin 1.7.9 to 1.7.15, run.exe only hides the window but not the task bar entry, when invoked from the Startup menu in some cases. This seems buggy, see my thread: http://cygwin.com/ml/cygwin/2012-07/msg00473.html But I don't have the impression that a developer accepted this as bug. Do you have a suggestion how to avoid this situation? Regards, Paul -- 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: AW: AW: possible to run XWin as windows service?
On 7/28/2012 9:08 AM, Paul Maier wrote: The cygwin program run.exe is designed to do just that. It's what I use for this purpose :-) ... I was using run.exe too. run.exe used to hide the window and the task bar entry. But since my upgrade from Cygwin 1.7.9 to 1.7.15, run.exe only hides the window but not the task bar entry, when invoked from the Startup menu in some cases. This seems buggy, see my thread: http://cygwin.com/ml/cygwin/2012-07/msg00473.html But I don't have the impression that a developer accepted this as bug. Do you have a suggestion how to avoid this situation? I used to have difficulty like that with startxwin, but it does not happen any more for me with xlaunch. It did look like a race condition or something ... Eliot -- 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: AW: AW: AW: AW: AW: Can't paste text or type dead keys when mouse is out of the window
On Sun, Jul 22, 2012 at 02:26:06AM +0200, Paul Maier wrote: The problem here is, when running vi in an xterm and the mouse slowly (unnoticed) moves over the scrollbar or out of the xterm, and you want to jump to mark a, you need to enter `a, that is in keystrokes I'll experiment to see if I can reproduce this effect with my environment. thanks for the detailed explanation. Hi Thomas, yes, I'm talking about dead keys = compose sequences. Was it possible to you to reproduce it in your environment? Typing dead key ` apostrophe then press letter a while the mouse pointer is over the scrollbar area of an xterm? yes - I can reproduce it. Actually once I was made aware of the issue, I could see in my mind where the problem might lie. But I just verified it since you reminded me (on one of my Linux machines). My idea about the problem is that since xterm has setup translations (which capture the input) on more than one widget (without appearing to address this special case), that it might be that there's a better point in the widget to attach the translations to. This was discussed a little late in the #277 cycle to want to hold that up, so I had in mind to spend some time investigating a solution for it during #278. Hi Thomas, I would like to report, that above problem still exists. I tested against xterm-281. yes (I spent some time investigating this, but did not yet find a solution) -- Thomas E. Dickey dic...@invisible-island.net http://invisible-island.net ftp://invisible-island.net signature.asc Description: Digital signature
AW: AW: 'de' keyboard layout issues
In Windows, all blind keys followed by a space result in that character. Same in XWin, but with one exception: dead-´ plus space gives ' instead of ´. Please check out my patch for that. [...] for files /usr/share/x11/locale/iso8859-1/Compose and /usr/share/x11/locale/iso8859-15/Compose. This patch makes sense to me, but doesn't seem to go far enough. Since the compose sequences are selected by the locale, this fixes things if LANG=de_DE.iso8859-1 or LANG=de_DE.iso8859-15, but not if LANG=de_DE.UTF-8. I'll try to take another look when I'm back from my holiday :-) Hi Jon, agreed. But isn't a partial fix better than no fix? 8-) Regards, Paul Compose.patch Description: Binary data -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
AW: AW: AW: AW: AW: Can't paste text or type dead keys when mouse is out of the window
The problem here is, when running vi in an xterm and the mouse slowly (unnoticed) moves over the scrollbar or out of the xterm, and you want to jump to mark a, you need to enter `a, that is in keystrokes I'll experiment to see if I can reproduce this effect with my environment. thanks for the detailed explanation. Hi Thomas, yes, I'm talking about dead keys = compose sequences. Was it possible to you to reproduce it in your environment? Typing dead key ` apostrophe then press letter a while the mouse pointer is over the scrollbar area of an xterm? yes - I can reproduce it. Actually once I was made aware of the issue, I could see in my mind where the problem might lie. But I just verified it since you reminded me (on one of my Linux machines). My idea about the problem is that since xterm has setup translations (which capture the input) on more than one widget (without appearing to address this special case), that it might be that there's a better point in the widget to attach the translations to. This was discussed a little late in the #277 cycle to want to hold that up, so I had in mind to spend some time investigating a solution for it during #278. Hi Thomas, I would like to report, that above problem still exists. I tested against xterm-281. Regards, Paul -- 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/
AW: AW: QAW: AW: Levovo trackpoint come delayed (reproducable with xev)
2. Download XWin.20120129-git-45e67e363e19a481.exe.bz2. /bin/startxwin -- /bin/XWin.20120129-git-45e67e363e19a481.exe -logverbose 3 -clipboard - emulate3buttons 100 -nounixkill -nowinkill -xkboptions nbsp:level3 - Doesn't start. Error message on the console is: giving up. /bin/startxwin: No such file or directory (errno 2): unable to connect to X server /bin/startxwin: No such process (errno 3): Server error. - No output at all to file /var/log/xwin/XWin.0.log. Possibly you need to 'chmod +x /bin/XWin.20120129-git-45e67e363e19a481.exe' -- Jon TURNEY Volunteer Cygwin/X X Server maintainer Hi Jon, x bit was set: $ls -lg *.exe -r-xr-xr-x+ 1 13762945 02.02.2012 19.38 XWin.20120129-git-45e67e363e19a481.exe What about the other interesting results? Please note, that yesterday I sent 2 mails, the second mail continues paragraph counting from 6 to 9. Regards, Paul -- 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/
AW: AW: AltGr key mostly fires an additional CONTROL key
-Ursprüngliche Nachricht- I've had a go at fixing it. Can you please try the build I've uploaded at [1] and see if it still shows the problem for you? [1] ftp://cygwin.com/pub/cygwinx/XWin.20110803-git-a493c0465e56ce0b.exe.bz2 Hi Jon, works fine for me. I Played around quite a while, but the CONTROL-locking didn't occur any more. Yippie! Hi Jon, regarding XWin.20110803-git-a493c0465e56ce0b.exe.bz2 on my PC fixes AltGr problem: I wanted to ask, if that fix will be available with the next release? Regards, Paul -- 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/
AW: AW: Can't paste text or type blind keys when mouse is out of the window
I assume that you see the same behavior with other X applications, i.e. it's not xterm-specific? No, at least xedit works fine on my PC, with blind keys and with mouse text pasting, no matter if the mouse pointer is really inside or on blue window frame or (for blind keys:) really outside. Actually, maybe this is an xterm problem? It seems to be somehow related to the xterm's --enable-toolbar configuration (which is turned on in the cygwin package). If I rebuild xterm with that disabled, the problem goes away, and I can also reproduce the problem on F15 under twm if I build xterm with --enable-toolbar there (which is not enabled in the distro supplied package) Hi Jon, maybe it's a workaround to include two xterm builds in the cygwin release: one xterm compiled with --enable-toolbar and the other having it disabled. I don't use the toolbar, so I would have the blind keys working fine at zero cost. Paul -- 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: AW: 'de' keyboard layout issues (Re: AW: AW: AltGr key mostly fires an additional CONTROL key)
On 12/08/2011 07:48, Paul Maier wrote: 1. Tilde sign - Tilde sign (~) should be a normal (not a blind) key. In Windows I hit AltGr++ to get ~, in XWin I need to type AltGr++ then space to get a ~. See attachment for the initial XWin xmodmap -pke table. Possible xmodmap correction (works fine): keycode 35 = plus asterisk plus asterisk asciitilde This is a can of worms I don't want to open :-) In case it wasn't clear, the can of worms here is ensuring that XWin selects a keyboard layout which matches the Windows one in all cases. At the moment, in the 'de' layout, the tilde deadkey will add a macron diacritic, e.g. AltGr + + + a = ã. Obviously I meant to write 'tilde diacritic' here :-) I really lack the expertise to determine if this is a bug in xkeyboard-config (if this german keyboard behavior is something no german keyboard user would ever expect or want) The xkb configurations we use come from the xkeyboard-config project, and aren't trying to be identical to Windows, but to conform to the appropriate national standards and user expectations. However, I can see in the case of XWin this is problematic, as it will be confusing to switch between X and normal Windows windows which have different keyboard behavior. I did some research: German computer keyboard layout is defined in DIN 2137-2. And to my surprise I found, that tilde is a dead key there. That means, that the xkeyboard-config project perfectly matches the DIN norm, while Windows (where the key is not dead) does not match it. So I understand, that you may want to stick to the DIN norm. Usability comes before standards compliance :-) A workaround for guys like me, who want the XWin keyboard work the same like Windows, is possible with xmodmap, so yeah ... let's close this point. Doing some more research, I found an upstream bug [1], which seems to make the opposite claim about DIN 2137-2(1998) I also discovered that the nodeadkeys variant of the de layout was at one stage the default used by XWin when a German Windows keyboard layout was reported [2] Maybe the 'correct' solution is possibly to create a 'nodeadtilde' variant of the de layout in xkeyboard-config, and then to arrange for that to be the default used by XWin when Windows reports a German keyboard layout. Perhaps you'd like to try the attached patch to /usr/share/X11/xkb/symbols/de, which adds a nodeadtilde variant, which you can then select with -xkbvariant nodeadtilde. Or perhaps the correct solution is to use one of the existing deadgraveacute or deadacute variants as the XWin default when Windows reports a German keyboard layout? [1] https://bugs.freedesktop.org/show_bug.cgi?id=9752 [2] http://cygwin.com/ml/cygwin-xfree/2003-05/msg00495.html Hi Jon, thanks for your work. I myself have made 2 patches and include them in this mail: - One patch for files /usr/share/x11/locale/iso8859-1/Compose and /usr/share/x11/locale/iso8859-15/Compose. - My patch for the de file: de.patch.patch patches your patch, whereas de.patch is the same thing patching the original de file. Here is the explanation (I'm referring to the original pargraph numbering): 1. Tilde sign - Yes, file de patched with your de.patch and XWin invoked with -xkbvariant nodeadtilde results in a German Windows keyboard (regarding the tilde). I did just a renaming of the Group description there to match the pattern of the other xkbvariants. I'd really appreciate it if you could re-open the upstream bug [1] for the tilde issue, ideally with a suitable patch and referencing this discussion. I'd also suggest you send your other suggested changes to the xkb list [2], as I'm not really qualified to review them. [1] https://bugs.freedesktop.org/show_bug.cgi?id=9752 [2] http://www.freedesktop.org/wiki/Software/XKeyboardConfig/Development 3. Non breaking space (NBSP) on ALT+space - In my patch I provide a xkbvariant windowscompatible, that puts nobreakspace onto Alt+Space, like Windows has it. Furthermore, I added a line to the default German layout. It doesn't change the behaviour of the space key with shift, Alt, AltGr, but (and that's the reason why I've put it there), it makes the space key xmodmap redefinable in regard to the Alt key. Without that patch the key definition has not enough numbers of layers, resulting in that xmodmap discards a change of AltGr layer of space. It looks like the mysterious voodoo to achieve this is adding '-xkboptions nbsp:level3' Perhaps that should be set by XWin by default if that is how Windows behaves for all keyboard layouts (so that we don't get different behavior between XWin windows and other Windows applications) 5. New dead acute issue --- Sorry to say, I found another difference while testing. This is, what the Compose.patch is for. In Windows, all blind keys followed by a space result in that character. Same
AW: 'de' keyboard layout issues (Re: AW: AW: AltGr key mostly fires an additional CONTROL key)
1. Tilde sign - Tilde sign (~) should be a normal (not a blind) key. In Windows I hit AltGr++ to get ~, in XWin I need to type AltGr++ then space to get a ~. See attachment for the initial XWin xmodmap -pke table. Possible xmodmap correction (works fine): keycode 35 = plus asterisk plus asterisk asciitilde This is a can of worms I don't want to open :-) In case it wasn't clear, the can of worms here is ensuring that XWin selects a keyboard layout which matches the Windows one in all cases. At the moment, in the 'de' layout, the tilde deadkey will add a macron diacritic, e.g. AltGr + + + a = ã. Obviously I meant to write 'tilde diacritic' here :-) I really lack the expertise to determine if this is a bug in xkeyboard-config (if this german keyboard behavior is something no german keyboard user would ever expect or want) The xkb configurations we use come from the xkeyboard-config project, and aren't trying to be identical to Windows, but to conform to the appropriate national standards and user expectations. However, I can see in the case of XWin this is problematic, as it will be confusing to switch between X and normal Windows windows which have different keyboard behavior. I did some research: German computer keyboard layout is defined in DIN 2137-2. And to my surprise I found, that tilde is a dead key there. That means, that the xkeyboard-config project perfectly matches the DIN norm, while Windows (where the key is not dead) does not match it. So I understand, that you may want to stick to the DIN norm. Usability comes before standards compliance :-) A workaround for guys like me, who want the XWin keyboard work the same like Windows, is possible with xmodmap, so yeah ... let's close this point. Doing some more research, I found an upstream bug [1], which seems to make the opposite claim about DIN 2137-2(1998) I also discovered that the nodeadkeys variant of the de layout was at one stage the default used by XWin when a German Windows keyboard layout was reported [2] Maybe the 'correct' solution is possibly to create a 'nodeadtilde' variant of the de layout in xkeyboard-config, and then to arrange for that to be the default used by XWin when Windows reports a German keyboard layout. Perhaps you'd like to try the attached patch to /usr/share/X11/xkb/symbols/de, which adds a nodeadtilde variant, which you can then select with -xkbvariant nodeadtilde. Or perhaps the correct solution is to use one of the existing deadgraveacute or deadacute variants as the XWin default when Windows reports a German keyboard layout? [1] https://bugs.freedesktop.org/show_bug.cgi?id=9752 [2] http://cygwin.com/ml/cygwin-xfree/2003-05/msg00495.html Hi Jon, thanks for your work. I myself have made 2 patches and include them in this mail: - One patch for files /usr/share/x11/locale/iso8859-1/Compose and /usr/share/x11/locale/iso8859-15/Compose. - My patch for the de file: de.patch.patch patches your patch, whereas de.patch is the same thing patching the original de file. Here is the explanation (I'm referring to the original pargraph numbering): 1. Tilde sign - Yes, file de patched with your de.patch and XWin invoked with -xkbvariant nodeadtilde results in a German Windows keyboard (regarding the tilde). I did just a renaming of the Group description there to match the pattern of the other xkbvariants. 3. Non breaking space (NBSP) on ALT+space - In my patch I provide a xkbvariant windowscompatible, that puts nobreakspace onto Alt+Space, like Windows has it. Furthermore, I added a line to the default German layout. It doesn't change the behaviour of the space key with shift, Alt, AltGr, but (and that's the reason why I've put it there), it makes the space key xmodmap redefinable in regard to the Alt key. Without that patch the key definition has not enough numbers of layers, resulting in that xmodmap discards a change of AltGr layer of space. 5. New dead acute issue --- Sorry to say, I found another difference while testing. This is, what the Compose.patch is for. In Windows, all blind keys followed by a space result in that character. Same in XWin, but with one exception: dead-´ plus space gives ' instead of ´. Please check out my patch for that. Regards, Paul Compose.patch Description: Binary data de.patch.patch Description: Binary data de.patch Description: Binary data -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: AW: 'de' keyboard layout issues (Re: AW: AW: AltGr key mostly fires an additional CONTROL key)
On 09/08/2011 00:17, Paul Maier wrote:
1. Tilde sign
-
Tilde sign (~) should be a normal (not a blind) key.
In Windows I hit AltGr++ to get ~, in XWin I need to type AltGr++ then
space to
get a ~.
See attachment for the initial XWin xmodmap -pke table.
Possible xmodmap correction (works fine):
keycode 35 = plus asterisk plus asterisk asciitilde
This is a can of worms I don't want to open :-)
In case it wasn't clear, the can of worms here is ensuring that XWin selects a
keyboard layout which matches the Windows one in all cases.
At the moment, in the 'de' layout, the tilde deadkey will add a macron
diacritic, e.g. AltGr + + + a = ã.
Obviously I meant to write 'tilde diacritic' here :-)
I really lack the expertise to determine if this is a bug in xkeyboard-config
(if this german keyboard behavior is something no german keyboard user would
ever expect or want)
The xkb configurations we use come from the xkeyboard-config project, and
aren't trying to be identical to Windows, but to conform to the appropriate
national standards and user expectations.
However, I can see in the case of XWin this is problematic, as it will be
confusing to switch between X and normal Windows windows which have different
keyboard behavior.
I did some research: German computer keyboard layout is defined in DIN 2137-2.
And to my surprise I found, that tilde is a dead key there.
That means, that the xkeyboard-config project perfectly matches the DIN norm,
while Windows (where the key is not dead) does not match it.
So I understand, that you may want to stick to the DIN norm.
Usability comes before standards compliance :-)
A workaround for guys like me, who want the XWin keyboard work the same like
Windows,
is possible with xmodmap, so yeah ... let's close this point.
Doing some more research, I found an upstream bug [1], which seems to make the
opposite claim about DIN 2137-2(1998)
I also discovered that the nodeadkeys variant of the de layout was at one
stage the default used by XWin when a German Windows keyboard layout was
reported [2]
Maybe the 'correct' solution is possibly to create a 'nodeadtilde' variant of
the de layout in xkeyboard-config, and then to arrange for that to be the
default used by XWin when Windows reports a German keyboard layout.
Perhaps you'd like to try the attached patch to /usr/share/X11/xkb/symbols/de,
which adds a nodeadtilde variant, which you can then select with -xkbvariant
nodeadtilde.
Or perhaps the correct solution is to use one of the existing deadgraveacute
or deadacute variants as the XWin default when Windows reports a German
keyboard layout?
[1] https://bugs.freedesktop.org/show_bug.cgi?id=9752
[2] http://cygwin.com/ml/cygwin-xfree/2003-05/msg00495.html
--- de.old 2011-08-09 20:17:57.40625 +0100
+++ de 2011-08-09 20:26:52.15625 +0100
@@ -96,6 +96,17 @@
};
partial alphanumeric_keys
+xkb_symbols nodeadtilde {
+// modify the basic German layout to not have the tilde dead key
+
+include de(basic)
+
+name[Group1]=German (nodeadtilde);
+
+key AD12 { [ plus, asterisk, asciitilde, macron ] };
+};
+
+partial alphanumeric_keys
xkb_symbols ro {
// add romanian-specific letters to the basic German layout.
// Romanian symbols are accessible with combination of AltGr and
--
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/
'de' keyboard layout issues (Re: AW: AW: AltGr key mostly fires an additional CONTROL key)
On 04/08/2011 03:21, Paul Maier wrote: Thanks for the logs, that was very useful. I still can't reproduce this (although holding AltGr down to make it autorepeat seems the best way to try to do that). It is a timing issue with the keypress/release messages so it might be sensitive to CPU speed, or perhaps you have some software installed which looks at keypress/release messages and changes the timing? I've had a go at fixing it. Can you please try the build I've uploaded at [1] and see if it still shows the problem for you? [1] ftp://cygwin.com/pub/cygwinx/XWin.20110803-git-a493c0465e56ce0b.exe.bz2 Hi Jon, works fine for me. I Played around quite a while, but the CONTROL-locking didn't occur any more. Yippie! Is it ok, if I leave the hotfix file permanently in on my PC (I mean, did you base it on a recent XWin released version with just my bug fix in - or is there other experimental stuff inside?), then I'll use it automatically during work and I can let you know in case of problems. That particular build is 1.10.3-1 plus the patch for your issue. I wouldn't have started a thread with the following, but since we have already started looking at this keyboard, maybe you are interested in some of these: A new thread would have been fine :-) I am assuming you are using the 'de' keyboard layout: [ 29391,484] (--) Windows keyboard layout: 0407 (0407) Deutsch, type 4 [ 29391,484] (--) Found matching XKB configuration German (Germany) [ 29391,484] (--) Model = pc105 Layout = de Variant = none Options = none [ 29391,484] Rules = base Model = pc105 Layout = de Variant = none Options = none Tilde sign (~) should be a normal (not a blind) key. In Windows I hit AltGr++ to get ~, in XWin I need to type AltGr++ then space to get a ~. See attachment for the initial XWin xmodmap -pke table. Possible xmodmap correction (works fine): keycode 35 = plus asterisk plus asterisk asciitilde This is a can of worms I don't want to open :-) At the moment, in the 'de' layout, the tilde deadkey will add a macron diacritic, e.g. AltGr + + + a = ã. I really lack the expertise to determine if this is a bug in xkeyboard-config (if this german keyboard behavior is something no german keyboard user would ever expect or want) The xkb configurations we use come from the xkeyboard-config project, and aren't trying to be identical to Windows, but to conform to the appropriate national standards and user expectations. However, I can see in the case of XWin this is problematic, as it will be confusing to switch between X and normal Windows windows which have different keyboard behavior. As a workaround, you might find specifying -xkbvariant nodeadkeys, deadgraveacute or deadacute helpful. Euro Currency sign doesn't work. I know - it's not a latin1 character, but together with CP1252 this xmodmap correction works like Windows: keycode 26 = e E e E 0x0080 I guess this is another symptom of Xlib not understanding the de_DE.CP1252 locale. This works fine in the de_DE.UTF-8 locale. I suppose I could patch Xlib to fix this, but I'd rather encourage people to use UTF-8 locales. ALT+Space produces a NBSP character (HEX A0) in Windows, but not in XWin. xmodmap correction is unfortunately not possible, because the xmodmap setting on ISO_Level3_Shift+Space is just thrown away: Something like keycode 65 = space NoSymbol space NoSymbol nobreakspace or keycode 65 = space space space space nobreakspace doesn't work: it's discarded and the setting is not shown on a xmodmap -pke. So I put nobreakspace to the fifth place of another key - there it works. That would be good if key 65 (space key) would accept above xmodmap setting or have it initially. Reading [1], this looks like an (undocumented) Windows-ism http://en.wikipedia.org/wiki/Non-breaking_space#Keyboard_entry_methods Number block is not working. See attachment for the initial XWin xmodmap -pke table (all these KP_* settings look good at the first sight, but the keys don't produce numbers). Possible xmodmap correction (works fine): keycode 63 = asterisk asterisk keycode 79 = 7 7 keycode 80 = 8 8 keycode 81 = 9 9 keycode 82 = minus minus keycode 83 = 4 4 keycode 84 = 5 5 keycode 85 = 6 6 keycode 86 = plus plus keycode 87 = 1 1 keycode 88 = 2 2 keycode 89 = 3 3 keycode 90 = 0 0 keycode 91 = period period keycode 108 = Return Return keycode 112 = slash slash I can't reproduce this problem. I wonder if this is a problem with handling numpad overlaid onto normal keys on a laptop keypad? Again, -logverbose 3 output together with xev output would be helpful. -- 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:
AW: AW: AltGr key mostly fires an additional CONTROL key
Thanks for the logs, that was very useful. I still can't reproduce this (although holding AltGr down to make it autorepeat seems the best way to try to do that). It is a timing issue with the keypress/release messages so it might be sensitive to CPU speed, or perhaps you have some software installed which looks at keypress/release messages and changes the timing? I've had a go at fixing it. Can you please try the build I've uploaded at [1] and see if it still shows the problem for you? [1] ftp://cygwin.com/pub/cygwinx/XWin.20110803-git-a493c0465e56ce0b.exe.bz2 Hi Jon, works fine for me. I Played around quite a while, but the CONTROL-locking didn't occur any more. Yippie! Is it ok, if I leave the hotfix file permanently in on my PC (I mean, did you base it on a recent XWin released version with just my bug fix in - or is there other experimental stuff inside?), then I'll use it automatically during work and I can let you know in case of problems. I wouldn't have started a thread with the following, but since we have already started looking at this keyboard, maybe you are interested in some of these: Tilde sign (~) should be a normal (not a blind) key. In Windows I hit AltGr++ to get ~, in XWin I need to type AltGr++ then space to get a ~. See attachment for the initial XWin xmodmap -pke table. Possible xmodmap correction (works fine): keycode 35 = plus asterisk plus asterisk asciitilde Euro Currency sign doesn't work. I know - it's not a latin1 character, but together with CP1252 this xmodmap correction works like Windows: keycode 26 = e E e E 0x0080 ALT+Space produces a NBSP character (HEX A0) in Windows, but not in XWin. xmodmap correction is unfortunately not possible, because the xmodmap setting on ISO_Level3_Shift+Space is just thrown away: Something like keycode 65 = space NoSymbol space NoSymbol nobreakspace or keycode 65 = space space space space nobreakspace doesn't work: it's discarded and the setting is not shown on a xmodmap -pke. So I put nobreakspace to the fifth place of another key - there it works. That would be good if key 65 (space key) would accept above xmodmap setting or have it initially. Number block is not working. See attachment for the initial XWin xmodmap -pke table (all these KP_* settings look good at the first sight, but the keys don't produce numbers). Possible xmodmap correction (works fine): keycode 63 = asterisk asterisk keycode 79 = 7 7 keycode 80 = 8 8 keycode 81 = 9 9 keycode 82 = minus minus keycode 83 = 4 4 keycode 84 = 5 5 keycode 85 = 6 6 keycode 86 = plus plus keycode 87 = 1 1 keycode 88 = 2 2 keycode 89 = 3 3 keycode 90 = 0 0 keycode 91 = period period keycode 108 = Return Return keycode 112 = slash slash Regards, Paul keycode 8 = keycode 9 = Escape NoSymbol Escape keycode 10 = 1 exclam 1 exclam onesuperior exclamdown onesuperior keycode 11 = 2 quotedbl 2 quotedbl twosuperior oneeighth twosuperior keycode 12 = 3 section 3 section threesuperior sterling threesuperior keycode 13 = 4 dollar 4 dollar onequarter currency onequarter keycode 14 = 5 percent 5 percent onehalf threeeighths onehalf keycode 15 = 6 ampersand 6 ampersand notsign fiveeighths notsign keycode 16 = 7 slash 7 slash braceleft seveneighths braceleft keycode 17 = 8 parenleft 8 parenleft bracketleft trademark bracketleft keycode 18 = 9 parenright 9 parenright bracketright plusminus bracketright keycode 19 = 0 equal 0 equal braceright degree braceright keycode 20 = ssharp question ssharp question backslash questiondown U1E9E keycode 21 = dead_acute dead_grave dead_acute dead_grave dead_cedilla dead_ogonek dead_cedilla keycode 22 = BackSpace NoSymbol BackSpace keycode 23 = Tab ISO_Left_Tab Tab ISO_Left_Tab keycode 24 = q Q q Q at Greek_OMEGA at keycode 25 = w W w W lstroke Lstroke lstroke keycode 26 = e E e E EuroSign EuroSign EuroSign keycode 27 = r R r R paragraph registered paragraph keycode 28 = t T t T tslash Tslash tslash keycode 29 = z Z z Z leftarrow yen leftarrow keycode 30 = u U u U downarrow uparrow downarrow keycode 31 = i I i I rightarrow idotless rightarrow keycode 32 = o O o O oslash Oslash oslash keycode 33 = p P p P thorn THORN thorn keycode 34 = udiaeresis Udiaeresis udiaeresis Udiaeresis dead_diaeresis dead_abovering dead_diaeresis keycode 35 = plus asterisk plus asterisk dead_tilde dead_macron dead_tilde keycode 36 = Return NoSymbol Return keycode 37 = Control_L NoSymbol Control_L keycode 38 = a A a A ae AE ae keycode 39 = s S s S U017F U1E9E U017F keycode 40 = d D d D eth ETH eth keycode 41 = f F f F dstroke ordfeminine dstroke keycode 42 = g G g G eng ENG eng keycode 43 = h H h H hstroke Hstroke hstroke keycode 44 = j J j J dead_belowdot dead_abovedot dead_belowdot keycode 45 = k K k K kra ampersand kra keycode 46 = l L l L lstroke Lstroke lstroke keycode 47 = odiaeresis Odiaeresis odiaeresis Odiaeresis dead_doubleacute
AW: AW: clipboard integration doesn't work
As a workaround, you could perhaps set your locale to de_DE.ISO8859-1 (which is a subset of CP1252), if you actually need to work with CP1252 encoded data, Hi Jon, that WORKS!! 8-))) Thanks for the help. It's fine for me now. Paul -- 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/
AW: AW: 1.9.2.0: Xwin SIGSEGV when font server should be queried
I managed to work around it. In the startup of XWin I start a few windows. In one of them I add the font server after a bit of sleep to settle down XWin. Now the XWin does not SIGSEGV any more why so ever. Here are the scripts I use to start up my X environment Burkhard Startxwin.bat: @echo off SET DISPLAY=127.0.0.1:0.0 REM REM The path in the CYGWIN_ROOT environment variable assignment assume REM that Cygwin is installed in a directory called 'cygwin' in the root REM directory of the current drive. You will only need to modify REM CYGWIN_ROOT if you have installed Cygwin in another directory. For REM example, if you installed Cygwin in \foo\bar\baz\cygwin, you will need REM to change \cygwin to \foo\bar\baz\cygwin. REM REM This batch file will almost always be run from the same drive (and REM directory) as the drive that contains Cygwin/X, therefore you will REM not need to add a drive letter to CYGWIN_ROOT. For example, you do REM not need to change \cygwin to c:\cygwin if you are running this REM batch file from the C drive. REM SET CYGWIN_ROOT=\cygwin SET RUN=%CYGWIN_ROOT%\bin\run -p /usr/bin SET PATH=.;%CYGWIN_ROOT%\bin;%PATH% SET XAPPLRESDIR= SET XCMSDB= SET XKEYSYMDB= SET XNLSPATH= REM Shared Memory support SET CYGWIN=server REM REM Cleanup after last run. REM if not exist %CYGWIN_ROOT%\tmp\.X11-unix\X0 goto CLEANUP-FINISH attrib -s %CYGWIN_ROOT%\tmp\.X11-unix\X0 del %CYGWIN_ROOT%\tmp\.X11-unix\X0 :CLEANUP-FINISH if exist %CYGWIN_ROOT%\tmp\.X11-unix rmdir %CYGWIN_ROOT%\tmp\.X11-unix REM REM The error Fatal server error: could not open default font 'fixed' is REM caused by using a DOS mode mount for the mount that the Cygwin/X REM fonts are accessed through. See the Cygwin/X FAQ for more REM information: REM http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-error-font-eof REM if %OS% == Windows_NT goto OS_NT REM Windows 95/98/Me echo startxwin.bat - Starting on Windows 95/98/Me goto STARTUP :OS_NT REM Windows NT/2000/XP/2003 echo startxwin.bat - Starting on Windows NT/2000/XP/2003 :STARTUP REM Description of XWin-specific options is in XWin(1) manpage. REM REM Startup the programs REM REM Startup the X Server with the integrated Windows-based window manager. REM WARNING: Do not use 'xwinclip' in conjunction with the ``-clipboard'' REM command-line parameter for XWin. Doing so would start two clipboard REM managers, which is never supposed to happen. %RUN% XWin -multiwindow -clipboard -silent-dup-error -xkbvariant nodeadkeys -logverbose 3 REM add my favorites %RUN% bash ~/.startxwinrc ~/startxwinrc: sleep 3 xrdb -all -load ~/.Xdefaults 2/tmp/startxwin.log # add WEE's favorites ssh -Y as1 aixterm -fullcursor -geometry 81x30-125+93 -T \ROUTERS-LOG\ -fn 6x10 -e /usr/local/bin/max.pl ssh -Y as1 aixterm -ls -fullcursor -geometry 81x25+711+1 -bg magenta -fg snow -T \Mail-LOG\ -fn 6x10 -e ~/bin/maillog.sh ssh -Y as1 ~/bin/termtk.pl #now add font server ; terminal closes upon script end ssh -Y as1 aixterm -ls -fullcursor -geometry 81x25+37+208 -e ~/.xsetwee ssh -Y as1 aixterm -ls -fullcursor -geometry 81x25+37+208 ssh -Y as1 aixterm -ls -fullcursor -geometry 81x25+88+217 .xsetwee: echo Sleeping 10 seconds sleep 10 xset fp+ tcp/mystique:7100 xset q echo Sleeping 10 seconds until close sleep 10 exit _ Geschaeftsfuehrer/Managing Directors: Christoph Hahn-Woernle, Frank Apel HRB 17335, Amtsgericht Stuttgart (Commercial Register District Court Stuttgart) St.-Nr. 99064/06051, USt-IdNr./VAT Reg.No.: DE 203036780 -- 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/
AW: AW: 1.9.2.0: Xwin SIGSEGV when font server should be queried
Rejoiced too early. When I start an application that uses a font that is not on the font server XWin crashes again with the same stack trace I already sent you. Burkhard _ Geschaeftsfuehrer/Managing Directors: Christoph Hahn-Woernle, Frank Apel HRB 17335, Amtsgericht Stuttgart (Commercial Register District Court Stuttgart) St.-Nr. 99064/06051, USt-IdNr./VAT Reg.No.: DE 203036780 -- 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: AW: AW: AW: AW: AW: Getting multiple lines Xlib: unexpected async reply (sequence 0xAdress)! when runnning startx
On Thu, 19 May 2005, Vincenzo Daniele wrote: Ok. Sorry for this misunderstanding. $ XWin :0 starts fine sleep 5s is sleeping 5 secs $ DISPLAY=:0.0 twm winProcEstablishConnection - Hello winProcEstablishConnection - Clipboard is not enabled, returning. Xlib: unexpected async reply (sequence 0x73)! Hm. That's very strange. So the error is already present in this simple setting. It would be great if you could check what happens with remote usage with other hosts where the problem does not occur (eg other unices) win-host$ XWin -ac :0 unix-host$ DISPLAY=win-host:0.0 twm You could also try Xming which uses a different network layer http://freedesktop.org/wiki/Xming $ /cygdrive/c/Program Files/Xming/Xming :0 $ DISPLAY=localhost:0.0 twm (please notice it's localhost:0.0 instead of :0.0 because Xming does not support unix sockets) bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: AW: AW: AW: AW:
Antwort: Antwort: Antwort: Antwort: It's German for Reply, and the German shorthand for RE: On Thu, 19 May 2005 10:00:26 -0400, Andrew Schulman wrote: What the hell is that?
Re: AW: AW:
What the hell is that? Antwort: Antwort: Antwort: Antwort: It's German for Reply, and the German shorthand for RE: Thank you. This has been bothering me for ages! Of course it's still annoying, but at least now I know what it means!
AW: AW: cygwin.rules - Enabling shared libXt finally?
No, there is no functional changes. I only want to make sure, that no c function in Intrinsic.c can use the symbol _y (in c 'y'), so this patch renames it to __$XtInherit, which isn't usable for c functions. BTW: I was very in rush while doing the last patch, which may fails to be applied. The symbol which has to be patched is _y and not _$$y like done in the previous patch. I've added an updated patch. Ralf --- Initialize-old.c 2003-10-21 20:21:18.0 +0200 +++ Initialize.c 2003-10-21 20:23:25.0 +0200 @@ -236,8 +236,8 @@ asm (.data\n\ .globl __XtInherit\n\ - __XtInherit: jmp *_y \n\ - _y: .long ___XtInherit \n\ + __XtInherit: jmp *__$XtInherit \n\ + __$XtInherit: .long ___XtInherit \n\ .text \n); #define _XtInherit __XtInherit Ralf Errm, this isn't going to change the public interface is it? That is, if Harold releases another libXt with this change, would that break the recently re-compiled and released lesstif, etc etc? -- Chuck Ralf Habacker wrote: Not sure I understand. What should be changed in the current version of the Xt code? only note 1, chaning the label. The second note is only for completeness. Attached are my curent xc/lib/Xt/[Initialize.c|IntrinsicP.h] files. Please send a diff against these if anything should be changed. Note that these are intentionally from the 4.3 branch. --- Initialize-old.c 2003-10-21 20:21:18.0 +0200 +++ Initialize.c 2003-10-21 20:23:25.0 +0200 @@ -236,8 +236,8 @@ asm (.data\n\ .globl __XtInherit\n\ - __XtInherit: jmp *_$$y \n\ - _$$y: .long ___XtInherit \n\ + __XtInherit: jmp *__$XtInherit \n\ + __$XtInherit: .long ___XtInherit \n\ .text \n); #define _XtInherit __XtInherit
AW: AW: Enabling SHM support in default build of XWin.exe
Hi Charles, ... if linked to the static ipc-library. Using the cygipc dll results in an additional runtime dependency, which will produce windows runtime linking errors if the cygipc package isn't installed, which will produce more support noise dealing with this issue. Using the static library avoids this problem. I think that you *should* use the DLL. And add cygipc to the setup.hint requires: of XFree86. Not because I think that everyone should or will 'turn on' the daemon, but because: you can't use libtool to make a DLL that has static dependencies (without heroic effort). Now, I know that XFree86 does not use libtool, but maybe I want to build gtk or something that (a) does, and (b) links to XFree86 libs. Since, in this scenario, the XFree86 libs will have a link time dependency on libcygipc.a -- I won't be able to build a DLL version of gtk (without heroic effort). What's the support issue you're worried about, Ralf? One more requires: library? When Harold is busy spinning out expat, fontconfig, and freetype -- what's one more? I forgot that the standard cygwin libtool has this limitation (I`m living on the kde [=older libtool release] side of libtool which uses a pass_all lib filter and you're right that it is easier to maintain one package (cygipc) as to recompile every package which is linked to the static cygipc lib on every new cygipc release. Thanks for pointing this out. ;-) Ralf
