* read vs select on mouse events in console
@ 2022-12-22 14:55 Thomas Wolff
2022-12-23 3:24 ` Takashi Yano
0 siblings, 1 reply; 6+ messages in thread
From: Thomas Wolff @ 2022-12-22 14:55 UTC (permalink / raw)
To: cygwin-developers
[-- Attachment #1: Type: text/plain, Size: 994 bytes --]
When I added mouse notification support to the console long ago, I
deliberately introduced a function mouse_aware() which was common
between the console version of function read() and the console branch of
function select(), in order to make sure by design that inconsistencies
between them could never occur.
Now I noticed that by some change, mouse_aware() is not used anymore in
select() code.
This means that it could happen that either a mouse event would be
indicated by select() but then not be delivered by read(), so read()
could stall,
or (possibly, not sure) the other way round, a mouse event available for
delivery would not be recognized by select().
The attached test case is a rough demonstration of the issue. It uses
mouse mode DECSET 1000 which has a limited range of mouse coordinates.
Run it in a maximized console, click into the upper left area, then
further apart toward lower right, and eventually the program will stall
until another key is pressed.
Thomas
[-- Attachment #2: test-select.c --]
[-- Type: text/plain, Size: 1874 bytes --]
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <termios.h>
#include <stdio.h>
#include <sys/select.h>
#include <time.h>
#include <signal.h>
struct termios saved_tattr;
void
restore_tattr (void)
{
if (isatty (STDIN_FILENO))
tcsetattr (STDIN_FILENO, TCSANOW, &saved_tattr);
}
int
ready_select ()
{
struct timeval timeoutstru;
fd_set readfds;
int nfds;
static int rv = 0;
timeoutstru.tv_sec = 0;
timeoutstru.tv_usec = 800000;
FD_ZERO (& readfds);
FD_SET (STDIN_FILENO, & readfds);
nfds = select (STDIN_FILENO + 1, & readfds, 0, 0, & timeoutstru);
printf ("(%d)", nfds);
fflush (stdout);
return nfds;
}
int
main (void)
{
if (isatty (STDIN_FILENO)) {
struct termios tattr;
tcgetattr (STDIN_FILENO, &saved_tattr);
tattr = saved_tattr;
/*
*/
tattr.c_iflag &= ~(IGNBRK|BRKINT|PARMRK|ISTRIP|INLCR|IGNCR|ICRNL|IXON);
tattr.c_oflag &= ~OPOST;
tattr.c_cflag &= ~(CSIZE|PARENB);
tattr.c_cflag |= CS8;
tattr.c_lflag &= ~(ECHO|ECHONL|ICANON|ISIG|IEXTEN);
/* use miminal change for test case: */
tattr.c_lflag &= ~(ICANON);
tcsetattr (STDIN_FILENO, TCSAFLUSH, &tattr);
atexit (restore_tattr);
}
setbuf (stdout, 0);
// printf ("\033[?1000h\033[?1006h\033[?1004h");
printf ("\033[?1000h\033[?1004h");
while (1) {
unsigned char c;
int res;
while (! ready_select ()) {
}
res = read (STDIN_FILENO, & c, 1);
if (c == '\x04') {
break;
}
switch (c & 0xFF) {
case 0x00 ... 0x1f: putchar ('^'); putchar (c + 0x40);
if (c == '\r') printf ("\r\n");
break;
case 0x7f: putchar ('^'); putchar ('?'); break;
case 0x80 ... 0xFF: printf ("\\x%2X", c); break;
default: putchar (c);
}
fflush (stdout);
}
printf ("\033[?1000l\033[?1004l\r\nbye\r\n");
return 0;
}
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: read vs select on mouse events in console
2022-12-22 14:55 read vs select on mouse events in console Thomas Wolff
@ 2022-12-23 3:24 ` Takashi Yano
2022-12-23 9:08 ` Thomas Wolff
0 siblings, 1 reply; 6+ messages in thread
From: Takashi Yano @ 2022-12-23 3:24 UTC (permalink / raw)
To: cygwin-developers
Hi Thomas,
On Thu, 22 Dec 2022 15:55:01 +0100
Thomas Wolff wrote:
> When I added mouse notification support to the console long ago, I
> deliberately introduced a function mouse_aware() which was common
> between the console version of function read() and the console branch of
> function select(), in order to make sure by design that inconsistencies
> between them could never occur.
> Now I noticed that by some change, mouse_aware() is not used anymore in
> select() code.
> This means that it could happen that either a mouse event would be
> indicated by select() but then not be delivered by read(), so read()
> could stall,
> or (possibly, not sure) the other way round, a mouse event available for
> delivery would not be recognized by select().
> The attached test case is a rough demonstration of the issue. It uses
> mouse mode DECSET 1000 which has a limited range of mouse coordinates.
> Run it in a maximized console, click into the upper left area, then
> further apart toward lower right, and eventually the program will stall
> until another key is pressed.
mouse_aware() is called from process_input_message(). Currently,
both read() and select() call process_input_message(). So,
mouse_aware() is processed in both read() and select(), I think.
Therefore, if mouse event has some problem, the cause should be
something another.
Could you please explain about your test case more detail a bit?
What are the expected behavior and the current behavior?
I tried:
1) Maximize command prompt.
2) Start \cygwin64\bin\bash -l
3) Start your test case.
4) Then, "(0)" is displayed every one second.
5) If push down mouse left button at top left corner, some message is shown.
6) Another message is shown when release mouse left button.
7) Move mouse cursor to bottom right corner.
8) Clicking mouse does not generate any message.
9) "(0)" is still displayed every one second.
Is this different from your observation? Or do you expect
different behavior?
--
Takashi Yano <takashi.yano@nifty.ne.jp>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: read vs select on mouse events in console
2022-12-23 3:24 ` Takashi Yano
@ 2022-12-23 9:08 ` Thomas Wolff
2022-12-23 10:19 ` Takashi Yano
0 siblings, 1 reply; 6+ messages in thread
From: Thomas Wolff @ 2022-12-23 9:08 UTC (permalink / raw)
To: cygwin-developers
Hi Takashi
Am 23.12.2022 um 04:24 schrieb Takashi Yano:
> Hi Thomas,
>
> On Thu, 22 Dec 2022 15:55:01 +0100
> Thomas Wolff wrote:
>> When I added mouse notification support to the console long ago, I
>> deliberately introduced a function mouse_aware() which was common
>> between the console version of function read() and the console branch of
>> function select(), in order to make sure by design that inconsistencies
>> between them could never occur.
>> Now I noticed that by some change, mouse_aware() is not used anymore in
>> select() code.
>> This means that it could happen that either a mouse event would be
>> indicated by select() but then not be delivered by read(), so read()
>> could stall,
>> or (possibly, not sure) the other way round, a mouse event available for
>> delivery would not be recognized by select().
>> The attached test case is a rough demonstration of the issue. It uses
>> mouse mode DECSET 1000 which has a limited range of mouse coordinates.
>> Run it in a maximized console, click into the upper left area, then
>> further apart toward lower right, and eventually the program will stall
>> until another key is pressed.
> mouse_aware() is called from process_input_message(). Currently,
> both read() and select() call process_input_message(). So,
> mouse_aware() is processed in both read() and select(), I think.
>
> Therefore, if mouse event has some problem, the cause should be
> something another.
>
> Could you please explain about your test case more detail a bit?
> What are the expected behavior and the current behavior?
>
> I tried:
> 1) Maximize command prompt.
> 2) Start \cygwin64\bin\bash -l
> 3) Start your test case.
> 4) Then, "(0)" is displayed every one second.
> 5) If push down mouse left button at top left corner, some message is shown.
> 6) Another message is shown when release mouse left button.
> 7) Move mouse cursor to bottom right corner.
> 8) Clicking mouse does not generate any message.
> 9) "(0)" is still displayed every one second.
>
> Is this different from your observation? Or do you expect different behavior?
I see different behavior indeed; no further output of (0) and Windows
display its message to make a mouse selection in the title bar.
The purpose of the test program is to check whether select() reports
something available, then read it to actually verify and display the input.
OK, I overlooked the nesting in process_input_message, so maybe it's OK,
but then still my observation of the test case is mysterious. I'll look
further into it, but not so soon...
Thanks
Thomas
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: read vs select on mouse events in console
2022-12-23 9:08 ` Thomas Wolff
@ 2022-12-23 10:19 ` Takashi Yano
2022-12-23 12:03 ` Thomas Wolff
0 siblings, 1 reply; 6+ messages in thread
From: Takashi Yano @ 2022-12-23 10:19 UTC (permalink / raw)
To: cygwin-developers
On Fri, 23 Dec 2022 10:08:20 +0100
Thomas Wolff wrote:
> Am 23.12.2022 um 04:24 schrieb Takashi Yano:
> > Hi Thomas,
> >
> > On Thu, 22 Dec 2022 15:55:01 +0100
> > Thomas Wolff wrote:
> >> When I added mouse notification support to the console long ago, I
> >> deliberately introduced a function mouse_aware() which was common
> >> between the console version of function read() and the console branch of
> >> function select(), in order to make sure by design that inconsistencies
> >> between them could never occur.
> >> Now I noticed that by some change, mouse_aware() is not used anymore in
> >> select() code.
> >> This means that it could happen that either a mouse event would be
> >> indicated by select() but then not be delivered by read(), so read()
> >> could stall,
> >> or (possibly, not sure) the other way round, a mouse event available for
> >> delivery would not be recognized by select().
> >> The attached test case is a rough demonstration of the issue. It uses
> >> mouse mode DECSET 1000 which has a limited range of mouse coordinates.
> >> Run it in a maximized console, click into the upper left area, then
> >> further apart toward lower right, and eventually the program will stall
> >> until another key is pressed.
> > mouse_aware() is called from process_input_message(). Currently,
> > both read() and select() call process_input_message(). So,
> > mouse_aware() is processed in both read() and select(), I think.
> >
> > Therefore, if mouse event has some problem, the cause should be
> > something another.
> >
> > Could you please explain about your test case more detail a bit?
> > What are the expected behavior and the current behavior?
> >
> > I tried:
> > 1) Maximize command prompt.
> > 2) Start \cygwin64\bin\bash -l
> > 3) Start your test case.
> > 4) Then, "(0)" is displayed every one second.
> > 5) If push down mouse left button at top left corner, some message is shown.
> > 6) Another message is shown when release mouse left button.
> > 7) Move mouse cursor to bottom right corner.
> > 8) Clicking mouse does not generate any message.
> > 9) "(0)" is still displayed every one second.
> >
> > Is this different from your observation? Or do you expect different behavior?
> I see different behavior indeed; no further output of (0) and Windows
> display its message to make a mouse selection in the title bar.
Ah, that may be due to "Quick Edit Mode". It seems that the
"Quick Edit Mode" is disabled in the DECSET 1000 range, however,
it is enabled outside of the range. So, clicking mouse outside of
the range triggers the "Quick Edit Mode" then program is suspended.
If you uncheck the "Quick Edit Mode" setting, the problem will
probably disappear. Please try.
--
Takashi Yano <takashi.yano@nifty.ne.jp>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: read vs select on mouse events in console
2022-12-23 10:19 ` Takashi Yano
@ 2022-12-23 12:03 ` Thomas Wolff
2022-12-24 11:37 ` Takashi Yano
0 siblings, 1 reply; 6+ messages in thread
From: Thomas Wolff @ 2022-12-23 12:03 UTC (permalink / raw)
To: cygwin-developers
Am 23.12.2022 um 11:19 schrieb Takashi Yano:
> On Fri, 23 Dec 2022 10:08:20 +0100
> Thomas Wolff wrote:
>> Am 23.12.2022 um 04:24 schrieb Takashi Yano:
>>> Hi Thomas,
>>>
>>> On Thu, 22 Dec 2022 15:55:01 +0100
>>> Thomas Wolff wrote:
>>>> When I added mouse notification support to the console long ago, I
>>>> deliberately introduced a function mouse_aware() which was common
>>>> between the console version of function read() and the console branch of
>>>> function select(), in order to make sure by design that inconsistencies
>>>> between them could never occur.
>>>> Now I noticed that by some change, mouse_aware() is not used anymore in
>>>> select() code.
>>>> This means that it could happen that either a mouse event would be
>>>> indicated by select() but then not be delivered by read(), so read()
>>>> could stall,
>>>> or (possibly, not sure) the other way round, a mouse event available for
>>>> delivery would not be recognized by select().
>>>> The attached test case is a rough demonstration of the issue. It uses
>>>> mouse mode DECSET 1000 which has a limited range of mouse coordinates.
>>>> Run it in a maximized console, click into the upper left area, then
>>>> further apart toward lower right, and eventually the program will stall
>>>> until another key is pressed.
>>> mouse_aware() is called from process_input_message(). Currently,
>>> both read() and select() call process_input_message(). So,
>>> mouse_aware() is processed in both read() and select(), I think.
>>>
>>> Therefore, if mouse event has some problem, the cause should be
>>> something another.
>>>
>>> Could you please explain about your test case more detail a bit?
>>> What are the expected behavior and the current behavior?
>>>
>>> I tried:
>>> 1) Maximize command prompt.
>>> 2) Start \cygwin64\bin\bash -l
>>> 3) Start your test case.
>>> 4) Then, "(0)" is displayed every one second.
>>> 5) If push down mouse left button at top left corner, some message is shown.
>>> 6) Another message is shown when release mouse left button.
>>> 7) Move mouse cursor to bottom right corner.
>>> 8) Clicking mouse does not generate any message.
>>> 9) "(0)" is still displayed every one second.
>>>
>>> Is this different from your observation? Or do you expect different behavior?
>> I see different behavior indeed; no further output of (0) and Windows
>> display its message to make a mouse selection in the title bar.
> Ah, that may be due to "Quick Edit Mode". It seems that the
> "Quick Edit Mode" is disabled in the DECSET 1000 range, however,
> it is enabled outside of the range. So, clicking mouse outside of
> the range triggers the "Quick Edit Mode" then program is suspended.
>
> If you uncheck the "Quick Edit Mode" setting, the problem will probably disappear. Please try.
Right, but how does Windows notice about mouse events processed by
cygwin, so it enters quick edit mode or not?
Still mysterious.
Thanks
Thomas
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: read vs select on mouse events in console
2022-12-23 12:03 ` Thomas Wolff
@ 2022-12-24 11:37 ` Takashi Yano
0 siblings, 0 replies; 6+ messages in thread
From: Takashi Yano @ 2022-12-24 11:37 UTC (permalink / raw)
To: cygwin-developers
On Fri, 23 Dec 2022 13:03:06 +0100
Thomas Wolff wrote:
> Am 23.12.2022 um 11:19 schrieb Takashi Yano:
> > On Fri, 23 Dec 2022 10:08:20 +0100
> > Thomas Wolff wrote:
> >> I see different behavior indeed; no further output of (0) and Windows
> >> display its message to make a mouse selection in the title bar.
> > Ah, that may be due to "Quick Edit Mode". It seems that the
> > "Quick Edit Mode" is disabled in the DECSET 1000 range, however,
> > it is enabled outside of the range. So, clicking mouse outside of
> > the range triggers the "Quick Edit Mode" then program is suspended.
> >
> > If you uncheck the "Quick Edit Mode" setting, the problem will probably disappear. Please try.
> Right, but how does Windows notice about mouse events processed by
> cygwin, so it enters quick edit mode or not?
> Still mysterious.
Actually, mouse_aware() is not used after Win10 1703.
Mouse event is translated to ESC sequence by Windows.
ENABLE_VIRTUAL_TERMINAL_INPUT flag does that. Therefore,
Windows knows whther the mouse event is processed or not.
mouse_aware() works only if the system is before win10
1607 or legacy console mode is enabled.
--
Takashi Yano <takashi.yano@nifty.ne.jp>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-12-24 11:37 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-12-22 14:55 read vs select on mouse events in console Thomas Wolff
2022-12-23 3:24 ` Takashi Yano
2022-12-23 9:08 ` Thomas Wolff
2022-12-23 10:19 ` Takashi Yano
2022-12-23 12:03 ` Thomas Wolff
2022-12-24 11:37 ` Takashi Yano
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).