[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

Re: Emacs and removal of CYGWIN=tty

[Corinna Vinschen]

On Jul  6 09:04, Lars Bjørndal wrote:
> Corinna Vinschen writes:
> 
> > On Jun 30 13:54, Samuel Thibault wrote:
> >> Ken Brown, le Thu 30 Jun 2011 07:49:42 -0400, a écrit :
> >> > On 6/30/2011 3:58 AM, Lars Bjørndal wrote:
> >> > >I've heard that the value of the CYGWIN environment variable 'tty' will
> >> > >be unsupported for the next release of cygwin. I use emacs a lot from within
> >> > >cygwin, and if not CYTWIN=tty is set prior to starting bash, the control-c
> >> > >character outputs control-g. C-c, c-x is therefore wrongly interpreted
> >> > >by emacs. Is there other ways to get emacs works as expected, if the
> >> > >variable is removed?
> >> > 
> >> > The problem only occurs in a Windows console, such as the one you get by
> >> > using the Cygwin desktop shortcut.  Use a different terminal emulator, such
> >> > as mintty, instead.
> >> 
> >> This is not an option, as mintty is not accessible from brltty.
> >
> > I just applied a patch to CVS which makes Emacs' Ctrl-x Ctrl-c work as
> > expected in the console.  This should work with other applications as
> > well which set the termios IGNBRK flag.
> 
> I downloaded the 20110705 version of cygwin1.dll, and replaced my
> original one. Now, BRLTTY doesn't work. It starts, but the braille
> display isn't updated/refreshed. I confirmed that Emacs exits with c-x,
> c-c.

What I don't get from your reply is if you are comparing the latest
snapshot against 1.7.9 with CYGWIN=tty mode, or if you're comparing
to another snapshot in default console mode.  Without this information
it's rather tricky to see where the problem might come from.

We're trying to make the console window work so that the tty option is
not necessary, but we can't debug stuff we can't use.  So this might
have to be debugged by a brltty developer.

I can't believe it's due to my change.  The only relevant difference
between 20110705 and the 20110624 snapshot is that Window's Ctrl-C
handling is now switched off if an applicaton sets the IGNBRK termios
attribute.

The problem is to know how the braille display is updated and what's
missing in the console tty emulation 


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: Emacs and removal of CYGWIN=tty

[Lars Bjørndal]

[Corinna Vinschen]

> What I don't get from your reply is if you are comparing the latest
> snapshot against 1.7.9 with CYGWIN=tty mode, or if you're comparing
> to another snapshot in default console mode.

Oh, I'm sorry. Tested against the 1.7.9 version.

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: Emacs and removal of CYGWIN=tty

[Corinna Vinschen]

On Jul  6 10:03, Lars Bjørndal wrote:
> [Corinna Vinschen]
> 
> > What I don't get from your reply is if you are comparing the latest
> > snapshot against 1.7.9 with CYGWIN=tty mode, or if you're comparing
> > to another snapshot in default console mode.
> 
> Oh, I'm sorry. Tested against the 1.7.9 version.

In CYGWIN=tty or CYGWIN=notty mode?


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: Emacs and removal of CYGWIN=tty

[Lars Bjørndal]

[Corinna]

> On Jul  6 10:03, Lars Bjørndal wrote:
>> [Corinna Vinschen]
>> 
>> > What I don't get from your reply is if you are comparing the latest
>> > snapshot against 1.7.9 with CYGWIN=tty mode, or if you're comparing
>> > to another snapshot in default console mode.
>> 
>> Oh, I'm sorry. Tested against the 1.7.9 version.
>
> In CYGWIN=tty or CYGWIN=notty mode?

In both environments, BRLTTY works with 1.7.9.

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: Emacs and removal of CYGWIN=tty

[Christopher Faylor]

On Wed, Jul 06, 2011 at 01:08:26PM +0200, Lars Bj?rndal wrote:
>[Corinna]
>
>> On Jul  6 10:03, Lars Bj?rndal wrote:
>>> [Corinna Vinschen]
>>> 
>>> > What I don't get from your reply is if you are comparing the latest
>>> > snapshot against 1.7.9 with CYGWIN=tty mode, or if you're comparing
>>> > to another snapshot in default console mode.
>>> 
>>> Oh, I'm sorry. Tested against the 1.7.9 version.
>>
>> In CYGWIN=tty or CYGWIN=notty mode?
>
>In both environments, BRLTTY works with 1.7.9.

So are you claiming that Corinna's change caused the problem or did you
see this with other snapshots?

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: Emacs and removal of CYGWIN=tty

[Lars Bjørndal]

Christopher Faylor writes:

> On Wed, Jul 06, 2011 at 01:08:26PM +0200, Lars Bj?rndal wrote:
>>[Corinna]
>>
>>> On Jul  6 10:03, Lars Bj?rndal wrote:
>>>> [Corinna Vinschen]
>>>> 
>>>> > What I don't get from your reply is if you are comparing the latest
>>>> > snapshot against 1.7.9 with CYGWIN=tty mode, or if you're comparing
>>>> > to another snapshot in default console mode.
>>>> 
>>>> Oh, I'm sorry. Tested against the 1.7.9 version.
>>>
>>> In CYGWIN=tty or CYGWIN=notty mode?
>>
>>In both environments, BRLTTY works with 1.7.9.
>
> So are you claiming that Corinna's change caused the problem or did you
> see this with other snapshots?

I did a test with 20110624, and BRLTTY doesn't work there either. Sorry
for the confusion. Corinnas patch looks perfect.

Let's wait for Samuel to comment, since he is contributing to the BRLTTY
development team.

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

brltty problems with recent snapshots (was Re: Emacs and removal of CYGWIN=tty)

[Christopher Faylor]

On Thu, Jul 07, 2011 at 09:31:28AM +0200, Lars Bj?rndal wrote:
>Christopher Faylor writes:
>
>> On Wed, Jul 06, 2011 at 01:08:26PM +0200, Lars Bj?rndal wrote:
>>>[Corinna]
>>>
>>>> On Jul  6 10:03, Lars Bj?rndal wrote:
>>>>> [Corinna Vinschen]
>>>>> 
>>>>> > What I don't get from your reply is if you are comparing the latest
>>>>> > snapshot against 1.7.9 with CYGWIN=tty mode, or if you're comparing
>>>>> > to another snapshot in default console mode.
>>>>> 
>>>>> Oh, I'm sorry. Tested against the 1.7.9 version.
>>>>
>>>> In CYGWIN=tty or CYGWIN=notty mode?
>>>
>>>In both environments, BRLTTY works with 1.7.9.
>>
>> So are you claiming that Corinna's change caused the problem or did you
>> see this with other snapshots?
>
>I did a test with 20110624, and BRLTTY doesn't work there either. Sorry
>for the confusion. Corinnas patch looks perfect.
>
>Let's wait for Samuel to comment, since he is contributing to the BRLTTY
>development team.

Since neither Corinna nor I know how to run brltty we really need some
insight here.  strace output for working and nonworking cases would be
useful, I guess.  Please be sure to use the most recent (i.e., at least
2011-07-10) snapshot when testing.

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: brltty problems with recent snapshots (was Re: Emacs and removal of CYGWIN=tty)

[Samuel Thibault]

Christopher Faylor, le Sun 10 Jul 2011 20:08:43 -0400, a écrit :
> On Thu, Jul 07, 2011 at 09:31:28AM +0200, Lars Bj?rndal wrote:
> >Christopher Faylor writes:
> >
> >> On Wed, Jul 06, 2011 at 01:08:26PM +0200, Lars Bj?rndal wrote:
> >>>[Corinna]
> >>>
> >>>> On Jul  6 10:03, Lars Bj?rndal wrote:
> >>>>> [Corinna Vinschen]
> >>>>> 
> >>>>> > What I don't get from your reply is if you are comparing the latest
> >>>>> > snapshot against 1.7.9 with CYGWIN=tty mode, or if you're comparing
> >>>>> > to another snapshot in default console mode.
> >>>>> 
> >>>>> Oh, I'm sorry. Tested against the 1.7.9 version.
> >>>>
> >>>> In CYGWIN=tty or CYGWIN=notty mode?
> >>>
> >>>In both environments, BRLTTY works with 1.7.9.
> >>
> >> So are you claiming that Corinna's change caused the problem or did you
> >> see this with other snapshots?
> >
> >I did a test with 20110624, and BRLTTY doesn't work there either. Sorry
> >for the confusion. Corinnas patch looks perfect.
> >
> >Let's wait for Samuel to comment, since he is contributing to the BRLTTY
> >development team.
> 
> Since neither Corinna nor I know how to run brltty we really need some
> insight here.

I'm away at LSM at the moment, so I don't have the time to investigate.
However, just run

brltty -b xw

and it'll open a window at the top of the screen, which is supposed to
display your shell prompt and what you are typing.

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: brltty problems with recent snapshots (was Re: Emacs and removal of CYGWIN=tty)

[Christopher Faylor]

On Mon, Jul 11, 2011 at 02:11:14AM +0200, Samuel Thibault wrote:
>Christopher Faylor, le Sun 10 Jul 2011 20:08:43 -0400, a ?crit :
>> On Thu, Jul 07, 2011 at 09:31:28AM +0200, Lars Bj?rndal wrote:
>> >Christopher Faylor writes:
>> >
>> >> On Wed, Jul 06, 2011 at 01:08:26PM +0200, Lars Bj?rndal wrote:
>> >>>[Corinna]
>> >>>
>> >>>> On Jul  6 10:03, Lars Bj?rndal wrote:
>> >>>>> [Corinna Vinschen]
>> >>>>> 
>> >>>>> > What I don't get from your reply is if you are comparing the latest
>> >>>>> > snapshot against 1.7.9 with CYGWIN=tty mode, or if you're comparing
>> >>>>> > to another snapshot in default console mode.
>> >>>>> 
>> >>>>> Oh, I'm sorry. Tested against the 1.7.9 version.
>> >>>>
>> >>>> In CYGWIN=tty or CYGWIN=notty mode?
>> >>>
>> >>>In both environments, BRLTTY works with 1.7.9.
>> >>
>> >> So are you claiming that Corinna's change caused the problem or did you
>> >> see this with other snapshots?
>> >
>> >I did a test with 20110624, and BRLTTY doesn't work there either. Sorry
>> >for the confusion. Corinnas patch looks perfect.
>> >
>> >Let's wait for Samuel to comment, since he is contributing to the BRLTTY
>> >development team.
>> 
>> Since neither Corinna nor I know how to run brltty we really need some
>> insight here.
>
>I'm away at LSM at the moment, so I don't have the time to investigate.
>However, just run
>
>brltty -b xw
>
>and it'll open a window at the top of the screen, which is supposed to
>display your shell prompt and what you are typing.

Thanks.

I don't see any difference in behavior between Cygwin 1.7.9, the most
recent snapshot, or the 20110629 snapshot.  I did have to run rebaseall
to get everything working though.

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: brltty problems with recent snapshots (was Re: Emacs and removal of CYGWIN=tty)

[Samuel Thibault]

Christopher Faylor, le Sun 10 Jul 2011 20:31:22 -0400, a écrit :
> On Mon, Jul 11, 2011 at 02:11:14AM +0200, Samuel Thibault wrote:
> >just run
> >
> >brltty -b xw
> >
> >and it'll open a window at the top of the screen, which is supposed to
> >display your shell prompt and what you are typing.
> 
> Thanks.
> 
> I don't see any difference in behavior between Cygwin 1.7.9, the most
> recent snapshot, or the 20110629 snapshot.

What behavior do you see?  Does the window show you the text as you type
it in the cygwin console?

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: brltty problems with recent snapshots (was Re: Emacs and removal of CYGWIN=tty)

[Christopher Faylor]

On Mon, Jul 11, 2011 at 04:44:49PM +0200, Samuel Thibault wrote:
>Christopher Faylor, le Sun 10 Jul 2011 20:31:22 -0400, a ?crit :
>> On Mon, Jul 11, 2011 at 02:11:14AM +0200, Samuel Thibault wrote:
>> >just run
>> >
>> >brltty -b xw
>> >
>> >and it'll open a window at the top of the screen, which is supposed to
>> >display your shell prompt and what you are typing.
>> 
>> Thanks.
>> 
>> I don't see any difference in behavior between Cygwin 1.7.9, the most
>> recent snapshot, or the 20110629 snapshot.
>
>What behavior do you see?  Does the window show you the text as you type
>it in the cygwin console?

Yes.

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

Christopher Faylor writes:

> On Mon, Jul 11, 2011 at 04:44:49PM +0200, Samuel Thibault wrote:
>>Christopher Faylor, le Sun 10 Jul 2011 20:31:22 -0400, a ?crit :
>>> On Mon, Jul 11, 2011 at 02:11:14AM +0200, Samuel Thibault wrote:
>>> >just run
>>> >
>>> >brltty -b xw
>>> >
>>> >and it'll open a window at the top of the screen, which is supposed to
>>> >display your shell prompt and what you are typing.
>>> 
>>> Thanks.
>>> 
>>> I don't see any difference in behavior between Cygwin 1.7.9, the most
>>> recent snapshot, or the 20110629 snapshot.
>>
>>What behavior do you see?  Does the window show you the text as you type
>>it in the cygwin console?
>
> Yes.

Let me explain a bit more what happens here.

(I've tried to also run rebaseall, but with no different result.)

BRLTTY starts with a recent cygwin1.dll,, and the initial startup
message is displayed on my braille display. Normally, it should be
possible to press a scrolling key to make the message disappear, but
nothing happens. If I, however, press the BRLTTY paste keys, the
display is updated with the text at the current screen line. If the
current line is a terminal prompt, and I type some text, the display
isn't updated until I again press the BRLTTY paste. If I press the
scroll up key for instance four times, and then press the paste keys, I
can read the content of that line.

I'm using a Handy Tech Modular Evolution braille display, and so the ht
driver in BRLTTY are used. The problem may be related to the braille
driver in BRLTTY, I don't know.

Hope this helps.

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 11 21:12, Lars Bjørndal wrote:
> Christopher Faylor writes:
> 
> > On Mon, Jul 11, 2011 at 04:44:49PM +0200, Samuel Thibault wrote:
> >>Christopher Faylor, le Sun 10 Jul 2011 20:31:22 -0400, a ?crit :
> >>> On Mon, Jul 11, 2011 at 02:11:14AM +0200, Samuel Thibault wrote:
> >>> >just run
> >>> >
> >>> >brltty -b xw
> >>> >
> >>> >and it'll open a window at the top of the screen, which is supposed to
> >>> >display your shell prompt and what you are typing.
> >>> 
> >>> Thanks.
> >>> 
> >>> I don't see any difference in behavior between Cygwin 1.7.9, the most
> >>> recent snapshot, or the 20110629 snapshot.
> >>
> >>What behavior do you see?  Does the window show you the text as you type
> >>it in the cygwin console?
> >
> > Yes.
> 
> Let me explain a bit more what happens here.
> 
> (I've tried to also run rebaseall, but with no different result.)
> 
> BRLTTY starts with a recent cygwin1.dll,, and the initial startup
> message is displayed on my braille display. Normally, it should be
> possible to press a scrolling key to make the message disappear, but
> nothing happens. If I, however, press the BRLTTY paste keys, the
> display is updated with the text at the current screen line. If the
> current line is a terminal prompt, and I type some text, the display
> isn't updated until I again press the BRLTTY paste. If I press the
> scroll up key for instance four times, and then press the paste keys, I
> can read the content of that line.

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.


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

[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?

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: brltty problems with recent snapshots

[Samuel Thibault]

Lars Bjørndal, le Wed 13 Jul 2011 11:06:46 +0200, a écrit :
> > 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.

Ok, so the tty layer of cygwin is involved indeed.

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

Ok, I'll let cygwin people have a look at the changelog.

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: brltty problems with recent snapshots

[Christopher Faylor]

On Wed, Jul 13, 2011 at 03:05:41PM +0200, Samuel Thibault wrote:
>Lars Bj?rndal, le Wed 13 Jul 2011 11:06:46 +0200, a ?crit :
>> > 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.
>
>Ok, so the tty layer of cygwin is involved indeed.

Nope. "tty layer" != "com port".

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: brltty problems with recent snapshots

[Samuel Thibault]

Christopher Faylor, le Wed 13 Jul 2011 11:30:43 -0400, a écrit :
> On Wed, Jul 13, 2011 at 03:05:41PM +0200, Samuel Thibault wrote:
> >Ok, so the tty layer of cygwin is involved indeed.
> 
> Nope. "tty layer" != "com port".

Ah, in cygwin, then. Ok.

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