This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: [PATCH v2 0/1] Pseudo console support in PTY (v2)
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.