From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) by sourceware.org (Postfix) with ESMTPS id 7CE803858D1E for ; Fri, 23 Dec 2022 12:03:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7CE803858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=towo.net Authentication-Results: sourceware.org; spf=none smtp.mailfrom=towo.net Received: from [192.168.178.72] ([91.65.247.133]) by mrelayeu.kundenserver.de (mreue106 [212.227.15.183]) with ESMTPSA (Nemesis) id 1Mg6qO-1ofNox0J5S-00hggq for ; Fri, 23 Dec 2022 13:03:01 +0100 Message-ID: Date: Fri, 23 Dec 2022 13:03:06 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: read vs select on mouse events in console To: cygwin-developers@cygwin.com References: <20221223122408.e2412a32f5ab1bca115a8ae6@nifty.ne.jp> <17a52f3b-c8c4-b4dc-c852-93d5fcb22888@towo.net> <20221223191946.4b6dd028ec5309c228867b87@nifty.ne.jp> From: Thomas Wolff In-Reply-To: <20221223191946.4b6dd028ec5309c228867b87@nifty.ne.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:xfP/cF5JAoGNt8VOJysCCpqo0TR3QOsyAutFtB1iHDeMD8ecBPc 7az9AP9XjJ/6NWalvL4vVUWKwq18ktdbYp7SGapUarV20fkYJrLTMaRtKrooS0RmqJZhDPo xYkNkMUR+KEaNTQV3OeLF+VkEHdiNH+FiJEmpydo1AGpyyX/DaTuodXkZBxlPVo65WPCGXL XqoqQ4TWeKvu4DskFGMrQ== UI-OutboundReport: notjunk:1;M01:P0:YGzNV3Bpzds=;hkoz5376RU3U1RR+BLuUAKPlIre pPW3lEB+JwM+beVrvepCjQRKMljs2Y8b0YOz0HInTRGY5Kd1Bz+d+HUXGAxdPBIkTDHQTKAec uJAU5Jl16gKspDmpAwmFXF/UQhgKR5DPe7ViUersEDw37FiR9m0vK4Wdzq74ZmO6CDHt6YyRC OSwXNnZY2V1PVNVm4+8BGaCTbLhrYl8CB6wlt3/HMSCSKtL8/J9Itd0Qll17RcTYjMwPQfFgF Znboms1wNGPKHz/56lk8IUympIhw3qZPJ5s6tfV4hJdynF9XWrShACw+ZS9y9/lrwbmRFwq0l QzzRxbKGIMdXYGUFWRV774t95mXFru+9au0KIMSoz+hjOaGXw+maO77VyPdgjXvUHZ79dW4NX fKhe5vhzrQ5oH7GTc9dyO8TKOVPkeBJncc9AC27/ycS1rtE1IUN5IPDyBGTX4ioevnbiQqmU8 oLahMyyJ0wQymXmBjrsxIwkC7xpshtcGh/Jj0pJLCD3aTA5VrTMH2I92gTAjdZo3dxmQobEqC dWbRBK6mnPqANCfxd6cZnAI2eqalQQ/Z5umV7uZEpcBxGb4TVFZiOwgEnztIgH/Lwo0IBPGfA ZzOsdSQiTGwXU0AfdaqOeLbn1/xSUQ7gKsLu+//CdFo5C0H98srotmjPeqQ9fu+R7jPEjwfnZ ZHtemcjLeqxdlZlK/weGQ8SPwuPxb+RnyJri5//zdQ== X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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