This is the mail archive of the cygwin-developers 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: [PATCH v3 0/1] Pseudo console support in PTY (v3)


Hi Thomas,

Thank you very much for testing.

On Sat, 6 Apr 2019 23:33:04 +0200 Thomas Wolff wrote:
> Character output conversion works with my test program (using 
> WriteConsoleW). Using java, output works too (with proper java encoding 
> option), but non-ASCII input characters are replaced by and echoed as space.

Indeed... I will fix it.

> If I try a non-Unicode terminal session, e.g. running mintty -o Locale=C 
> -o Charset=CP1252 -, and enter a € key, mintty hangs. While you said it 
> doesn't work (yet), it should better not hang at least. I'd like to 
> repeat at this point that the whole mechanism should only be applied if 
> a non-cygwin program is run. (If it were, entering € in bash would not 
> block the terminal.)

OK. I will check why this happens.

> Do you actively synchronize anything? I thought this is not needed 
> anymore (unlike winpty) because the ConPTY performs the adaptation.

I don't think so.

> Terminal reports "\033[6n" and "\033[0c" are apparently emulated and 
> sent in reverse order;
> response to primary device attribute request is wrong (not what mintty 
> would report).
> There is no response to secondary device attribute request ("\033[>0c") 
> and others,
> e.g. '\033[18t' or '\033]10;?\033\' and many others; why can't these 
> requests be passed to the terminal and handled transparently? (You 
> explained something around handles before but I don't get the point.)

This is not caused by my intercept, but pseudo console itself.
Unfortunately, pseudo console is not transparent at all. Pseudo
console interprets VT100 sequences in output and processes them.
Then, it fowards another VT100 sequences to the pipe associated
with the pseudo console.

> Output to alternate screen seems to be forced to the primary screen, mostly;
> if I try to switch screen in various ways (menu, echo "\033[?1047h" > 
> /dev/pty1, before or while cmd.exe runs),
> behaviour appears to be inconsistent and not as expected (expected 
> behaviour is that any output goes to the active screen).

Hmmm, this may be caused by "synchronization". I will also check
this.

> Again, I don't see a need that you intercept this at all.

The patch attached disables all my intercept. It is against v3.
Please check the output from PTY using script command with this
patch. You can use your test case for the test. You will find many
VT100 ESC secuenses you don't write to console. These are written
by pseudo console itself.

Also, you can confirm screen layout is broken if you run cygwin
apps and native console apps alternately. "Synchronization" is
necessary to avoid this, I think.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

Attachment: for-Thomas.patch
Description: Binary data


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