This is the mail archive of the cygwin-patches mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: console: new mouse modes, request/response attempt


Am 02.04.2012 22:40, schrieb 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:
...
* 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.
...
`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?
Yes, that's why I mentioned problem 1 above. The patch is experimental, and it revealed that even if the missing relation could be properly established, there's still the other problem... (see below).
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.
My point is: The function that doesn't work here, puts_readahead/put_readahead,
is also called in fhandler_pty_master::accept_input () (fhandler_tty.cc)
and in fhandler_termios::line_edit () (fhandler_termios.cc),
and I remember pipe and/or pty problems being discussed recently.
Also there is the "input delay issue" in mintty/xterm I described (and by the way, I forgot to mention it does not happen anymore in the terminal after rlogin to another system) and somehow I suspect they might have a common cause, or similar causes.
------
Thomas



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]