Re: segfault Xserver...current version (1.10, not 1.8)

2011-08-16 Thread Jon TURNEY

On 16/08/2011 08:16, Linda Walsh wrote:

Christopher Faylor wrote:

On Tue, Aug 09, 2011 at 05:55:31PM -0700, Linda Walsh wrote:

Jon TURNEY wrote:


Following the instructions at [2] to obtain an Xserver backtrace would
also be of great help.

[2] http://x.cygwin.com/devel/backtrace.html


Reading symbols from /usr/bin/Xwin...(no debugging symbols found)...done.


From the above web page:

To generate a useful backtrace, you will need an X server built with
debugging symbols. X server snapshots are built with debugging symbols
for this reason. Download the latest X Server snapshot from
ftp://cygwin.com/pub/cygwinx, uncompress it using bunzip2, and move it
to /usr/bin/XWin.exe


Well, I DID follow the instructions provided by Johnmaybe that page
should point to binaries that have symbols?


WFM

(Although it seems that the execute bit is removed by the time we download the 
file, so I need to amend the instructions in that regard)


Perhaps you can generate a similar transcript?


$ file /usr/bin/XWin.exe
/usr/bin/XWin.exe: PE32 executable (GUI) Intel 80386 (stripped to external 
PDB), for MS Windows

$ wget ftp://cygwin.com/pub/cygwinx/XWin.20110803-git-a493c0465e56ce0b.exe.bz2
--2011-08-16 13:19:25--  
ftp://cygwin.com/pub/cygwinx/XWin.20110803-git-a493c0465e56ce0b.exe.bz2
   = `XWin.20110803-git-a493c0465e56ce0b.exe.bz2'
Resolving cygwin.com (cygwin.com)... 209.132.180.131
Connecting to cygwin.com (cygwin.com)|209.132.180.131|:21... connected.
Logging in as anonymous ... Logged in!
== SYST ... done.== PWD ... done.
== TYPE I ... done.  == CWD (1) /pub/cygwinx ... done.
== SIZE XWin.20110803-git-a493c0465e56ce0b.exe.bz2 ... 4123185
== PASV ... done.== RETR XWin.20110803-git-a493c0465e56ce0b.exe.bz2 ... 
done.
Length: 4123185 (3.9M) (unauthoritative)

100%[==]
 4,123,185109K/s   in 41s

2011-08-16 13:20:09 (97.3 KB/s) - `XWin.20110803-git-a493c0465e56ce0b.exe.bz2' 
saved [4123185]


$ bunzip2 XWin.20110803-git-a493c0465e56ce0b.exe.bz2

$ chmod +x XWin.20110803-git-a493c0465e56ce0b.exe

$ mv XWin.20110803-git-a493c0465e56ce0b.exe /usr/bin/XWin.exe

$ file /usr/bin/XWin.exe
/usr/bin/XWin.exe: PE32 executable (GUI) Intel 80386, for MS Windows

$ gdb --args XWin
GNU gdb (GDB) 7.3.50.20110727-cvs (cygwin-special)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as i686-cygwin.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/bin/XWin...done.
(gdb)



--
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: 'de' keyboard layout issues (Re: AW: AW: AltGr key mostly fires an additional CONTROL key)

2011-08-16 Thread Jon TURNEY

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 

considering modifier keys after gaining focus

2011-08-16 Thread Oliver Schmidt

Hi,

I had the problem, that the state of the modifier keys was lost when a 
window is created (or raised).


Example: in window A Ctrl + some key opens a window B, then in window B 
Ctrl + some other key triggers the next action. However after the 
opening of window B the Ctrl key has to be released and pressed again. 
If the user keeps the Ctrl key holding when the window B is opened, the 
next key press X will be interpreted as X and not as Ctrl+X.


I send a patch to fix this problem with this email: I just extended the 
function winRestoreModeKeyStates in winkeybd.c to consider not only the 
mode switch key but also the modifiers Ctrl, Shift, Alt/AltGr by using 
the Windows function GetAsyncKeyState.


This patch works fine for me.

However one problem is unsolved: if the key combination for opening 
window B (in the above example) is an AltGr key combination, the 
GetAsyncKeyState will also report, that the Ctrl key is pressed, which 
is not true, since this is the well known Windows fake Ctrl_L :-(


Any suggestions how to solve this?

Best regards,
Oliver
diff --git a/cygwin/hw/xwin/winkeybd.c b/cygwin/hw/xwin/winkeybd.c
index 9e5a9b0..e807fc5 100644
--- a/cygwin/hw/xwin/winkeybd.c
+++ b/cygwin/hw/xwin/winkeybd.c
@@ -255,6 +255,7 @@ void
 winRestoreModeKeyStates (void)
 {
   DWORDdwKeyState;
+  BOOL modifierPressed;
   BOOL processEvents = TRUE;
   unsigned short   internalKeyStates;
 
@@ -282,6 +283,34 @@ winRestoreModeKeyStates (void)
* have a logical XOR operator, so we use a macro instead.
*/
 
+  modifierPressed = (GetAsyncKeyState (VK_CONTROL)  0);
+  if (WIN_XOR (internalKeyStates  ControlMask, modifierPressed))
+{
+  if (modifierPressed) winSendKeyEvent (KEY_LCtrl, TRUE);
+  else winSendKeyEvent (KEY_LCtrl, FALSE);
+}
+
+  modifierPressed = (GetAsyncKeyState (VK_SHIFT)  0);
+  if (WIN_XOR (internalKeyStates  ShiftMask, modifierPressed))
+{
+  if (modifierPressed) winSendKeyEvent (KEY_ShiftL, TRUE);
+  else winSendKeyEvent (KEY_ShiftL, FALSE);
+}
+
+  modifierPressed = (GetAsyncKeyState (VK_LMENU)  0);
+  if (WIN_XOR (internalKeyStates  Mod1Mask, modifierPressed))
+{
+  if (modifierPressed) winSendKeyEvent (KEY_Alt, TRUE);
+  else winSendKeyEvent (KEY_Alt, FALSE);
+}
+
+  modifierPressed = (GetAsyncKeyState (VK_RMENU)  0);
+  if (WIN_XOR (internalKeyStates  Mod5Mask, modifierPressed))
+{
+  if (modifierPressed) winSendKeyEvent (KEY_AltLang, TRUE);
+  else winSendKeyEvent (KEY_AltLang, FALSE);
+}
+
   /* Has the key state changed? */
   dwKeyState = GetKeyState (VK_NUMLOCK)  0x0001;
   if (WIN_XOR (internalKeyStates  NumLockMask, dwKeyState))

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

email to list keeps bouncing

2011-08-16 Thread McBroom, Robert C
My emails to the list keep bouncing from the spam checker.  I have everything 
in plain text.  Anyone have any advice on getting through?


  
Robert C. McBroom
US Department of Energy
Safety  Health Team 
Safety and Health Division, SE-33
200 Administration Rd.
PO Box 2001
Oak Ridge, TN 37831-8732



--
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: Computer upgrade breaks CYGWIN X

2011-08-16 Thread McBroom, Robert C


-Original Message-

On 8/12/2011 9:44 AM, McBroom, Robert C wrote:

snip

 rm3@mcbroomrc2 ~
 $   1 [main] emacs-X11 5540 C:\cygwin\bin\emacs-X11.exe: *** fatal error 
 - unable to remap 
 \\?\C:\cygwin\lib\gtk-2.0\2.10.0\loaders\cygpixbufloader-xpm.dll to same 
 address as parent: 0x37 != 0x3F
 Stack trace:

You might try rebaseall for this.  Read the readme first though so you
know how to run it.

-- 
Larry

-OP Message-

None of my searches show a faq or readme for rebaseall.  I tried the latest 
sequence that has shown up in mail postings

dash -c rebaseall -b 0x77

in a command window, but the failures in CYGWIN still occur.  The command 
seemed to execute.  Processexplorer doesn't show any CYGWIN processes running 
to create a conflict.  There is nothing from man.  Not sure what the 
appropriate memory address would be for WIN 7 32 with 4G as truncated by 32 bit 
addressing.

Robert McBroom
_


--
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: email to list keeps bouncing

2011-08-16 Thread Christopher Faylor
On Tue, Aug 16, 2011 at 05:53:07PM +, McBroom, Robert C wrote:
My emails to the list keep bouncing from the spam checker.  I have everything 
in plain text.  Anyone have any advice on getting through?

1) Don't send list problems here.

2) Read the bounce message.  You were including raw email in the body of
your message.

--
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: Computer upgrade breaks CYGWIN X

2011-08-16 Thread Larry Hall (Cygwin-X)

On 8/16/2011 1:57 PM, McBroom, Robert C wrote:

lhall wrote:

On 8/12/2011 9:44 AM, McBroom, Robert C wrote:

snip


rm3@mcbroomrc2 ~
$   1 [main] emacs-X11 5540 C:\cygwin\bin\emacs-X11.exe: *** fatal error - 
unable to remap 
\\?\C:\cygwin\lib\gtk-2.0\2.10.0\loaders\cygpixbufloader-xpm.dll to same 
address as parent: 0x37 != 0x3F
Stack trace:


You might try rebaseall for this.  Read the readme first though so you
know how to run it.


None of my searches show a faq or readme for rebaseall.


$ ls /usr/share/doc/Cygwin/rebase-3.0.1.README
/usr/share/doc/Cygwin/rebase-3.0.1.README

There it is! ;-)

--
Larry

_

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/