[Lars Bjørndal] Re: brltty problems with recent snapshots

[Lars Bjørndal] Re: brltty problems with recent snapshots

[Lars Bjørndal]

[-- Attachment #1: Type: message/rfc822, Size: 1854 bytes --]

From: lars@lamasti.net (Lars Bjørndal)
To: Samuel Thibault <samuel.thibault@ens-lyon.org>
Subject: Re: brltty problems with recent snapshots
Date: Wed, 13 Jul 2011 11:06:46 +0200
Message-ID: <m37h7m7dnd.fsf@dalen.lamasti.net>

[Samuel Thibault]

> Corinna Vinschen, le Tue 12 Jul 2011 09:38:14 +0200, a écrit :
>> I just tried `brltty -b xw', too, and that's not what I see.  Every
>> keypress and every change to the command line is immediately reflected
>> in the brltty window.
>
> Ok, I believe the issue is particular to the driver then. It may be
> related to ttys due to the use of opening the braille device itself.
>
> Lars, are you using com1: or usb:?  Could you perhaps try to go yet
> earlier in the snapshots, up to the latest one which still works, so we
> can know which snapshot brought the bug exactly?

I'm using a com-port, since Modular Evolution has USB2serial conversion.

The latest cygwin1.dll that works for me, is 20110502.

Regards,
Lars


[-- Attachment #2: Type: text/plain, Size: 218 bytes --]

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: brltty problems with recent snapshots

[Lars Bjørndal]

[My self]

> The latest cygwin1.dll that works for me, is 20110502.

Just want to add that setting CYGWIN=tty, results in that 'bash --login
-i' won't work.

Lars

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: brltty problems with recent snapshots

[Corinna Vinschen]

On Jul 13 14:34, Lars Bjørndal wrote:
> [My self]
> 
> > The latest cygwin1.dll that works for me, is 20110502.
> 
> Just want to add that setting CYGWIN=tty, results in that 'bash --login
> -i' won't work.

Well, we're removing CYGWIN=tty anyway.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: brltty problems with recent snapshots

[Christopher Faylor]

On Wed, Jul 13, 2011 at 02:34:09PM +0200, Lars Bj?rndal wrote:
>[My self]
>
>> The latest cygwin1.dll that works for me, is 20110502.
>
>Just want to add that setting CYGWIN=tty, results in that 'bash --login
>-i' won't work.

?  The only thing that "set CYGWIN=tty" now is print a warning.
"CYGWIN=tty" has been removed in the latest snapshots.  So, except
for the warning, "CYGWIN=tty" is the same thing as "CYGWIN=notty".

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: [Lars Bjørndal] Re: brltty problems with recent snapshots

[Corinna Vinschen]

On Jul 13 13:41, Lars Bjørndal wrote:
> Date: Wed, 13 Jul 2011 11:06:46 +0200
> From: Lars Bjørndal <lars@lamasti.net>
> To: Samuel Thibault <samuel.thibault@ens-lyon.org>
> Subject: Re: brltty problems with recent snapshots
> 
> [Samuel Thibault]
> 
> > Corinna Vinschen, le Tue 12 Jul 2011 09:38:14 +0200, a écrit :
> >> I just tried `brltty -b xw', too, and that's not what I see.  Every
> >> keypress and every change to the command line is immediately reflected
> >> in the brltty window.
> >
> > Ok, I believe the issue is particular to the driver then. It may be
> > related to ttys due to the use of opening the braille device itself.
> >
> > Lars, are you using com1: or usb:?  Could you perhaps try to go yet
> > earlier in the snapshots, up to the latest one which still works, so we
> > can know which snapshot brought the bug exactly?
> 
> I'm using a com-port, since Modular Evolution has USB2serial conversion.
> 
> The latest cygwin1.dll that works for me, is 20110502.

Hmm, it seems I introduced a bug into serial I/O afterwards.
Does brltty use blocking or nonblocking I/O?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: [Lars Bjørndal] Re: brltty problems with recent snapshots

[Samuel Thibault]

Corinna Vinschen, le Wed 13 Jul 2011 15:05:50 +0200, a écrit :
> On Jul 13 13:41, Lars Bjørndal wrote:
> > I'm using a com-port, since Modular Evolution has USB2serial conversion.
> > 
> > The latest cygwin1.dll that works for me, is 20110502.
> 
> Hmm, it seems I introduced a bug into serial I/O afterwards.
> Does brltty use blocking or nonblocking I/O?

nonblocking.

Samuel

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: [Lars Bjørndal] Re: brltty problems with recent snapshots

[Corinna Vinschen]

On Jul 13 15:37, Samuel Thibault wrote:
> Corinna Vinschen, le Wed 13 Jul 2011 15:05:50 +0200, a écrit :
> > On Jul 13 13:41, Lars Bjørndal wrote:
> > > I'm using a com-port, since Modular Evolution has USB2serial conversion.
> > > 
> > > The latest cygwin1.dll that works for me, is 20110502.
> > 
> > Hmm, it seems I introduced a bug into serial I/O afterwards.
> > Does brltty use blocking or nonblocking I/O?
> 
> nonblocking.

I just applied a patch which tries to handle nonblocking I/O better.
Can you give it a try, please?


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: [Lars Bjørndal] Re: brltty problems with recent snapshots

[Lars Bjørndal]

On Wed, Jul 13, 2011 at 09:00:28PM +0200, Corinna Vinschen wrote:
> On Jul 13 15:37, Samuel Thibault wrote:
> > Corinna Vinschen, le Wed 13 Jul 2011 15:05:50 +0200, a écrit :
> > > On Jul 13 13:41, Lars Bjørndal wrote:
> > > > I'm using a com-port, since Modular Evolution has USB2serial conversion.
> > > > 
> > > > The latest cygwin1.dll that works for me, is 20110502.
> > > 
> > > Hmm, it seems I introduced a bug into serial I/O afterwards.
> > > Does brltty use blocking or nonblocking I/O?
> > 
> > nonblocking.
> 
> I just applied a patch which tries to handle nonblocking I/O better.
> Can you give it a try, please?

Is it available from cygwin.com/snapshots - or somewhere else? I ask
because tomorow is my last work day before I take a holiday break.

Lars

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: [Lars Bjørndal] Re: brltty problems with recent snapshots

[Corinna Vinschen]

On Jul 13 21:24, Lars Bjørndal wrote:
> On Wed, Jul 13, 2011 at 09:00:28PM +0200, Corinna Vinschen wrote:
> > On Jul 13 15:37, Samuel Thibault wrote:
> > > Corinna Vinschen, le Wed 13 Jul 2011 15:05:50 +0200, a écrit :
> > > > On Jul 13 13:41, Lars Bjørndal wrote:
> > > > > I'm using a com-port, since Modular Evolution has USB2serial conversion.
> > > > > 
> > > > > The latest cygwin1.dll that works for me, is 20110502.
> > > > 
> > > > Hmm, it seems I introduced a bug into serial I/O afterwards.
> > > > Does brltty use blocking or nonblocking I/O?
> > > 
> > > nonblocking.
> > 
> > I just applied a patch which tries to handle nonblocking I/O better.
> > Can you give it a try, please?
> 
> Is it available from cygwin.com/snapshots - or somewhere else? I ask
> because tomorow is my last work day before I take a holiday break.

I just uploaded a new snapshot.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: [Lars Bjørndal] Re: brltty problems with recent snapshots

[Lars Bjørndal]

[Corinna Vinschen]

> On Jul 13 15:37, Samuel Thibault wrote:
>> Corinna Vinschen, le Wed 13 Jul 2011 15:05:50 +0200, a écrit :
>> > On Jul 13 13:41, Lars Bjørndal wrote:
>> > > I'm using a com-port, since Modular Evolution has USB2serial conversion.
>> > > 
>> > > The latest cygwin1.dll that works for me, is 20110502.
>> > 
>> > Hmm, it seems I introduced a bug into serial I/O afterwards.
>> > Does brltty use blocking or nonblocking I/O?
>> 
>> nonblocking.
>
> I just applied a patch which tries to handle nonblocking I/O better.
> Can you give it a try, please?

Thank you! It works perfectly.

Now, back to the original problem, with c-x, c-c within Emacs.

Running Emacs from bash shell, and pressing this sequence, the Emacs
program exits, as expected. Witin a remote ssh session however, c-c get
the session to exit with the messsage: "Killed by signal 2".

Steps to reproduce:

1. Run cmd

2. bash --login -i

3. ssh user@host

4. c-c

There is also some issues when navigating in an emacs buffer with
cursoring keys. A beep is produced every time the cursor moves over a
line break. Try also to type a tab character and then use left arrow.
You'll then hear a beep. Also spaces generates beeps if you navigate
between them, but I'm not sure if that happens all the time.

Thanks and regards,
Lars

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: [Lars Bjørndal] Re: brltty problems with recent snapshots

[Corinna Vinschen]

On Jul 14 10:19, Lars Bjørndal wrote:
> [Corinna Vinschen]
> 
> > On Jul 13 15:37, Samuel Thibault wrote:
> >> Corinna Vinschen, le Wed 13 Jul 2011 15:05:50 +0200, a écrit :
> >> > On Jul 13 13:41, Lars Bjørndal wrote:
> >> > > I'm using a com-port, since Modular Evolution has USB2serial conversion.
> >> > > 
> >> > > The latest cygwin1.dll that works for me, is 20110502.
> >> > 
> >> > Hmm, it seems I introduced a bug into serial I/O afterwards.
> >> > Does brltty use blocking or nonblocking I/O?
> >> 
> >> nonblocking.
> >
> > I just applied a patch which tries to handle nonblocking I/O better.
> > Can you give it a try, please?
> 
> Thank you! It works perfectly.
> 
> Now, back to the original problem, with c-x, c-c within Emacs.
> 
> Running Emacs from bash shell, and pressing this sequence, the Emacs
> program exits, as expected. Witin a remote ssh session however, c-c get
> the session to exit with the messsage: "Killed by signal 2".
> 
> Steps to reproduce:
> 
> 1. Run cmd
> 
> 2. bash --login -i
> 
> 3. ssh user@host
> 
> 4. c-c

Thanks for the report, fixed in CVS.

> There is also some issues when navigating in an emacs buffer with
> cursoring keys. A beep is produced every time the cursor moves over a
> line break. Try also to type a tab character and then use left arrow.
> You'll then hear a beep. Also spaces generates beeps if you navigate
> between them, but I'm not sure if that happens all the time.

I can't reproduce this.  Is your TERM variable set to something
other than "cygwin"?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: [Lars Bjørndal] Re: brltty problems with recent snapshots

[Lars Bjørndal]

On Thu, Jul 14, 2011 at 12:16:09PM +0200, Corinna Vinschen wrote:
> On Jul 14 10:19, Lars Bjørndal wrote:
[...]

> > There is also some issues when navigating in an emacs buffer with
> > cursoring keys. A beep is produced every time the cursor moves over a
> > line break. Try also to type a tab character and then use left arrow.
> > You'll then hear a beep. Also spaces generates beeps if you navigate
> > between them, but I'm not sure if that happens all the time.
> 
> I can't reproduce this.  Is your TERM variable set to something
> other than "cygwin"?

Sorry. It turned out that this beeps came from a GUI screen reader,
Window-Eyes running, with speech and braill deactivated while in cmd.

One problem is left, which I'm not sure if it's a BRLTTY or cygwin
problem:

BRLTTY has a cut & paste facility. It sometimes doesn't paste all
characters inside cygwin. Pasting an att sign into a shell prompt, the
terminal beeps, and no character is written. Doing the same thing
after exiting bash, but still with BRLTTY running and in a cmd
session, the att sign is printed.

I'm not sure if you can cut & paste with BRLTTY without a braille
display. Let's ask Samuel.

Thanks and regards,
Lars

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: [Lars Bjørndal] Re: brltty problems with recent snapshots

[Samuel Thibault]

Lars Bjørndal, le Thu 14 Jul 2011 12:56:21 +0200, a écrit :
> BRLTTY has a cut & paste facility. It sometimes doesn't paste all
> characters inside cygwin. Pasting an att sign into a shell prompt, the
> terminal beeps, and no character is written. Doing the same thing
> after exiting bash, but still with BRLTTY running and in a cmd
> session, the att sign is printed.

I don't have the time to investigate now, but I can say that depending
on whether it could open the terminal through CONIN$, brltty uses
WriteConsoleInputW (or WriteConsoleInputA if not available) or SendInput
for this.

Samuel

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Issue with inserting '@' at the command prompt.

[Samuel Thibault]

Samuel Thibault, le Thu 14 Jul 2011 14:42:14 +0200, a écrit :
> Lars Bjørndal, le Thu 14 Jul 2011 12:56:21 +0200, a écrit :
> > BRLTTY has a cut & paste facility. It sometimes doesn't paste all
> > characters inside cygwin. Pasting an att sign into a shell prompt, the
> > terminal beeps, and no character is written. Doing the same thing
> > after exiting bash, but still with BRLTTY running and in a cmd
> > session, the att sign is printed.
> 
> I don't have the time to investigate now, but I can say that depending
> on whether it could open the terminal through CONIN$, brltty uses
> WriteConsoleInputW (or WriteConsoleInputA if not available) or SendInput
> for this.

In the case at stake it is WriteConsoleInputW. Let me explain a simpler
case (pasting is the same)

- the user presses '@' on his braille keyboard (ascii 0x40).
- brltty wants to synthesize it.
- brltty calls VkKeyScanW('@') to get the corresponding virtual key,
  0x0630 on an azerty keyboard, which means altgr (controlkeystate 1) +
  virtualkey 0x30
- brltty calls MapVirtualKey(vk, 0) to get the corresponding scancode,
  0x11 on a standard PC keyboard.
- brltty thus calls WriteConsoleInputW, passing it a KEY_EVENT_RECORD
  structure:
  .bKeyDown = 1,
  .wRepeatCount = 1,
  .wVirtualKeyCode = 0x630,
  .wVirtualScanCode = 0x11,
  .uChar.UnicodeChar = 0x40,
  .dwControlKeyState = 1,

and then the same with bKeyDown = 0.

This correctly inserts an '@' in a plain windows console with the
windows cmd, but with a windows console with the cygwin or mingw shell,
this beeps and does not insert anything.

Any idea?

Samuel

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Issue with inserting '@' at the command prompt.

[Samuel Thibault]

Samuel Thibault, le Fri 19 Aug 2011 04:37:40 +0200, a écrit :
> - the user presses '@' on his braille keyboard (ascii 0x40).

I forgot to mention: everything goes fine at the cmd, cygwin and mingw
shell when the pressed key is e.g. 'a', i.e. which does not need altgr.

Samuel

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Issue with inserting '@' at the command prompt.

[Corinna Vinschen]

On Aug 19 04:37, Samuel Thibault wrote:
> Samuel Thibault, le Thu 14 Jul 2011 14:42:14 +0200, a écrit :
> > Lars Bjørndal, le Thu 14 Jul 2011 12:56:21 +0200, a écrit :
> > > BRLTTY has a cut & paste facility. It sometimes doesn't paste all
> > > characters inside cygwin. Pasting an att sign into a shell prompt, the
> > > terminal beeps, and no character is written. Doing the same thing
> > > after exiting bash, but still with BRLTTY running and in a cmd
> > > session, the att sign is printed.
> > 
> > I don't have the time to investigate now, but I can say that depending
> > on whether it could open the terminal through CONIN$, brltty uses
> > WriteConsoleInputW (or WriteConsoleInputA if not available) or SendInput
> > for this.
> 
> In the case at stake it is WriteConsoleInputW. Let me explain a simpler
> case (pasting is the same)
> 
> - the user presses '@' on his braille keyboard (ascii 0x40).
> - brltty wants to synthesize it.
> - brltty calls VkKeyScanW('@') to get the corresponding virtual key,
>   0x0630 on an azerty keyboard, which means altgr (controlkeystate 1) +
>   virtualkey 0x30
> - brltty calls MapVirtualKey(vk, 0) to get the corresponding scancode,
>   0x11 on a standard PC keyboard.
> - brltty thus calls WriteConsoleInputW, passing it a KEY_EVENT_RECORD
>   structure:
>   .bKeyDown = 1,
>   .wRepeatCount = 1,
>   .wVirtualKeyCode = 0x630,
>   .wVirtualScanCode = 0x11,
>   .uChar.UnicodeChar = 0x40,
>   .dwControlKeyState = 1,
> 
> and then the same with bKeyDown = 0.
> 
> This correctly inserts an '@' in a plain windows console with the
> windows cmd, but with a windows console with the cygwin or mingw shell,
> this beeps and does not insert anything.

I don't know why it works with cmd, but the above code is wrong.
The code returned by VkKeyScanW is not just a key code, it's the
combination of a key code in the low byte and a bitmask specifying
the modifier keys in the high byte, see
http://msdn.microsoft.com/en-us/library/ms646329%28VS.85%29.aspx

So, what I did was to write a simple testcase (wow!) which reproduces
your behaviour using the french keyboard layout.

Using the above virtual key code of 0xc630 and a control key state of 1
does not work.  However, computing a control code and a key code from
VkKeyScanW's return value works fine.

Here's the testcase:

$ cat > vkkeyscan-test.c <<EOF
#include <stdio.h>
#include <sys/ioctl.h>
#include <windows.h>

#define MAPVK_VK_TO_VSC    0
#define MAPVK_VSC_TO_VK    1
#define MAPVK_VK_TO_CHAR   2
#define MAPVK_VSC_TO_VK_EX 3
#define MAPVK_VK_TO_VSC_EX 4

void
write_char (WCHAR w, BOOL wrong, BOOL silent)
{
  SHORT vks = VkKeyScanW (w);
  UINT scan = MapVirtualKeyW (vks & 0xff, MAPVK_VK_TO_VSC);
  DWORD ctrl = 0;
  INPUT_RECORD in[2];
  DWORD ret;

  /* Create correct CtrlKeyState from high byte returned by VkKeyScanW. */
  if (vks & 0x100)
    ctrl |= SHIFT_PRESSED;
  if (vks & 0x200)
    ctrl |= RIGHT_CTRL_PRESSED;
  if (vks & 0x400)
    ctrl |= RIGHT_ALT_PRESSED;

  in[0].EventType = KEY_EVENT;
  in[0].Event.KeyEvent.bKeyDown = 1;
  in[0].Event.KeyEvent.wRepeatCount = 1;
  /* Only use lower byte from VkKeyScanW as key code. */
  if (wrong)
    in[0].Event.KeyEvent.wVirtualKeyCode = vks;
  else
    in[0].Event.KeyEvent.wVirtualKeyCode = vks & 0xff;
  in[0].Event.KeyEvent.wVirtualScanCode = scan;
  in[0].Event.KeyEvent.uChar.UnicodeChar = w;
  if (wrong)
    in[0].Event.KeyEvent.dwControlKeyState = 1;
  else
    in[0].Event.KeyEvent.dwControlKeyState = ctrl;
  memcpy (in + 1, in, sizeof (INPUT_RECORD));
  in[1].Event.KeyEvent.bKeyDown = 0;

  if (!silent)
    printf ("vks: 0x%hx, scan: 0x%x, vk: 0x%hx, ctrl: 0x%x\n",
	    vks, scan, in[0].Event.KeyEvent.wVirtualKeyCode,
	    in[0].Event.KeyEvent.dwControlKeyState);

  if (!WriteConsoleInputW (GetStdHandle (STD_INPUT_HANDLE), in, 2, &ret))
    fprintf (stderr, "WriteConsoleInput: %lu\n", GetLastError ());
}

int
main ()
{
  HKL layout;
  int nonblocking = 1;
  char buf[1];

  /* LANG_FRENCH | SUBLANG_FRENCH */
  layout = LoadKeyboardLayoutW (L"0000040c", KLF_ACTIVATE | KLF_REPLACELANG
					     | KLF_SETFORPROCESS);
  if (!layout)
    {
      fprintf (stderr, "LoadKeyboardLayout: %lu\n", GetLastError ());
      return 1;
    }
  /* nonblocking, so the user doesn't have to type anything. */
  ioctl (0, FIONBIO, &nonblocking);

  printf ("Wrong:\n");
  write_char (L'@', TRUE, FALSE);
  write_char (L'\n', TRUE, TRUE); /* Accommodate line buffered I/O. */
  if (read (0, buf, 1) > 0)
    printf ("read: 0x%x <%c>\n", buf[0], buf[0]);

  printf ("Right:\n");
  write_char (L'@', FALSE, FALSE);
  write_char (L'\n', FALSE, TRUE); /* Accommodate line buffered I/O. */
  if (read (0, buf, 1) > 0)
    printf ("read: 0x%x <%c>\n", buf[0], buf[0]);

  return 0;
}
EOF
$ gcc -g -o vkkeyscan-test vkkeyscan-test.c
$ ./vkkeyscan-test
Wrong:
vks: 0x630, scan: 0xb, vk: 0x630, ctrl: 0x1
read: 0x1b <
Right:
vks: 0x630, scan: 0xb, vk: 0x30, ctrl: 0x5
read: 0x40 <@>


Corinna


-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Issue with inserting '@' at the command prompt.

[Samuel Thibault]

Corinna Vinschen, le Fri 19 Aug 2011 13:50:19 +0200, a écrit :
> >   .wVirtualKeyCode = 0x630,

Eergl, no, that should have been 0x30 here, our code does properly masks
out the high part, I just missed that in our code.

> a simple testcase (wow!)

Sorry, but I'm not paid for this, I don't actually use the software at
all (neither brltty nor windows), don't actually own the hardware (thus
had to emulate it in qemu by first reverse-engineering the actual device
behavior), it just seems I'm the only guy in the world that knows a bit
about both brltty and windows and knows that some people *need* it, and
I thus spend time on it, and it was already almost 5am...

>   /* Create correct CtrlKeyState from high byte returned by VkKeyScanW. */
>   if (vks & 0x100)
>     ctrl |= SHIFT_PRESSED;
>   if (vks & 0x200)
>     ctrl |= RIGHT_CTRL_PRESSED;
>   if (vks & 0x400)
>     ctrl |= RIGHT_ALT_PRESSED;

Err, do you mean LEFT_ALT_PRESSED here? Right alt is altgr in some
keyboard layouts, which is precisely what people use to type '@' in
the french layout, actually. E.g. LeftAlt-A and RightAlt-A (i.e.
altgr-a) is not the same in such layouts. In the past we were using
left_ctrl+left_alt, but this was not working in DOS applications in cmd,
so we made it a special case by using right alt instead.

I have now added right control along right alt, which indeed fixes
the issue, I am apparently unable to run DOS applications in my XP
installation, but I hope it will also work there.

Thanks,
Samuel

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Issue with inserting '@' at the command prompt.

[Corinna Vinschen]

On Aug 19 15:14, Samuel Thibault wrote:
> Corinna Vinschen, le Fri 19 Aug 2011 13:50:19 +0200, a écrit :
> > >   .wVirtualKeyCode = 0x630,
> 
> Eergl, no, that should have been 0x30 here, our code does properly masks
> out the high part, I just missed that in our code.

And what about the control code?  It's a fixed 1 in your example, but
obviously it should be 6.

> > a simple testcase (wow!)
> 
> Sorry, but I'm not paid for this, I don't actually use the software at
> all (neither brltty nor windows), don't actually own the hardware (thus
> had to emulate it in qemu by first reverse-engineering the actual device
> behavior),

Same here.  I tested this on a Qemu/KVM driven W7 box.

> it just seems I'm the only guy in the world that knows a bit
> about both brltty and windows and knows that some people *need* it, and
> I thus spend time on it, and it was already almost 5am...
> 
> >   /* Create correct CtrlKeyState from high byte returned by VkKeyScanW. */
> >   if (vks & 0x100)
> >     ctrl |= SHIFT_PRESSED;
> >   if (vks & 0x200)
> >     ctrl |= RIGHT_CTRL_PRESSED;
> >   if (vks & 0x400)
> >     ctrl |= RIGHT_ALT_PRESSED;
> 
> Err, do you mean LEFT_ALT_PRESSED here? Right alt is altgr in some
> keyboard layouts, which is precisely what people use to type '@' in
> the french layout, actually. E.g. LeftAlt-A and RightAlt-A (i.e.

I'm aware of this difference, so, no, that was a deliberate
RIGHT_ALT_PRESSED.  However, this also works for me when using
LEFT_CTRL_PRESSED and LEFT_ALT_PRESSED in the conditionals above.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Issue with inserting '@' at the command prompt.

[Samuel Thibault]

[-- Attachment #1: Type: text/plain, Size: 1448 bytes --]

Corinna Vinschen, a écrit :
> On Aug 19 15:14, Samuel Thibault wrote:
> > Corinna Vinschen, le Fri 19 Aug 2011 13:50:19 +0200, a Ãcrit :
> > > >   .wVirtualKeyCode = 0x630,
> >
> > Eergl, no, that should have been 0x30 here, our code does properly masks
> > out the high part, I just missed that in our code.
> 
> And what about the control code?  It's a fixed 1 in your example,

That's only the example. 1 is obviously not hardcoded in the real source
code, which I have attached (I just initially wanted to avoid you having
to browse into the whole not-so-readable source ).

> but obviously it should be 6.

That's clearly not obvious from an altgr point of view: people use altgr
to type '@', so it makes sense to simulate the hit of the right alt
(i.e. altgr).

> > Err, do you mean LEFT_ALT_PRESSED here? Right alt is altgr in some
> > keyboard layouts, which is precisely what people use to type '@' in
> > the french layout, actually. E.g. LeftAlt-A and RightAlt-A (i.e.
> 
> I'm aware of this difference, so, no, that was a deliberate
> RIGHT_ALT_PRESSED.

But for the cases when only alt is to be pressed, this simulates a right
alt, which with e.g. the french layout is not the same as the left one.

> However, this also works for me when using
> LEFT_CTRL_PRESSED and LEFT_ALT_PRESSED in the conditionals above.

But it won't work with DOS applications (e.g. edit). That's precisely
the reason why I added the special case.

Samuel

[-- Attachment #2: screen.c --]
[-- Type: text/plain, Size: 17081 bytes --]

/*
 * BRLTTY - A background process providing access to the console screen (when in
 *          text mode) for a blind person using a refreshable braille display.
 *
 * Copyright (C) 1995-2011 by The BRLTTY Developers.
 *
 * BRLTTY comes with ABSOLUTELY NO WARRANTY.
 *
 * This is free software, placed under the terms of the
 * GNU General Public License, as published by the Free Software
 * Foundation; either version 2 of the License, or (at your option) any
 * later version. Please see the file LICENSE-GPL for details.
 *
 * Web Page: http://mielke.cc/brltty/
 *
 * This software is maintained by Dave Mielke <dave@mielke.cc>.
 */

#include "prologue.h"

#include "log.h"
#include "parse.h"
#include "brldefs.h"
#include "sys_windows.h"
#include "scancodes.h"
#include "unicode.h"

typedef enum {
  PARM_ROOT,
  PARM_FOLLOWFOCUS
} ScreenParameters;
#define SCRPARMS "root", "followfocus"
static unsigned int root, followFocus;

#include "scr_driver.h"

static HANDLE consoleOutput = INVALID_HANDLE_VALUE;
static HANDLE consoleInput = INVALID_HANDLE_VALUE;

static int
processParameters_WindowsScreen (char **parameters) {
  root = 0;
  if (*parameters[PARM_ROOT])
    if (!validateYesNo(&root, parameters[PARM_ROOT]))
      logMessage(LOG_WARNING, "%s: %s", "invalid root setting", parameters[PARM_ROOT]);
  if (root && AttachConsoleProc)
    logMessage(LOG_WARNING, "No need for root BRLTTY on newer (XP or later) systems");

  followFocus = 1;
  if (*parameters[PARM_FOLLOWFOCUS])
    if (!validateYesNo(&followFocus, parameters[PARM_FOLLOWFOCUS]))
      logMessage(LOG_WARNING, "%s: %s", "invalid follow focus setting", parameters[PARM_FOLLOWFOCUS]);
  if (followFocus && !AttachConsoleProc)
    logMessage(LOG_WARNING, "Cannot follow focus on older (pre-XP) systems");
  return 1;
}

static int
openStdHandles (void) {
  if ((consoleOutput == INVALID_HANDLE_VALUE &&
    (consoleOutput = CreateFile("CONOUT$",GENERIC_READ|GENERIC_WRITE,FILE_SHARE_READ|FILE_SHARE_WRITE,NULL,OPEN_EXISTING,0,NULL)) == INVALID_HANDLE_VALUE)
    ||(consoleInput == INVALID_HANDLE_VALUE &&
    (consoleInput = CreateFile("CONIN$",GENERIC_READ|GENERIC_WRITE,FILE_SHARE_READ|FILE_SHARE_WRITE,NULL,OPEN_EXISTING,0,NULL)) == INVALID_HANDLE_VALUE)) {
    logWindowsSystemError("GetStdHandle");
    return 0;
  }
  return 1;
}

static void
closeStdHandles (void) {
  CloseHandle(consoleInput);
  consoleInput = INVALID_HANDLE_VALUE;
  CloseHandle(consoleOutput);
  consoleOutput = INVALID_HANDLE_VALUE;
}

static int
tryToAttach (HWND win) {
#define CONSOLEWINDOW "ConsoleWindowClass"
  static char class[] = CONSOLEWINDOW;
  DWORD process;
  if (GetClassName(win, class, sizeof(class)) != strlen(CONSOLEWINDOW)
      || memcmp(class,CONSOLEWINDOW,strlen(CONSOLEWINDOW)))
    return 0;
  if (!GetWindowThreadProcessId(win, &process))
    return 0;
  FreeConsole();
  if (!AttachConsoleProc(process))
    return 0;
  closeStdHandles();
  return openStdHandles();
}

static int
construct_WindowsScreen (void) {
  if (followFocus && (AttachConsoleProc || root)) {
    /* disable ^C */
    SetConsoleCtrlHandler(NULL,TRUE);
    if (!FreeConsole() && GetLastError() != ERROR_INVALID_PARAMETER)
      logWindowsSystemError("FreeConsole");
    return 1;
  }
  return openStdHandles();
}

static void
destruct_WindowsScreen (void) {
  closeStdHandles();
}

static int
selectVirtualTerminal_WindowsScreen (int vt) {
  return 0;
}

static int
switchVirtualTerminal_WindowsScreen (int vt) {
  return 0;
}

static ALTTABINFO altTabInfo;
static HWND altTab;
static char altTabName[128];
static BOOL CALLBACK
findAltTab (HWND win, LPARAM lparam) {
  if (GetAltTabInfoAProc(win, -1, &altTabInfo, NULL, 0)) {
    altTab = win;
    return FALSE;
  }
  return TRUE;
}

static CONSOLE_SCREEN_BUFFER_INFO info;
static const char *unreadable;
static int cols;
static int rows;

static int
currentVirtualTerminal_WindowsScreen (void) {
  HWND win;

  unreadable = NULL;
  altTab = NULL;

  if (followFocus && (AttachConsoleProc || root) && GetAltTabInfoAProc) {
    altTabInfo.cbSize = sizeof(altTabInfo);
    EnumWindows(findAltTab, 0);

    if (altTab) {
      if (!(GetAltTabInfoAProc(altTab,
	      altTabInfo.iColFocus + altTabInfo.iRowFocus * altTabInfo.cColumns,
	      &altTabInfo, altTabName, sizeof(altTabName)))) {
	altTab = NULL;
      } else {
	return 0;
      }
    }
  }

  if (!(win = GetForegroundWindow())) win = INVALID_HANDLE_VALUE;

  if (!AttachConsoleProc && root) {
    unreadable = "root BRLTTY";
  } else if (win == INVALID_HANDLE_VALUE) {
    unreadable = "no foreground window";
  } else if (followFocus && AttachConsoleProc && !tryToAttach(win)) {
    unreadable = "no attachable console";
  } else if (consoleOutput == INVALID_HANDLE_VALUE) {
    unreadable = "can't open console output";
  } else if (!(GetConsoleScreenBufferInfo(consoleOutput, &info))) {
    logWindowsSystemError("GetConsoleScreenBufferInfo");
    unreadable = "can't read console information";

    CloseHandle(consoleOutput);
    consoleOutput = INVALID_HANDLE_VALUE;
  }

  return (int)win;
}

static void
describe_WindowsScreen (ScreenDescription *description) {
  description->number = (int) currentVirtualTerminal_WindowsScreen();
  description->unreadable = unreadable;
  if (unreadable) {
    description->rows = 1;
    description->cols = strlen(unreadable);
    description->posx = 0;
    description->posy = 0;
    description->cursor = 0;
  } else if (altTab) {
    description->rows = 1;
    description->cols = strlen(altTabName);
    description->posx = 0;
    description->posy = 0;
    description->cursor = 0;
  } else {
    description->cols = info.srWindow.Right + 1 - info.srWindow.Left;
    description->rows = info.srWindow.Bottom + 1 - info.srWindow.Top;
    description->posx = info.dwCursorPosition.X - info.srWindow.Left;
    description->posy = info.dwCursorPosition.Y - info.srWindow.Top; 
    description->cursor = 1;
  }
  cols = description->cols;
  rows = description->rows;
}

static int
readCharacters_WindowsScreen (const ScreenBox *box, ScreenCharacter *buffer) {
  int x, xx, y;
  static int wide;
  COORD coord;

  BOOL WINAPI (*fun) (HANDLE, void*, DWORD, COORD, LPDWORD);
  const char *name;
  size_t size;
  void *buf;
  WORD *bufAttr;

  if (!validateScreenBox(box, cols, rows)) return 0;

  if (unreadable) {
    setScreenMessage(box, buffer, unreadable);
    return 1;
  }

  if (altTab) {
    setScreenMessage(box, buffer, altTabName);
    return 1;
  }

  coord.X = box->left + info.srWindow.Left;
  coord.Y = box->top + info.srWindow.Top;

  if (!wide) {
    wchar_t buf;
    DWORD read;
    if (ReadConsoleOutputCharacterW(consoleOutput, &buf, 1, coord, &read))
      wide = 1;
    else {
      if (GetLastError() == ERROR_CALL_NOT_IMPLEMENTED)
	wide = -1;
      else {
	logWindowsSystemError("ReadConsoleOutputCharacterW");
	return 0;
      }
    }
  }
#define USE(f, t) (fun = (typeof(fun))f, name = #f, size = sizeof(t))
  if (wide > 0)
    USE(ReadConsoleOutputCharacterW, wchar_t);
  else
    USE(ReadConsoleOutputCharacterA, char);
#undef USE

  if (!(buf = malloc(box->width*size))) {
    logSystemError("malloc for Windows console reading");
    return 0;
  }

  if (!(bufAttr = malloc(box->width*sizeof(WORD)))) {
    logSystemError("malloc for Windows console reading");
    free(buf);
    return 0;
  }

  for (y=0; y<box->height; y++, coord.Y++) {
    DWORD read;

    if (!fun(consoleOutput, buf, box->width, coord, &read)) {
      logWindowsSystemError(name);
      break;
    }

    if (wide > 0) {
      for (x=0, xx = 0; x<box->width && xx < read; x++, xx++) {
	wchar_t wc = ((wchar_t*)buf)[xx];
	int i;

	buffer[y*box->width+x].text = wc;
	for (i = 1; i < getCharacterWidth(wc); i++) {
	  x++;
	  buffer[y*box->width+x].text = UNICODE_ZERO_WIDTH_SPACE;
	}
      }
      for ( ; x<box->width; x++) {
	buffer[y*box->width+x].text = L' ';
      }
    } else {
      for (x=0; x<read; x++) {
	/* TODO: GetConsoleCP and convert */
	buffer[y*box->width+x].text = ((char*)buf)[x];
      }
      for ( ; x<box->width; x++) {
	buffer[y*box->width+x].text = ' ';
      }
    }

    if (!ReadConsoleOutputAttribute(consoleOutput, bufAttr, box->width, coord, &read)) {
      logWindowsSystemError(name);
      break;
    }

    for (x=0, xx=0; x<box->width && xx < read; x++, xx++) {
      int i;
      buffer[y*box->width+x].attributes = bufAttr[xx];
      for (i = 1; i < getCharacterWidth(buffer[y*box->width+x].text); i++) {
	x++;
        buffer[y*box->width+x].attributes = bufAttr[xx];
      }
    }
    for ( ; x < box->width; x++)
      buffer[y*box->width+x].attributes = 0;
  }

  free(buf);
  free(bufAttr);

  return (y == box->height);
}

static int 
doInsertWriteConsoleInput (BOOL down, WCHAR wchar, WORD vk, WORD scancode, DWORD controlKeyState) {
  DWORD num;
  INPUT_RECORD buf;
  KEY_EVENT_RECORD *keyE = &buf.Event.KeyEvent;

  buf.EventType = KEY_EVENT;
  memset(keyE, 0, sizeof(*keyE));
  keyE->bKeyDown = down;
  keyE->wRepeatCount = 1;
  keyE->wVirtualKeyCode = vk;
  keyE->wVirtualScanCode = scancode;
  keyE->uChar.UnicodeChar = wchar;
  keyE->dwControlKeyState = controlKeyState;
  if (WriteConsoleInputW(consoleInput, &buf, 1, &num)) {
    if (num == 1) {
      return 1;
    } else {
      logMessage(LOG_ERR, "inserted %ld keys, expected 1", num);
    }
  } else {
    if (GetLastError() == ERROR_CALL_NOT_IMPLEMENTED) {
      keyE->uChar.AsciiChar = wchar;
      if (WriteConsoleInputA(consoleInput, &buf, 1, &num)) {
	if (num == 1) {
	  return 1;
	} else {
	  logMessage(LOG_ERR, "inserted %ld keys, expected 1", num);
	}
      }
    }
    logWindowsSystemError("WriteConsoleInput");
    CloseHandle(consoleInput);
    consoleInput = INVALID_HANDLE_VALUE;
  }
  return 0;
}

static int 
doInsertSendInput (BOOL down, WCHAR wchar, WORD vk, WORD scancode, DWORD flags) {
  if (SendInputProc) {
    UINT num;
    INPUT input;
    KEYBDINPUT *ki = &input.ki;

    input.type = INPUT_KEYBOARD;
    memset(ki, 0, sizeof(*ki));
    ki->dwFlags = flags;
    if (wchar) {
      ki->wVk = 0;
      ki->wScan = wchar;
      ki->dwFlags |= KEYEVENTF_UNICODE;
    } else {
      ki->wVk = vk;
      ki->wScan = scancode;
    }

    if (!down)
      ki->dwFlags |= KEYEVENTF_KEYUP;

    num = SendInput(1, &input, sizeof(INPUT));
    switch (num) {
      case 1:  return 1;
      case 0:  logWindowsSystemError("SendInput"); break;
      default: logMessage(LOG_ERR, "inserted %d keys, expected 1", num); break;
    }
    return 0;
  } else {
    keybd_event(vk, scancode, flags | (down ? 0 : KEYEVENTF_KEYUP), 0);
    return 1;
  }
}

static int
insertKey_WindowsScreen (ScreenKey key) {
  SHORT vk = 0;
  SHORT scancode = 0;
  DWORD controlKeyState = 0;
  WCHAR wchar = 0;

  logMessage(LOG_DEBUG, "Insert key: %4.4X",key);
  if (isSpecialKey(key)) {
    switch (key & SCR_KEY_CHAR_MASK) {
      case SCR_KEY_ENTER:         vk = VK_RETURN; wchar='\r'; break;
      case SCR_KEY_TAB:           vk = VK_TAB;    wchar='\t'; break;
      case SCR_KEY_BACKSPACE:     vk = VK_BACK;   wchar='\b'; break;
      case SCR_KEY_ESCAPE:        vk = VK_ESCAPE; wchar='\e'; break;
      case SCR_KEY_CURSOR_LEFT:   vk = VK_LEFT;   break;
      case SCR_KEY_CURSOR_RIGHT:  vk = VK_RIGHT;  break;
      case SCR_KEY_CURSOR_UP:     vk = VK_UP;     break;
      case SCR_KEY_CURSOR_DOWN:   vk = VK_DOWN;   break;
      case SCR_KEY_PAGE_UP:       vk = VK_PRIOR;  break;
      case SCR_KEY_PAGE_DOWN:     vk = VK_NEXT;   break;
      case SCR_KEY_HOME:          vk = VK_HOME;   break;
      case SCR_KEY_END:           vk = VK_END;    break;
      case SCR_KEY_INSERT:        vk = VK_INSERT; break;
      case SCR_KEY_DELETE:        vk = VK_DELETE; break;
      case SCR_KEY_FUNCTION + 0:  vk = VK_F1;     break;
      case SCR_KEY_FUNCTION + 1:  vk = VK_F2;     break;
      case SCR_KEY_FUNCTION + 2:  vk = VK_F3;     break;
      case SCR_KEY_FUNCTION + 3:  vk = VK_F4;     break;
      case SCR_KEY_FUNCTION + 4:  vk = VK_F5;     break;
      case SCR_KEY_FUNCTION + 5:  vk = VK_F6;     break;
      case SCR_KEY_FUNCTION + 6:  vk = VK_F7;     break;
      case SCR_KEY_FUNCTION + 7:  vk = VK_F8;     break;
      case SCR_KEY_FUNCTION + 8:  vk = VK_F9;     break;
      case SCR_KEY_FUNCTION + 9:  vk = VK_F10;    break;
      case SCR_KEY_FUNCTION + 10: vk = VK_F11;    break;
      case SCR_KEY_FUNCTION + 11: vk = VK_F12;    break;
      case SCR_KEY_FUNCTION + 12: vk = VK_F13;    break;
      case SCR_KEY_FUNCTION + 13: vk = VK_F14;    break;
      case SCR_KEY_FUNCTION + 14: vk = VK_F15;    break;
      case SCR_KEY_FUNCTION + 15: vk = VK_F16;    break;
      case SCR_KEY_FUNCTION + 16: vk = VK_F17;    break;
      case SCR_KEY_FUNCTION + 17: vk = VK_F18;    break;
      case SCR_KEY_FUNCTION + 18: vk = VK_F19;    break;
      case SCR_KEY_FUNCTION + 19: vk = VK_F20;    break;
      case SCR_KEY_FUNCTION + 20: vk = VK_F21;    break;
      case SCR_KEY_FUNCTION + 21: vk = VK_F22;    break;
      case SCR_KEY_FUNCTION + 22: vk = VK_F23;    break;
      case SCR_KEY_FUNCTION + 23: vk = VK_F24;    break;
      default: logMessage(LOG_WARNING, "Key %4.4X not suported.", key);
               return 0;
    }
  } else {
    if (key & SCR_KEY_ALT_LEFT) {
      controlKeyState |= LEFT_ALT_PRESSED;
      key &= ~ SCR_KEY_ALT_LEFT;
    }
    if (key & SCR_KEY_ALT_RIGHT) {
      controlKeyState |= RIGHT_ALT_PRESSED;
      key &= ~ SCR_KEY_ALT_RIGHT;
    }
    if (key & SCR_KEY_SHIFT) {
      controlKeyState |= SHIFT_PRESSED;
      key &= ~ SCR_KEY_SHIFT;
    }
    if (key & SCR_KEY_CONTROL) {
      controlKeyState |= LEFT_CTRL_PRESSED;
      key &= ~ SCR_KEY_CONTROL;
    }
    wchar = key & SCR_KEY_CHAR_MASK;
    vk = VkKeyScanW(wchar);
    if (vk == -1 && GetLastError() == ERROR_CALL_NOT_IMPLEMENTED)
      vk = VkKeyScan(wchar);
    if (vk != -1) {
      logMessage(LOG_DEBUG, "vk is %4.4X", vk);
      if (vk & 0x100) controlKeyState |= SHIFT_PRESSED;
      if ((vk & 0x600) == 0x600) {
	controlKeyState |= RIGHT_ALT_PRESSED;
      } else {
        if (vk & 0x200) controlKeyState |= LEFT_CTRL_PRESSED;
        if (vk & 0x400) controlKeyState |= LEFT_ALT_PRESSED;
      }
      vk = vk & 0xff;
    } else vk = 0;
  }

  scancode = MapVirtualKey(vk, 0);

  logMessage(LOG_DEBUG,"wchar %x vk %x scancode %d ks %ld", wchar, vk, scancode, controlKeyState);
  if (consoleInput != INVALID_HANDLE_VALUE && !unreadable) {
    logMessage(LOG_DEBUG, "using WriteConsoleInput");
    if (!doInsertWriteConsoleInput(TRUE, wchar, vk, scancode, controlKeyState))
      return 0;
    if (!doInsertWriteConsoleInput(FALSE, wchar, vk, scancode, controlKeyState))
      return 0;
    return 1;
  } else {
    logMessage(LOG_DEBUG, "using SendInput");
    if (controlKeyState & LEFT_CTRL_PRESSED)
      if (!doInsertSendInput(TRUE, 0, VK_CONTROL, 0, 0))
        return 0;
    if (controlKeyState & SHIFT_PRESSED)
      if (!doInsertSendInput(TRUE, 0, VK_SHIFT, 0, 0))
        return 0;
    if (controlKeyState & LEFT_ALT_PRESSED)
      if (!doInsertSendInput(TRUE, 0, VK_MENU, 0, 0))
        return 0;
    if (controlKeyState & RIGHT_ALT_PRESSED)
      if (!doInsertSendInput(TRUE, 0, VK_RMENU, 0, 0))
        return 0;
    if (!doInsertSendInput(TRUE, wchar, vk, scancode, 0))
      return 0;
    if (!doInsertSendInput(FALSE, wchar, vk, scancode, 0))
      return 0;
    if (controlKeyState & RIGHT_ALT_PRESSED)
      if (!doInsertSendInput(FALSE, 0, VK_RMENU, 0, 0))
        return 0;
    if (controlKeyState & LEFT_ALT_PRESSED)
      if (!doInsertSendInput(FALSE, 0, VK_MENU, 0, 0))
        return 0;
    if (controlKeyState & SHIFT_PRESSED)
      if (!doInsertSendInput(FALSE, 0, VK_SHIFT, 0, 0))
        return 0;
    if (controlKeyState & LEFT_CTRL_PRESSED)
      if (!doInsertSendInput(FALSE, 0, VK_CONTROL, 0, 0))
        return 0;
    return 1;
  }
  return 0;
}

static int
executeCommand_WindowsScreen (int command) {
  int blk = command & BRL_MSK_BLK;
  int arg = command & BRL_MSK_ARG;
  int press = 0;

  switch (blk) {
    case BRL_BLK_PASSXT:
      press = !(arg & 0X80);
      arg &= 0X7F;
      /* fallthrough */
    case BRL_BLK_PASSAT: {
      press |= !(command & BRL_FLG_KBD_RELEASE);

      if (arg >= 0X80)
	return 0;

      if (command & BRL_FLG_KBD_EMUL1)
	return 0;

      if (blk == BRL_BLK_PASSAT)
	arg = at2Xt[arg];

      return doInsertSendInput (press, 0, 0, arg,
	  command & BRL_FLG_KBD_EMUL0 ? KEYEVENTF_EXTENDEDKEY : 0);
    }
  }

  return 0;
}

static void
scr_initialize (MainScreen *main) {
  initializeRealScreen(main);
  main->base.selectVirtualTerminal = selectVirtualTerminal_WindowsScreen;
  main->base.switchVirtualTerminal = switchVirtualTerminal_WindowsScreen;
  main->base.currentVirtualTerminal = currentVirtualTerminal_WindowsScreen;
  main->base.describe = describe_WindowsScreen;
  main->base.readCharacters = readCharacters_WindowsScreen;
  main->base.insertKey = insertKey_WindowsScreen;
  main->base.executeCommand = executeCommand_WindowsScreen;
  main->processParameters = processParameters_WindowsScreen;
  main->construct = construct_WindowsScreen;
  main->destruct = destruct_WindowsScreen;
}


[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Issue with inserting '@' at the command prompt.

[Corinna Vinschen]

On Aug 19 16:06, Samuel Thibault wrote:
> Corinna Vinschen, a écrit :
> > On Aug 19 15:14, Samuel Thibault wrote:
> > > Corinna Vinschen, le Fri 19 Aug 2011 13:50:19 +0200, a Ãcrit :
> > > > >   .wVirtualKeyCode = 0x630,
> > >
> > > Eergl, no, that should have been 0x30 here, our code does properly masks
> > > out the high part, I just missed that in our code.
> > 
> > And what about the control code?  It's a fixed 1 in your example,
> 
> That's only the example. 1 is obviously not hardcoded in the real source
> code, which I have attached (I just initially wanted to avoid you having
> to browse into the whole not-so-readable source ).
> 
> > but obviously it should be 6.
> 
> That's clearly not obvious from an altgr point of view: people use altgr
> to type '@', so it makes sense to simulate the hit of the right alt
> (i.e. altgr).

Typo on my part.  I meant 5, the combination of RIGHT_ALT_PRESSED and
RIGHT_CTRL_PRESSED.  But RIGHT/LEFT CTRL should be equivalent anyway,
as far as general typing is concerned.

> > > Err, do you mean LEFT_ALT_PRESSED here? Right alt is altgr in some
> > > keyboard layouts, which is precisely what people use to type '@' in
> > > the french layout, actually. E.g. LeftAlt-A and RightAlt-A (i.e.
> > 
> > I'm aware of this difference, so, no, that was a deliberate
> > RIGHT_ALT_PRESSED.
> 
> But for the cases when only alt is to be pressed, this simulates a right
> alt, which with e.g. the french layout is not the same as the left one.

Yes, just like the german one.  However, to the best of my knowledge
there's no printable unicode char which requires to press left-alt on
any such keyboard layout.  That's exactly what the AltGr == right-alt
key is for, isn't it?

> > However, this also works for me when using
> > LEFT_CTRL_PRESSED and LEFT_ALT_PRESSED in the conditionals above.
> 
> But it won't work with DOS applications (e.g. edit). That's precisely
> the reason why I added the special case.

Uh, ok, I see.  If you press AltGr on a keyboard layout which does not
distinguish Alt and AltGr, (english, for instance), the AltGr key only
emits a RIGHT_ALT_PRESSED control code.  On a keyboard layout which does
distinguish them, the AltGr key emits LEFT_CTRL_PRESSED | RIGHT_ALT_PRESSED.
So you need some CTRL_PRESSED to emit the correct INPUT_RECORD.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Issue with inserting '@' at the command prompt.

[Samuel Thibault]

Corinna Vinschen, le Fri 19 Aug 2011 17:08:41 +0200, a écrit :
> On Aug 19 16:06, Samuel Thibault wrote:
> > Corinna Vinschen, a écrit :
> > > On Aug 19 15:14, Samuel Thibault wrote:
> > > > Corinna Vinschen, le Fri 19 Aug 2011 13:50:19 +0200, a Ãcrit :
> > > > > >   .wVirtualKeyCode = 0x630,
> > > >
> > > > Eergl, no, that should have been 0x30 here, our code does properly masks
> > > > out the high part, I just missed that in our code.
> > > 
> > > And what about the control code?  It's a fixed 1 in your example,
> > 
> > That's only the example. 1 is obviously not hardcoded in the real source
> > code, which I have attached (I just initially wanted to avoid you having
> > to browse into the whole not-so-readable source ).
> > 
> > > but obviously it should be 6.
> > 
> > That's clearly not obvious from an altgr point of view: people use altgr
> > to type '@', so it makes sense to simulate the hit of the right alt
> > (i.e. altgr).
> 
> Typo on my part.  I meant 5, the combination of RIGHT_ALT_PRESSED and
> RIGHT_CTRL_PRESSED.

Well I understood the latter without even looking at the exact number
actually :)

> But RIGHT/LEFT CTRL should be equivalent anyway, as far as general
> typing is concerned.

CTRL, yes.

> > > > Err, do you mean LEFT_ALT_PRESSED here? Right alt is altgr in some
> > > > keyboard layouts, which is precisely what people use to type '@' in
> > > > the french layout, actually. E.g. LeftAlt-A and RightAlt-A (i.e.
> > > 
> > > I'm aware of this difference, so, no, that was a deliberate
> > > RIGHT_ALT_PRESSED.
> > 
> > But for the cases when only alt is to be pressed, this simulates a right
> > alt, which with e.g. the french layout is not the same as the left one.
> 
> Yes, just like the german one.  However, to the best of my knowledge
> there's no printable unicode char which requires to press left-alt on
> any such keyboard layout.

Yes, but there are shortcuts which use left-alt.

> That's exactly what the AltGr == right-alt key is for, isn't it?

For glyphs, yes.

For instance, alt-e would open an edition menu, while altgr-e prints the
euro symbol.

> > > However, this also works for me when using
> > > LEFT_CTRL_PRESSED and LEFT_ALT_PRESSED in the conditionals above.
> > 
> > But it won't work with DOS applications (e.g. edit). That's precisely
> > the reason why I added the special case.
> 
> Uh, ok, I see.  If you press AltGr on a keyboard layout which does not
> distinguish Alt and AltGr, (english, for instance), the AltGr key only
> emits a RIGHT_ALT_PRESSED control code.

Ok.

> On a keyboard layout which does
> distinguish them, the AltGr key emits LEFT_CTRL_PRESSED | RIGHT_ALT_PRESSED.

Ah. *that* is the part that I was missing :) I had assumed that
RIGHT_ALT meant altgr. So we'll indeed simply simulate control as well,
and it should work correctly.

Thanks!
Samuel

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Issue with inserting '@' at the command prompt.

[Corinna Vinschen]

On Aug 19 17:15, Samuel Thibault wrote:
> Corinna Vinschen, le Fri 19 Aug 2011 17:08:41 +0200, a écrit :
> > Yes, just like the german one.  However, to the best of my knowledge
> > there's no printable unicode char which requires to press left-alt on
> > any such keyboard layout.
> 
> Yes, but there are shortcuts which use left-alt.
> 
> > That's exactly what the AltGr == right-alt key is for, isn't it?
> 
> For glyphs, yes.
> 
> For instance, alt-e would open an edition menu, while altgr-e prints the
> euro symbol.

Sure, but for the shortcuts, the keyboard doesn't generate a valid
unicode.  I think we're in violent agreement, just using different
expressions for it.

> > Uh, ok, I see.  If you press AltGr on a keyboard layout which does not
> > distinguish Alt and AltGr, (english, for instance), the AltGr key only
> > emits a RIGHT_ALT_PRESSED control code.
> 
> Ok.
> 
> > On a keyboard layout which does
> > distinguish them, the AltGr key emits LEFT_CTRL_PRESSED | RIGHT_ALT_PRESSED.
> 
> Ah. *that* is the part that I was missing :) I had assumed that
> RIGHT_ALT meant altgr. So we'll indeed simply simulate control as well,
> and it should work correctly.
> 
> Thanks!

Glad I could help,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple