console: new mouse modes, request/response attempt
Mon Apr 2 20:41:00 GMT 2012
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.
>>> 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
>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
>Maybe not, but the fact that it works partially but subsequent
>characters are postponed resembles the other problem that I have just reported
>firstname.lastname@example.org, 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.
More information about the Cygwin-patches