Re: Cannot start xterm
See startxwin(.exe) man page. Run startxwin from a login shell. Paul Ryan Mcdowell (rymcdowe) wrote: Please ignore this email, anti-virus was killing some of the installation scripts :( -Original Message- From: Ryan Mcdowell (rymcdowe) Sent: Thursday, January 07, 2010 4:46 PM To: 'cygwin-xfree@cygwin.com' Subject: RE: Cannot start xterm My hard drive crashed and I reinstalled XP SP3 from scratch. I then installed cygwin 1.7.3 from scratch. My first issue was I could not find startxwin.bat. I know it was supposed to be moved to /bin/startxwin.bat, but its not there. I built my own shortcut to start xwin C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe. That seems to start up the server just fine. However, when I click on Applications-xterm, nothing happens. I started up a normal cygwin window and manually try to start xterm via xterm -display localhost:0. This gives me the following: bash-3.2$ xterm -display localhost:0 Warning: Cannot convert string -adobe-helvetica-boldo8859-* to type FontStruct Warning: Unable to load any usable ISO8859 font Warning: Unable to load any usable ISO8859 font Error: Aborting: no font found bash-3.2$ I then tried to install all the fonts I could find, nothing seemed to fix the issue. I should also point out that I think something else was dorked up in the installation, as the PATH variable failed to include basic things like /bin. I had to manually add them back in my .bashrc (which the Cygwin.bat script fails to read, so I have to manually source it). When I first run Cygwin.bat, here is my environment. I'm thinking maybe some other variable is not set properly which is the root cause of xterm not finding any fonts. bash-3.2$ /bin/printenv HOMEPATH=\Documents and Settings\rymcdowe APPDATA=C:\Documents and Settings\rymcdowe\Application Data TERM=cygwin PROCESSOR_IDENTIFIER=x86 Family 6 Model 14 Stepping 12, GenuineIntel WINDIR=C:\WINDOWS USERDOMAIN=CISCO OS=Windows_NT ALLUSERSPROFILE=C:\Documents and Settings\All Users !::=::\ TEMP=/cygdrive/c/DOCUME~1/rymcdowe/LOCALS~1/Temp DEFLOGDIR=C:\Documents and Settings\All Users\Application Data\McAfee\DesktopProtection COMMONPROGRAMFILES=C:\Program Files\Common Files QTJAVA=C:\Program Files\QuickTime\QTSystem\QTJava.zip USERNAME=rymcdowe PROCESSOR_LEVEL=6 PATH=/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/system32/WindowsPowerShell/v1.0:/cygdrive/c/ProgramFiles/Credant/Shieldv5.4.2/:/cygdrive/c/ProgramFiles/QuickTime/QTSystem/:/cygdrive/c/ProgramFiles/Intel/WiFi/bin/ FP_NO_HOST_CHECK=NO PWD=/usr/bin SYSTEMDRIVE=C: USERPROFILE=C:\Documents and Settings\rymcdowe LOGONSERVER=\\ADC-RTP1-C1-5-W PROCESSOR_ARCHITECTURE=x86 !C:=C:\cygwin\bin SHLVL=1 HOME=/home/rymcdowe USERDNSDOMAIN=CISCO.COM PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.PSC1 HOMEDRIVE=C: PROMPT=$P$G COMSPEC=C:\WINDOWS\system32\cmd.exe TMP=/cygdrive/c/DOCUME~1/rymcdowe/LOCALS~1/Temp SYSTEMROOT=C:\WINDOWS PROCESSOR_REVISION=0e0c CLASSPATH=.;C:\Program Files\QuickTime\QTSystem\QTJava.zip PROGRAMFILES=C:\Program Files NUMBER_OF_PROCESSORS=2 VSEDEFLOGDIR=C:\Documents and Settings\All Users\Application Data\McAfee\DesktopProtection SESSIONNAME=Console COMPUTERNAME=RYMCDOWE-WXP _=/bin/printenv Anybody have any ideas? Ryan McDowell Systems Engineer Cisco Systems, Inc (W) +1 703.484.0040 (M) +1 703.201.5742 PGP Fingerprint: EED9 192F 9F45 FAE4 F6A3 8764 FEE1 299D 1B62 A361 -- 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/ -- 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/
Unrecognisable file format errors running setup.exe
Because I install Cygwin on multiple systems, I initially run setup.exe under wine (fedora 11) to download the files into a Samba-accessible directory (Distribution/Cygwin/ on Cambridge), into which I also place setup.exe. On a Vista system (I haven't tried to reproduce on XP), I then run the Samba-accessible setup.exe image to install from local directory. This worked flawlessly under Cygwin 1.5. For 1.7, I get repeated Cygwin Setup popup windows stating: Can't open file //\\CAMBRIDGE\Distribution\Cygwin/ for reading: Unrecogisable file format (spelling reproduced as displayed). Clicking OK button allows setup to continue. Apart from this, setup.exe appeared to function correctly except for not generating a desktop icon. 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: X server fails to start on Vista
And make sure the icon isn't hidden (I set Vista to always show the X Windows icon). Paul Larry Hall (Cygwin X) wrote: Kim Goldov wrote: I downloaded Cygwin-X per the instructions in http://x.cygwin.com/docs/ug/setup-cygwin-x-installing.html When selecting Cygwin-X - XWin Server in the start menu, X does not start and I get the following /var/log/XWin.0.log ... /usr/bin/XWin -multiwindow -clipboard -silent-dup-error ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1280 h 1024 winInitializeDefaultScreens - Returning _XSERVTransSocketINETCreateListener: ...SocketCreateListener() failed _XSERVTransMakeAllCOTSServerListeners: server already running Fatal server error: Cannot establish any listening sockets - Make sure an X server isn't already running And you're sure there is no X-server running already? Is there an icon for it in the right corner of the task bar? -- 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/
[PATCHES] Re: keypad assignments
To Cygwin maintainers:
Attached are two unidiff files for correcting the problem of translating
numeric keypad navigation keys to editing keypad navigation keys.
Editing keypad navigation is now only forced in the absence of a scancode.
Paul
Paul Loewenstein wrote:
Thomas,
I believe I have fixed the problem. What program do you use for
displaying the keycodes so I can test the fix before sending in the
patch?
Paul
Thomas Wolff wrote:
Hello,
I've managed to re-activate my Cygwin/XFree (there had been this
disabled keyboard problem with a non-cygwin XKEYSYMDB variable
setting since some recent release...).
So I discovered that, assumedly with that recent major revision, a
keyboard handling deficiency has been introduced:
The keys of the right keypad (aka numeric keypad) do no longer emit
the keysyms KP_Home, KP_Up etc as they used to do but just plainly
Home, Up etc which are also the keysyms of the small keypad (aka
editing keypad). This makes them indistinguishable for any
application - even worse, this cannot be fixed by configuration since
they even send the same keycodes!
These are different keys - considering them as aliases is a waste of
physical resources - and they must be distinguishable for an
application.
That means, they must have different keycodes and they should also
have different keysyms by default - that's what the KP_ keysyms are
designed for.
Thanks and kind regards,
Thomas
--
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/
--- ./origsrc/xorg-server-1.5.3/hw/xwin/winkeybd.c 2009-03-28
12:49:22.113013400 -0700
+++ ./src/xorg-server-1.5.3/hw/xwin/winkeybd.c 2009-03-31 21:39:23.908709800
-0700
@@ -78,7 +78,8 @@
{
int iKeyFixup = g_iKeyMap[wParam * WIN_KEYMAP_COLS + 1];
int iKeyFixupEx = g_iKeyMap[wParam * WIN_KEYMAP_COLS + 2];
- int iParamScanCode = LOBYTE (HIWORD (lParam));
+ int iParam = HIWORD (lParam);
+ int iParamScanCode = LOBYTE (iParam);
/* WM_ key messages faked by Vista speech recognition (WSR) don't have a
* scan code.
@@ -89,13 +90,19 @@
*/
if (iParamScanCode = 1)
{
- iParamScanCode = MapVirtualKeyEx(wParam,
- /*MAPVK_VK_TO_VSC*/0,
- GetKeyboardLayout(0));
+ if (VK_PRIOR = wParam wParam = VK_DOWN)
+ /* Trigger special case table to translate to extended
+* keycode, otherwise if num_lock is on, we can get keypad
+* numbers instead of navigation keys. */
+ iParam |= KF_EXTENDED;
+ else
+ iParamScanCode = MapVirtualKeyEx(wParam,
+/*MAPVK_VK_TO_VSC*/0,
+GetKeyboardLayout(0));
}
/* Branch on special extended, special non-extended, or normal key */
- if ((HIWORD (lParam) KF_EXTENDED) iKeyFixupEx)
+ if ((iParam KF_EXTENDED) iKeyFixupEx)
*piScanCode = iKeyFixupEx;
else if (iKeyFixup)
*piScanCode = iKeyFixup;
--- ./origsrc/xorg-server-1.5.3/hw/xwin/winkeybd.h 2009-03-28
12:49:22.113013400 -0700
+++ ./src/xorg-server-1.5.3/hw/xwin/winkeybd.h 2009-03-31 21:41:47.959509800
-0700
@@ -45,10 +45,8 @@
#defineWIN_KEYMAP_COLS 3
-/* ASCII column, rows 33 through 40 are for Speech Recognition with
- * num-lock asserted.
- * Rows 160 through 165 correspond to software-generated codes, which
- * may not be associated with the appropriate scan code/extended bit
+/* Rows 160 through 165 correspond to software-generated codes, which
+ * may not be associated with the appropriate scan code.
*/
const int
g_iKeyMap [] = {
@@ -86,14 +84,14 @@
/* 30 */ 0, 0, 0,
/* 31 */ 0, 0, 0,
/* 32 */ 0, 0, 0,
- /* 33 */ VK_PRIOR, KEY_PgUp, KEY_PgUp,
- /* 34 */ VK_NEXT,KEY_PgDown, KEY_PgDown,
- /* 35 */ VK_END, KEY_End,KEY_End,
- /* 36 */ VK_HOME,KEY_Home, KEY_Home,
- /* 37 */ VK_LEFT,KEY_Left, KEY_Left,
- /* 38 */ VK_UP, KEY_Up, KEY_Up,
- /* 39 */ VK_RIGHT, KEY_Right, KEY_Right,
- /* 40 */ VK_DOWN,KEY_Down, KEY_Down,
+ /* 33 */ VK_PRIOR, 0, KEY_PgUp,
+ /* 34 */ VK_NEXT,0, KEY_PgDown,
+ /* 35 */ VK_END, 0, KEY_End,
+ /* 36 */ VK_HOME,0, KEY_Home,
+ /* 37 */ VK_LEFT,0, KEY_Left,
+ /* 38 */ VK_UP, 0, KEY_Up,
+ /* 39 */ VK_RIGHT, 0, KEY_Right,
+ /* 40 */ VK_DOWN,0, KEY_Down,
/* 41 */ 0, 0
Re: keypad assignments
Thomas, I believe I have fixed the problem. What program do you use for displaying the keycodes so I can test the fix before sending in the patch? Paul Thomas Wolff wrote: Hello, I've managed to re-activate my Cygwin/XFree (there had been this disabled keyboard problem with a non-cygwin XKEYSYMDB variable setting since some recent release...). So I discovered that, assumedly with that recent major revision, a keyboard handling deficiency has been introduced: The keys of the right keypad (aka numeric keypad) do no longer emit the keysyms KP_Home, KP_Up etc as they used to do but just plainly Home, Up etc which are also the keysyms of the small keypad (aka editing keypad). This makes them indistinguishable for any application - even worse, this cannot be fixed by configuration since they even send the same keycodes! These are different keys - considering them as aliases is a waste of physical resources - and they must be distinguishable for an application. That means, they must have different keycodes and they should also have different keysyms by default - that's what the KP_ keysyms are designed for. Thanks and kind regards, Thomas -- 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/ -- 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: keypad assignments
Thomas, That may be my fault in fixing a problem with speech recognition and Cygwin. I'll have a look at that part of the special case table and undo that change if that is responsible. Paul Thomas Wolff wrote: Hello, I've managed to re-activate my Cygwin/XFree (there had been this disabled keyboard problem with a non-cygwin XKEYSYMDB variable setting since some recent release...). So I discovered that, assumedly with that recent major revision, a keyboard handling deficiency has been introduced: The keys of the right keypad (aka numeric keypad) do no longer emit the keysyms KP_Home, KP_Up etc as they used to do but just plainly Home, Up etc which are also the keysyms of the small keypad (aka editing keypad). This makes them indistinguishable for any application - even worse, this cannot be fixed by configuration since they even send the same keycodes! These are different keys - considering them as aliases is a waste of physical resources - and they must be distinguishable for an application. That means, they must have different keycodes and they should also have different keysyms by default - that's what the KP_ keysyms are designed for. Thanks and kind regards, Thomas -- 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/ -- 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: cygwin rxvt problems on Windows 7 64bit
Boba, Have you run rebaseall? I found I needed to run it with double the default offset. Paul BOBA FETT wrote: Hey guys, I just installed Windows 7 64bit beta and am trying to get my cygwin env to run on it. Basically cygwin installed fine and I can start the normal cygwin shell and use it. Problem is, that I cannot launch rxvt from a windows shortcut like I used to with WinXP (32bit though). I set up my shortcut as I used to run it on WinXP. When I click it, rxvt seems to launch, window size looks like the configured one in the shortcut, but the windows closes itself again prolly after a few milliseconds. You can just see the window popping up and then it's gone again. No Errors, nothing. I can launch rxvt though from within the official cygwin shell, typing rxvt there gives me a default rxvt window just fine. Anyone of you guys running rxvt on Windows 7 beta yet? Any help would be greatly appreciated ... thanks boba -- 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/ -- 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: Cygwin-X on Windows 7 Beta Success!
Fredrik, Thanks! I got it working with a reinstall and a rebaseall with double the default offset. GNUemacs does not survive rebaseall. Paul Fredrik Staxeng wrote: Paul Loewenstein paul.loewenst...@gmail.com writes: Fredrik, On 64-bit Windows 7, I cannot get Cygwin/X windows to accept keyboard input. Are you using 32-bit or 64-bit? 64. -- 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: Cygwin-X on Windows 7 Beta Success!
Fredrik, On 64-bit Windows 7, I cannot get Cygwin/X windows to accept keyboard input. Are you using 32-bit or 64-bit? Paul Fredrik Staxeng wrote: I have been running Cygwin with X on Windows 7 Beta for a few weeks. It works. I think it works rather well considering what it does. I had to do the rebase/reinstall libncurses thing, but then most things work with only a few problems. First, the startxwin icon succeeds in bringing up the the X server, but not the xterm. But when I run my start script from a Cygwin command prompt it works. Then, the first xterm appears instantly, but the second one takes a while (half a minute?). This seems very strange to me, so perhaps I am imagining things. Also, sometimes, e.g when running M-x grep in emacs, what look like command prompt windows flashes by quickly. They appear and then disappear. This does not really bother me much, but it kills the show-off potential. The audience would womder about those flashing windows and stop paying attention to the good things. Is there any way I could help with fixing these problems? -- 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: [patch 4/7] Cygwin/X: Invent a scan code if we dont have one
Yaakov,
Attached is the single unidiff file. I hope the path is relative to the
correct directory.
Paul
Yaakov (Cygwin/X) wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Paul Loewenstein wrote:
Sorry, I did the diff backwards. You can tell I don't do this often.
Corrected .diffs attached, so you don't have to use the patch reverse
option.
Could you please provide these as one unidiff (-u) patch?
Yaakov
Cygwin/X
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEAREIAAYFAklz9WgACgkQpiWmPGlmQSOJBgCgz8NGFbDMruR3CH3MA2W6lSbm
BcwAnRvfWFCtymVYROYoZDO6Hbiuio1k
=IV9F
-END PGP SIGNATURE-
--
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/
diff -u /usr/src/xorg-server-1.5.3-4/src/xorg-server-1.5.3/hw/xwin/winkeybd.c
xorg-server-1.5.3-4/src/xorg-server-1.5.3/hw/xwin/winkeybd.c
--- /usr/src/xorg-server-1.5.3-4/src/xorg-server-1.5.3/hw/xwin/winkeybd.c
2009-01-17 13:17:33.0 -0800
+++ xorg-server-1.5.3-4/src/xorg-server-1.5.3/hw/xwin/winkeybd.c
2009-01-19 08:21:55.58460 -0800
@@ -80,6 +80,20 @@
int iKeyFixupEx = g_iKeyMap[wParam * WIN_KEYMAP_COLS + 2];
int iParamScanCode = LOBYTE (HIWORD (lParam));
+/* WM_ key messages faked by Vista speech recognition (WSR) don't have a
+ * scan code.
+ *
+ * Vocola 3 (Rick Mohr's supplement to WSR) uses
+ * System.Windows.Forms.SendKeys.SendWait(), which appears always to give a
+ * scan code of 1
+ */
+ if (iParamScanCode = 1)
+{
+ iParamScanCode = MapVirtualKeyEx(wParam,
+ /*MAPVK_VK_TO_VSC*/0,
+ GetKeyboardLayout(0));
+}
+
/* Branch on special extended, special non-extended, or normal key */
if ((HIWORD (lParam) KF_EXTENDED) iKeyFixupEx)
*piScanCode = iKeyFixupEx;
diff -u /usr/src/xorg-server-1.5.3-4/src/xorg-server-1.5.3/hw/xwin/winkeybd.h
xorg-server-1.5.3-4/src/xorg-server-1.5.3/hw/xwin/winkeybd.h
--- /usr/src/xorg-server-1.5.3-4/src/xorg-server-1.5.3/hw/xwin/winkeybd.h
2007-10-23 14:26:52.0 -0700
+++ xorg-server-1.5.3-4/src/xorg-server-1.5.3/hw/xwin/winkeybd.h
2009-01-17 12:46:15.475681500 -0800
@@ -45,6 +45,11 @@
#defineWIN_KEYMAP_COLS 3
+/* ASCII column, rows 33 through 40 are for Speech Recognition with
+ * num-lock asserted.
+ * Rows 160 through 165 correspond to software-generated codes, which
+ * may not be associated with the appropriate scan code/extended bit
+ */
const int
g_iKeyMap [] = {
/* count Windows VK, ASCII, ASCII when extended VK */
@@ -81,14 +86,14 @@
/* 30 */ 0, 0, 0,
/* 31 */ 0, 0, 0,
/* 32 */ 0, 0, 0,
- /* 33 */ VK_PRIOR, 0, KEY_PgUp,
- /* 34 */ VK_NEXT,0, KEY_PgDown,
- /* 35 */ VK_END, 0, KEY_End,
- /* 36 */ VK_HOME,0, KEY_Home,
- /* 37 */ VK_LEFT,0, KEY_Left,
- /* 38 */ VK_UP, 0, KEY_Up,
- /* 39 */ VK_RIGHT, 0, KEY_Right,
- /* 40 */ VK_DOWN,0, KEY_Down,
+ /* 33 */ VK_PRIOR, KEY_PgUp, KEY_PgUp,
+ /* 34 */ VK_NEXT,KEY_PgDown, KEY_PgDown,
+ /* 35 */ VK_END, KEY_End,KEY_End,
+ /* 36 */ VK_HOME,KEY_Home, KEY_Home,
+ /* 37 */ VK_LEFT,KEY_Left, KEY_Left,
+ /* 38 */ VK_UP, KEY_Up, KEY_Up,
+ /* 39 */ VK_RIGHT, KEY_Right, KEY_Right,
+ /* 40 */ VK_DOWN,KEY_Down, KEY_Down,
/* 41 */ 0, 0, 0,
/* 42 */ 0, 0, 0,
/* 43 */ 0, 0, 0,
@@ -208,12 +213,12 @@
/* 157 */0, 0, 0,
/* 158 */0, 0, 0,
/* 159 */0, 0, 0,
- /* 160 */0, 0, 0,
- /* 161 */0, 0, 0,
- /* 162 */0, 0, 0,
- /* 163 */0, 0, 0,
- /* 164 */0, 0, 0,
- /* 165 */0, 0, 0,
+ /* 160 */VK_LSHIFT, KEY_ShiftL, KEY_ShiftL,
+ /* 161 */VK_RSHIFT, KEY_ShiftR, KEY_ShiftR,
+ /* 162 */VK_LCONTROL,KEY_LCtrl, KEY_LCtrl,
+ /* 163 */VK_RCONTROL,KEY_RCtrl, KEY_RCtrl,
+ /* 164 */VK_LMENU, KEY_Alt,KEY_Alt,
+ /* 165 */VK_RMENU, KEY_AltLang,KEY_AltLang,
/* 166 */0, 0, 0,
/* 167
Re: [patch 4/7] Cygwin/X: Invent a scan code if we dont have one
Jon,
Attached are my final patches. MAPVK_VK_TO_VSC_EX (which is 4, not 3)
did not help with the numeric-keypad key/num-lock problem. I have fixed
that problem with an update to the special case table in winkeybd.h. I
have also added to that table the (generated by software only) codes for
left/right-specific shift/control/alt. I have not tested the
left/right-specific entries. You may want to check that I have put the
correct codes in the correct rows (that correspond to the codes).
Paul
Paul Loewenstein wrote:
I plan to do a reasonably thorough investigation of what scan codes
show up during speech recognition. I believe I have seen both 0 and 1
(the ESC scancode). The latter must be a bug (almost certainly
Microsoft's) rather than a mere omission, but is much simpler to work
around than to get fixed. I believe it is safe to regenerate the
scancode for ESC, for all keyboards, even if the scancode is provided.
Have you looked at using| MAPVK_VK_TO_VSC_EX |(3) instead of
MAPVK_VK_TO_VSC(0)? This may solve the numeric keypad/numlock problem
described below. The code then has to look at the HIBYTE of the
regenerated iParamScanCode to check for E0, the extended key scancode,
and set KF_EXTENDED bit in HIWORD (lParam) if E0, then clear HIBYTE
(iParamScanCode).
When num-lock is asserted; with my tentative fix (using
MAPVK_VK_TO_VSC) saying move to end of line generates 1. However,
saying press end generates a fake end key correctly, I would guess
by enclosing the simulated key with simulated num-lock keystrokes.
Another valid way of dealing with these keys in the absence of a scan
code is to generate an extended key code (i.e. for the keys between
the numeric keypad and the alphabetic keys).
To resolve some of the above guesswork, I need to quickly hack an
application that displays both the virtual key code and the scan code,
together with the extended key indication. I should be able to do that
with a quick modification to publicly available code. I can also
modify it to test |MAPVK_VK_TO_VSC_EX|, which may solve the numeric
keypad scancode problem problem cleanly by providing extended keycodes
instead.
I would prefer to perform a clean, single fix. I'll also use diff!!
Paul
Reini Urban wrote:
Shouldn't we properly attribute Paul Loewenstein at least in the
patch who came up with this idea.
Jon TURNEY wrote:
Reini Urban wrote:
Shouldn't we properly attribute Paul Loewenstein at least in the
patch who came up with this idea.
Indeed, thanks for pointing out this oversight.
Revised patch attached.
That's what happens to people who don't use diff :-)
--
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/
*** xwin/xorg-server-1.5.3-4/src/xorg-server-1.5.3/hw/xwin/winkeybd.c Sat Jan
17 12:47:58 2009
--- /usr/src/xorg-server-1.5.3-4/src/xorg-server-1.5.3/hw/xwin/winkeybd.c
Sat Jan 17 13:17:33 2009
***
*** 76,100
void
winTranslateKey (WPARAM wParam, LPARAM lParam, int *piScanCode)
{
-
int iKeyFixup = g_iKeyMap[wParam * WIN_KEYMAP_COLS + 1];
int iKeyFixupEx = g_iKeyMap[wParam * WIN_KEYMAP_COLS + 2];
int iParamScanCode = LOBYTE (HIWORD (lParam));
- /* WM_ key messages faked by Vista speech recognition (WSR) don't have a
- * scan code.
- *
- * Vocola 3 (a supplement to WSR) uses
- * System.Windows.Forms.SendKeys.SendWait(), which appears to always
- * give a scan code of 1
- */
- if (iParamScanCode = 1)
- {
- iParamScanCode = MapVirtualKeyEx(wParam,
- /*MAPVK_VK_TO_VSC*/0,
- GetKeyboardLayout(0));
- }
-
/* Branch on special extended, special non-extended, or normal key */
if ((HIWORD (lParam) KF_EXTENDED) iKeyFixupEx)
*piScanCode = iKeyFixupEx;
--- 76,85
*** xwin/xorg-server-1.5.3-4/src/xorg-server-1.5.3/hw/xwin/winkeybd.h Sat Jan
17 12:46:15 2009
--- /usr/src/xorg-server-1.5.3-4/src/xorg-server-1.5.3/hw/xwin/winkeybd.h
Tue Oct 23 14:26:52 2007
***
*** 45,55
#define WIN_KEYMAP_COLS 3
- /* ASCII column, rows 33 through 40 are for Speech Recognition with
- * num-lock asserted.
- * Rows 160 through 165 correspond to software-generated codes, which
- * may not be associated with the appropriate scan code/extended bit
- */
const int
g_iKeyMap [] = {
/* countWindows VK, ASCII, ASCII when extended VK */
--- 45,50
***
*** 86,99
/* 30 */0, 0, 0,
/* 31 */0, 0, 0,
/* 32 */0, 0, 0,
! /* 33 */VK_PRIOR, KEY_PgUp
Re: [patch 4/7] Cygwin/X: Invent a scan code if we dont have one
Jon,
Sorry, I did the diff backwards. You can tell I don't do this often.
Corrected .diffs attached, so you don't have to use the patch reverse
option.
Paul
Paul Loewenstein wrote:
Jon,
Attached are my final patches. MAPVK_VK_TO_VSC_EX (which is 4, not 3)
did not help with the numeric-keypad key/num-lock problem. I have
fixed that problem with an update to the special case table in
winkeybd.h. I have also added to that table the (generated by
software only) codes for left/right-specific shift/control/alt. I
have not tested the left/right-specific entries. You may want to
check that I have put the correct codes in the correct rows (that
correspond to the codes).
Paul
Paul Loewenstein wrote:
I plan to do a reasonably thorough investigation of what scan codes
show up during speech recognition. I believe I have seen both 0 and
1 (the ESC scancode). The latter must be a bug (almost certainly
Microsoft's) rather than a mere omission, but is much simpler to work
around than to get fixed. I believe it is safe to regenerate the
scancode for ESC, for all keyboards, even if the scancode is provided.
Have you looked at using| MAPVK_VK_TO_VSC_EX |(3) instead of
MAPVK_VK_TO_VSC(0)? This may solve the numeric keypad/numlock
problem described below. The code then has to look at the HIBYTE of
the regenerated iParamScanCode to check for E0, the extended key
scancode, and set KF_EXTENDED bit in HIWORD (lParam) if E0, then
clear HIBYTE (iParamScanCode).
When num-lock is asserted; with my tentative fix (using
MAPVK_VK_TO_VSC) saying move to end of line generates 1.
However, saying press end generates a fake end key correctly, I
would guess by enclosing the simulated key with simulated num-lock
keystrokes.
Another valid way of dealing with these keys in the absence of a scan
code is to generate an extended key code (i.e. for the keys between
the numeric keypad and the alphabetic keys).
To resolve some of the above guesswork, I need to quickly hack an
application that displays both the virtual key code and the scan
code, together with the extended key indication. I should be able to
do that with a quick modification to publicly available code. I can
also modify it to test |MAPVK_VK_TO_VSC_EX|, which may solve the
numeric keypad scancode problem problem cleanly by providing extended
keycodes instead.
I would prefer to perform a clean, single fix. I'll also use diff!!
Paul
Reini Urban wrote:
Shouldn't we properly attribute Paul Loewenstein at least in the
patch who came up with this idea.
Jon TURNEY wrote:
Reini Urban wrote:
Shouldn't we properly attribute Paul Loewenstein at least in the
patch who came up with this idea.
Indeed, thanks for pointing out this oversight.
Revised patch attached.
That's what happens to people who don't use diff :-)
--
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/
--
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/
*** /usr/src/xorg-server-1.5.3-4/src/xorg-server-1.5.3/hw/xwin/winkeybd.c
Sat Jan 17 13:17:33 2009
--- xwin/xorg-server-1.5.3-4/src/xorg-server-1.5.3/hw/xwin/winkeybd.c Sat Jan
17 15:02:21 2009
***
*** 80,85
--- 80,99
int iKeyFixupEx = g_iKeyMap[wParam * WIN_KEYMAP_COLS + 2];
int iParamScanCode = LOBYTE (HIWORD (lParam));
+ /* WM_ key messages faked by Vista speech recognition (WSR) don't have a
+ * scan code.
+ *
+ * Vocola 3 (a supplement to WSR) uses
+ * System.Windows.Forms.SendKeys.SendWait(), which appears to always
+ * give a scan code of 1
+ */
+ if (iParamScanCode = 1)
+ {
+ iParamScanCode = MapVirtualKeyEx(wParam,
+ /*MAPVK_VK_TO_VSC*/0,
+ GetKeyboardLayout(0));
+ }
+
/* Branch on special extended, special non-extended, or normal key */
if ((HIWORD (lParam) KF_EXTENDED) iKeyFixupEx)
*piScanCode = iKeyFixupEx;
*** /usr/src/xorg-server-1.5.3-4/src/xorg-server-1.5.3/hw/xwin/winkeybd.h
Tue Oct 23 14:26:52 2007
--- xwin/xorg-server-1.5.3-4/src/xorg-server-1.5.3/hw/xwin/winkeybd.h Sat Jan
17 12:46:15 2009
***
*** 45,50
--- 45,55
#define WIN_KEYMAP_COLS 3
+ /* ASCII column, rows 33 through 40 are for Speech Recognition with
+ * num-lock asserted.
+ * Rows 160 through 165 correspond to software-generated codes, which
+ * may not be associated with the appropriate scan code/extended bit
Re: [patch 4/7] Cygwin/X: Invent a scan code if we dont have one
I plan to do a reasonably thorough investigation of what scan codes show up during speech recognition. I believe I have seen both 0 and 1 (the ESC scancode). The latter must be a bug (almost certainly Microsoft's) rather than a mere omission, but is much simpler to work around than to get fixed. I believe it is safe to regenerate the scancode for ESC, for all keyboards, even if the scancode is provided. Have you looked at using| MAPVK_VK_TO_VSC_EX |(3) instead of MAPVK_VK_TO_VSC(0)? This may solve the numeric keypad/numlock problem described below. The code then has to look at the HIBYTE of the regenerated iParamScanCode to check for E0, the extended key scancode, and set KF_EXTENDED bit in HIWORD (lParam) if E0, then clear HIBYTE (iParamScanCode). When num-lock is asserted; with my tentative fix (using MAPVK_VK_TO_VSC) saying move to end of line generates 1. However, saying press end generates a fake end key correctly, I would guess by enclosing the simulated key with simulated num-lock keystrokes. Another valid way of dealing with these keys in the absence of a scan code is to generate an extended key code (i.e. for the keys between the numeric keypad and the alphabetic keys). To resolve some of the above guesswork, I need to quickly hack an application that displays both the virtual key code and the scan code, together with the extended key indication. I should be able to do that with a quick modification to publicly available code. I can also modify it to test |MAPVK_VK_TO_VSC_EX|, which may solve the numeric keypad scancode problem problem cleanly by providing extended keycodes instead. I would prefer to perform a clean, single fix. I'll also use diff!! Paul Reini Urban wrote: Shouldn't we properly attribute Paul Loewenstein at least in the patch who came up with this idea. Jon TURNEY wrote: Reini Urban wrote: Shouldn't we properly attribute Paul Loewenstein at least in the patch who came up with this idea. Indeed, thanks for pointing out this oversight. Revised patch attached. That's what happens to people who don't use diff :-) -- 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/ -- 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/
Windows Vista Speech Recognition and Cygwin/X
The XWin server uses primarily hardware scan codes for interpreting the
windows WM_KEYDOWN and WM_SYSKEYDOWN messages. Unfortunately, Vista
speech recognition (WSR) doesn't bother to fill in the scancode field in
the lParam entry. Neither does SendKeys.SendWait(), which is what
Vocola 3, a recently released supplement to WSR, uses to send input to
applications.
To work around these Microsoft bugs, I modified winkeybd.c as follows:
void
winTranslateKey (WPARAM wParam, LPARAM lParam, int *piScanCode)
{
intiKeyFixup = g_iKeyMap[wParam * WIN_KEYMAP_COLS + 1];
intiKeyFixupEx = g_iKeyMap[wParam * WIN_KEYMAP_COLS + 2];
intiParamScanCode = LOBYTE (HIWORD (lParam));
to
void
winTranslateKey (WPARAM wParam, LPARAM lParam, int *piScanCode)
{
HKLdwhkl = GetKeyboardLayout(0);
intiKeyFixup = g_iKeyMap[wParam * WIN_KEYMAP_COLS + 1];
intiKeyFixupEx = g_iKeyMap[wParam * WIN_KEYMAP_COLS + 2];
intiParamScanCode = MapVirtualKeyEx (wParam,
/*MAPVK_VK_TO_VSC*/0, dwhkl);
so that the scan code is regenerated from the keycode.
An initial test appears to work. However, it is not clear to me whether
I have introduced some subtle bugs. For example, its correctness depends
on extended codes having the same scan code as the non-extended
equivalent on all keyboard layouts.
Can someone tell me if I've broken anything? Or suggest a more robust
fix? It would be nice to be able to release it rather than having a
privately distributed modification solely for Vista speech recognition.
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/
cygwin-xfree
I am suffering repeated xwin.exe crashes due to BadWindow (see attached /tmp/XWin.log). I am running Windows 2000. I am also running Dragon NaturallySpeaking 6.1, which I suspect has something to do with increasing the likelihood of applications receiving bad window handles. Is there any way of having xwin.exe recovering from this error rather than crashing? WRQ Reflection-X 9.0.1, which for various reasons I would like to retire, runs robustly in the same environment. Paul ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1600 h 1200 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 winSetEngine - Multi Window = ShadowGDI winAdjustVideoModeShadowGDI - Using Windows display depth of 32 bits per pixel winCreateBoundingWindowWindowed - User w: 1600 h: 1200 winCreateBoundingWindowWindowed - Current w: 1600 h: 1200 winAdjustForAutoHide - Original WorkArea: 0 0 1172 1600 winAdjustForAutoHide - Adjusted WorkArea: 0 0 1172 1600 winCreateBoundingWindowWindowed - WindowClient w 1600 h 1172 r 1600 l 0 b 1172 t 0 winCreateBoundingWindowWindowed - Returning winAllocateFBShadowGDI - Creating DIB with width: 1600 height: 1172 depth: 32 winAllocateFBShadowGDI - Dibsection width: 1600 height: 1172 depth: 32 size image: 7500800 winAllocateFBShadowGDI - Created shadow stride: 1600 winFinishScreenInitFB - Masks: 00ff ff00 00ff winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 winCreateDefColormap - Deferring to fbCreateDefColormap () null screen fn ReparentWindow null screen fn RestackWindow winFinishScreenInitFB - Calling winInitWM. InitQueue - Calling pthread_mutex_init InitQueue - pthread_mutex_init returned InitQueue - Calling pthread_cond_init InitQueue - pthread_cond_init returned winInitWM - Returning. winFinishScreenInitFB - returning winScreenInit - returning InitOutput - Returning. winInitMultiWindowWM - Hello winInitMultiWindowWM - Calling pthread_mutex_lock () winMultiWindowXMsgProc - Hello winMultiWindowXMsgProc - Calling pthread_mutex_lock () (EE) No primary keyboard configured (==) Using compiletime defaults for keyboard Rules = xfree86 Model = pc101 Layout = us Variant = (null) Options = (null) winPointerWarpCursor - Discarding first warp: 800 586 winBlockHandler - Releasing pmServerStarted winInitMultiWindowWM - pthread_mutex_lock () returned. DetectUnicodeSupport - Windows NT/2000/XP winInitMultiWindowWM - Calling setlocale () winBlockHandler - pthread_mutex_unlock () returned winInitMultiWindowWM - setlocale () returned winInitMultiWindowWM - XInitThreads () returned. winMultiWindowXMsgProc - pthread_mutex_lock () returned. winMultiWindowXMsgProc - XInitThreads () returned. winMultiWindowXMsgProc - pthread_mutex_unlock () returned. winMultiWindowXMsgProc - DISPLAY=127.0.0.1:0.0 winInitMultiWindowWM - pthread_mutex_unlock () returned. winInitMultiWindowWM - DISPLAY=127.0.0.1:0.0 winMultiWindowXMsgProc - XOpenDisplay () returned and successfully opened the display. winInitMultiWindowWM - XOpenDisplay () returned and successfully opened the display. winMultiWindowWMErrorHandler - ERROR: BadWindow (invalid Window parameter) winMultiWindowWMErrorHandler - ERROR: BadWindow (invalid Window parameter)
