Re: [PATCH v2 0/1] Pseudo console support in PTY (v2)

[Thomas Wolff <towo@towo.net>]

Hi
> Without patched cygwin-console-helper.exe, mintty will not start.
I was meanwhile able to build the patch (v1) on a Windows 7 system and 
try it on a Windows 10 system.

Takashi Yano wrote:
> Hi Corinna,
>
> On Wed, 3 Apr 2019 18:50:29 +0200 Corinna Vinschen wrote:
>> I will, but can you please outline the changes between v1 and v2 of your
>> patch?  I'd like to understand the code and what the challenges are to
>> get this working.
> Major changes are as follows.
>
> (1) Pseudo console setup code in pty master is moved into the function
>      setup_pseudoconsole().
In my test, character attributes (colour) were sometimes only reproduced 
when running the test program for the first time. Maybe v2 fixes that.
> (2) The code for pushing slave output into pseudo console screen buffer,
>      which is for synchronization between real terminal and pseudo console
>      screen buffer, is moved into the function push_to_pcon_screenbuffer().
> (3) In push_to_pcon_screenbuffer(), add code which attach to pseudo
>      console temporally if slave is not attached yet.
> (4) Call fhandler_console::need_invisible() in stdio_init() in dtable.cc
>      instead of just returning from function when progname is "mintty".
What's the specific handling for mintty? Puzzled, I think all pty-based 
terminals need the same handling.
> (5) Pushing slave output into pseudo console screen buffer is disabled
>      when alternate screen buffer is used.
Confused. What does console handling have to do with the alternate 
screen? It's purely a client-side concept with respect to the pty. If 
the terminal is in alternate screen mode, console output is directed to 
that screen buffer and should be handled the same way, right?
> (6) Change code page to 65001 (UTF-8) at startup of pty slave.
What about other codepages, depending on the locale?
> (7) Remove "\033[6n" and "\033[0c", which generate report result in
>      console input buffer, in the data to be pushed into pseudo console
>      screen buffer.
Why's that? If a Windows console app really sends those, it will do so 
on purpose (e.g. because it detects the %TERM% variable to conclude it's 
running in a terminal), so it will also expect the respective response.

I wasn't able to test raw keyboard input and terminal resize so far 
(looking for a suitable test app, some command-line Windows editor 
perhaps...)

There is one other interoperabililty problem I'm concerned about but it 
may not be related and perhaps not fixable via ConPTY:  If I start a 
Windows GUI program, e.g. notepad, and enter ^Z in the terminal, notepad 
is terminated rather than suspended. Maybe Cygwin should just ignore 
suspend signals towards Windows programs.

Kind regards
Thomas

> (8) Add some comments.
>
> (1) and (2) are not essential changes.
>
> (3) fixes the issue:
> On Thu,  4 Apr 2019 01:36:20 +0900 Takashi Yano wrote:
>> On Sat, 30 Mar 2019 22:08:04 +0900 Takashi Yano wrote:
>>> Known problems:
>>> * mintty fails to start if it is started in console cygwin
>>>    session.
>> This has been resolved in the new version.
> (3) also makes it unnecessary the code returning from function
> stdio_init() in dtable.cc when progname is "mintty".
>
> (4) is for:
> On Tue, 2 Apr 2019 13:02:48 +0200 Corinna Vinschen wrote:
>> I found another weird effect which I can't explain off the top
>> of my head:  system_printf() debug output does not show up
>> in a mintty anymore with this patch.  Any idea why?
> howver, I am not sure why this solves the issue.
>
> (5) makes vim screen drawing speed up a little.
> (6) avoids garbled characters.
> (7) avoids the garbage in the input buffer for native console apps
> after vim is used.
>