This is the mail archive of the
cygwin-patches
mailing list for the Cygwin project.
Re: console: new mouse modes, request/response attempt
On Mon, Apr 02, 2012 at 09:50:17PM +0200, Thomas Wolff wrote:
>Am 02.04.2012 20:50, schrieb Christopher Faylor:
>> On Mon, Apr 02, 2012 at 08:46:31PM +0200, Thomas Wolff wrote:
>>> This patch includes 2 things (to be fixed and separated anyway; change
>>> log still missing) for discussion:
>>> * mouse modes 6 and 15 (numeric mouse coordinates)
>>> * semi-fix for missing terminal status responses
>>> The fix tries to detect the proper fhandler for CONIO, which is then
>>> used to queue the response.
>>> Problem 1: I am not sure whether this detection is proper in all cases,
>>> what e.g. if /dev/tty is reopened etc. I don't know where else a
>>> relation between the handles for CONIN and CONOUT might be established.
>>> Problem 2: While the response reaches the application with this patch,
>>> only the first byte is read right-away. Further bytes are delayed until
>>> other input is becoming present (typing a key). This may (or may not) be
>>> related to other issues with select(), so maybe it's worth analyzing it.
>>>
>>> Thomas
>>> diff -rup sav/fhandler.h ./fhandler.h
>>> --- sav/fhandler.h 2012-04-01 19:46:04.000000000 +0200
>>> +++ ./fhandler.h 2012-04-02 15:47:22.385727000 +0200
>>> @@ -1282,8 +1282,11 @@ class dev_console
>>>
>>> bool insert_mode;
>>> int use_mouse;
>>> + bool ext_mouse_mode6;
>>> + bool ext_mouse_mode15;
>>> bool use_focus;
>>> bool raw_win32_keyboard_mode;
>>> + fhandler_console * fh_tty;
>>>
>>> inline UINT get_console_cp ();
>>> DWORD con_to_str (char *d, int dlen, WCHAR w);
>>> diff -rup sav/fhandler_console.cc ./fhandler_console.cc
>>> --- sav/fhandler_console.cc 2012-04-02 00:28:55.000000000 +0200
>>> +++ ./fhandler_console.cc 2012-04-02 18:02:26.004016200 +0200
>>> @@ -139,6 +139,8 @@ fhandler_console::set_unit ()
>>> if (shared_console_info)
>>> {
>>> fh_devices this_unit = dev ();
>>> + if (this_unit == FH_TTY)
>>> + dev_state.fh_tty = this;
>> You *definitely* just can't squirrel away a pointer to a random fhandler
>> here.
>Not sure what exactly you mean. Is "== FH_TTY" a random selection? I
>traced (again) that during setup of cygwin there are 80 fhandler objects
>created. Only one of them matches this criteria (and none the others,
>e.g. "== FH_CONIO". So I made a guess, and as I said, it works, kind of...
`this' is a pointer to a fhandler. You can't just store it in a static
location and use it whenever you want later. You have no idea how long
this fhandler will be around. What happens if it's destroyed?
>> Do we really care about console mode that much now that mintty is the
>> default?
>
>Maybe not, but the fact that it works partially but subsequent
>characters are postponed resembles the other problem that I have just reported
>tocygwin@cygwin.com, which makes me wonder whether there is one common problem.
>
>
>Also when I originally tweaked the mouse code, I couldn't completely
>understand the code in select.cc (only got it to work by pattern
>matching code...). I did notice, however, that select and read were
>inconsistent in the sense that an application having called select()
>with a positive response may not be able to get a byte with a subsequent
>read(), because criteria were re-evaluated and could have different
>results (esp. in border cases). I did fix it by strictly applying the
>same guard routine for both cases, but only for the mouse code branch.
If you have an example of actual failing code then please post it.
cgf