console: new mouse modes, request/response attempt

[Christopher Faylor]

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