Re: [PATCH 1/1] Cygwin: console: fix key input for native console application
On Apr 4 01:25, Takashi Yano wrote:
> - After 24 bit color support patch, arrow keys and function keys
> do not work properly in native console applications if they
> are started in cygwin console. This patch fixes this issue.
> ---
> winsup/cygwin/fhandler_console.cc | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/winsup/cygwin/fhandler_console.cc
> b/winsup/cygwin/fhandler_console.cc
> index d2e3184a6..335467b0b 100644
> --- a/winsup/cygwin/fhandler_console.cc
> +++ b/winsup/cygwin/fhandler_console.cc
> @@ -455,6 +455,15 @@ sig_exit:
> fhandler_console::input_states
> fhandler_console::process_input_message (void)
> {
> + if (wincap.has_con_24bit_colors ())
> +{
> + DWORD dwMode;
> + /* Enable xterm compatible mode in input */
> + GetConsoleMode (get_handle (), );
> + dwMode |= ENABLE_VIRTUAL_TERMINAL_INPUT;
> + SetConsoleMode (get_handle (), dwMode);
> +}
> +
>char tmp[60];
>
>if (!shared_console_info)
> @@ -2894,6 +2903,14 @@ fhandler_console::fixup_after_fork_exec (bool execing)
> {
>set_unit ();
>setup_io_mutex ();
> + if (wincap.has_con_24bit_colors ())
> +{
> + DWORD dwMode;
> + /* Disable xterm compatible mode in input */
> + GetConsoleMode (get_handle (), );
> + dwMode &= ~ENABLE_VIRTUAL_TERMINAL_INPUT;
> + SetConsoleMode (get_handle (), dwMode);
> +}
> }
>
> // #define WINSTA_ACCESS (WINSTA_READATTRIBUTES | STANDARD_RIGHTS_READ |
> STANDARD_RIGHTS_WRITE | WINSTA_CREATEDESKTOP | WINSTA_EXITWINDOWS)
> --
> 2.17.0
Pushed.
Thanks,
Corinna
--
Corinna Vinschen
Cygwin Maintainer
signature.asc
Description: PGP signature
[PATCH 1/1] Cygwin: console: fix key input for native console application
- After 24 bit color support patch, arrow keys and function keys
do not work properly in native console applications if they
are started in cygwin console. This patch fixes this issue.
---
winsup/cygwin/fhandler_console.cc | 17 +
1 file changed, 17 insertions(+)
diff --git a/winsup/cygwin/fhandler_console.cc
b/winsup/cygwin/fhandler_console.cc
index d2e3184a6..335467b0b 100644
--- a/winsup/cygwin/fhandler_console.cc
+++ b/winsup/cygwin/fhandler_console.cc
@@ -455,6 +455,15 @@ sig_exit:
fhandler_console::input_states
fhandler_console::process_input_message (void)
{
+ if (wincap.has_con_24bit_colors ())
+{
+ DWORD dwMode;
+ /* Enable xterm compatible mode in input */
+ GetConsoleMode (get_handle (), );
+ dwMode |= ENABLE_VIRTUAL_TERMINAL_INPUT;
+ SetConsoleMode (get_handle (), dwMode);
+}
+
char tmp[60];
if (!shared_console_info)
@@ -2894,6 +2903,14 @@ fhandler_console::fixup_after_fork_exec (bool execing)
{
set_unit ();
setup_io_mutex ();
+ if (wincap.has_con_24bit_colors ())
+{
+ DWORD dwMode;
+ /* Disable xterm compatible mode in input */
+ GetConsoleMode (get_handle (), );
+ dwMode &= ~ENABLE_VIRTUAL_TERMINAL_INPUT;
+ SetConsoleMode (get_handle (), dwMode);
+}
}
// #define WINSTA_ACCESS (WINSTA_READATTRIBUTES | STANDARD_RIGHTS_READ |
STANDARD_RIGHTS_WRITE | WINSTA_CREATEDESKTOP | WINSTA_EXITWINDOWS)
--
2.17.0
[PATCH 0/1] Fix console again (Re: Pseudo console support in PTY)
Hi Corinna, I have made a patch for the issue reported in cygwin-developers mailing list as follows. Could you please check? On Wed, 3 Apr 2019 09:27:58 +0200 Corinna Vinschen wrote: > On Apr 3 09:18, Thomas Wolff wrote: > > > - cmd history works > > In the cygwin console, it does not, echos the cursor-up escape sequence > > Oh, right, ... > > > instead. See my previous comment that I think ConPTY should only be applied > > if running at a pty. (And for other reasons only when starting a non-cygwin > > app.) > > but you got that wrong. The conpty stuff *is* only applied for ptys. > > The above appears to be a fallout of the console changes to support > the Windows console changes to emulate an xterm-256color, > https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=bd627864ab41 > > Takashi, can you take a look? Takashi Yano (1): Cygwin: console: fix key input for native console application winsup/cygwin/fhandler_console.cc | 17 + 1 file changed, 17 insertions(+) -- 2.17.0
Re: [PATCH fifo 0/2] Add support for duplex FIFOs
On 4/3/2019 8:33 AM, Achim Gratz wrote: > Achim Gratz writes: >> OK, a bit more info: The whole thing runs from a perl script (actually a >> module) that opens pipes to gnuplot and ghostscript. This code is >> _really_ old and has seen a lot of Cygwin releases, so it has options to >> either use temporary files, named pipes aka FIFO or direct pipes. Using >> temporary files serializes the execution and using a pipe chain is >> _really_ slow (like a hundred times, which is mostly tied up in system >> for a reason that I don't understand), so using FIFO is the default. >> Your new FIFO code increases the system time by about a factor of 10 in >> my tests, btw. > > So I've finalöly got around to fixing the pipe performance problem by > fooling the programs involved to think they are using files: have them > reading from /proc/self/fd/0 and writing to /proc/self/fd/1 gives me the > same performance as using a named FIFO. > > Incidentally, that workaround still works when I switch to the 20190402 > snapshot, while named FIFO fails as with the older snapshot (as > expected), so that seems to take a different code path. Maybe that > helps in finding the problem? Thanks. In the meantime, I've fixed the raw_write bug that I mentioned in an earlier post, along with some other bugs I found. I want to do a little more testing before I send the patches. Ken
Re: [PATCH fifo 0/2] Add support for duplex FIFOs
Achim Gratz writes: > OK, a bit more info: The whole thing runs from a perl script (actually a > module) that opens pipes to gnuplot and ghostscript. This code is > _really_ old and has seen a lot of Cygwin releases, so it has options to > either use temporary files, named pipes aka FIFO or direct pipes. Using > temporary files serializes the execution and using a pipe chain is > _really_ slow (like a hundred times, which is mostly tied up in system > for a reason that I don't understand), so using FIFO is the default. > Your new FIFO code increases the system time by about a factor of 10 in > my tests, btw. So I've finalöly got around to fixing the pipe performance problem by fooling the programs involved to think they are using files: have them reading from /proc/self/fd/0 and writing to /proc/self/fd/1 gives me the same performance as using a named FIFO. Incidentally, that workaround still works when I switch to the 20190402 snapshot, while named FIFO fails as with the older snapshot (as expected), so that seems to take a different code path. Maybe that helps in finding the problem? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [PATCH RFC] fork: reduce chances for "address space is already occupied" errors
Michael Haubenwallner writes: > Before I really can tell what I need regarding the rebase, I need to learn > what > exactly is recorded into the rebase database, and probably how the recorded > data > does influence the rebase procedure right now. Just where the DLL resides in the filesystem, what address it has been rebased to and what size it occupies. If you rebase a new DLL with the database, it will give you the first gap in the address space that this new DLL fits into for doing the rebase and record that into the database. With the --oblivious option, it keeps the database file untouched, so the information about the newly rebased DLL gets lost whenh the program exits. That's why you need to do all oblivious rebasing in a single invocation. > My thoughts so far for what I probably need: > > * First, rebase new dlls before being installed into the target file system > directory with respect to currently installed dlls (the --oblivious > option), You always rebase after the install so that the path information is correct. Pre-rebasing is useless. > * Second, register new dlls just installed into the target file system > directory into the rebase database without performing a rebase, and No, rebasing the installed DLL already does that. > * Third, unregister dlls being removed from the rebase database. Rebase already removes any entries that are no longer accessible from the database. > Also, it may make sense to allow for reusing the base address of an installed > dll by it's update replacement - while the old version dll still is in use and > the new version dll is in some temporary staging directory. Rebase already re-uses the base-address if the path for the new DLL is the same and it still fits into the gap. In general, however, that won't work when the size of any DLL changes. You can ask for more guardband around each entry, but that doesn't actually solve the problem as it's only useful for the initial (full) rebase. > As there may be multiple instances of Gentoo Prefix within one single > operating > system instance, it does not make sense to record the dll's base addresses > into > the rebase database of the underlying Cygwin instance in /etc, but still the > base addresses already recorded there should be respected when rebasing dlls > for within a particular Gentoo Prefix instance. If you can limit the address space that's used by the Cygwin base system, I'd just give your Gentoo prefix installation its own address space and rebase it independently from the base system. That probably requires some fooling around with the (currently hardcoded) rebase database files, but should otherwise just work. > Furthermore, with so called "Stacked Prefix", it is possible to have a second > level of Gentoo Prefix, so what I'm after is some option to tell the rebase > utility which database to record dll base addresses into, and which > multiple(!) > databases take into account while performing a rebase. I don't think you'll want to do that. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
Re: [PATCH RFC] fork: reduce chances for "address space is already occupied" errors
On Apr 3 12:38, Michael Haubenwallner wrote: > Furthermore, with so called "Stacked Prefix", it is possible to have a second > level of Gentoo Prefix, so what I'm after is some option to tell the rebase > utility which database to record dll base addresses into, and which > multiple(!) > databases take into account while performing a rebase. rebase is OSS. There's nothing keeping you from providing patches to make your scenario work ;) Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: [PATCH RFC] fork: reduce chances for "address space is already occupied" errors
On Apr 3 11:18, Michael Haubenwallner wrote: > On 4/1/19 5:56 PM, Corinna Vinschen wrote: > > On Apr 1 16:56, Corinna Vinschen wrote: > >> On Apr 1 16:28, Michael Haubenwallner wrote: > >>> On 3/28/19 9:30 PM, Corinna Vinschen wrote: > can you please collect the base addresses of all DLLs generated during > the build, plus their size and make a sorted list? It would be > interesting to know if the hash algorithm in ld is actually as bad > as I conjecture. > >>> > >>> Please find attached the output of rebase -i for the dlls after bootstrap > >>> on Cygwin 3.0.4, each built with ld from binutils-2.31.1. > > > > Oh, wait. That's not what I was looking for. The addresses are ok, but > > the paths *must* be the ones at the time the DLLs have been created, > > because that's what ld uses when creating the image base addresses. The > > addresses combined with the installation paths don't make sense anymore. > > So I have intercepted the ld.exe to show 'rebase -i' on any just created dll, > tell about the exact -o argument to ld, and the current directory. > > This is with binutils-2.31.1 > > Anything else needed? No, that should be sufficient, thanks for collecting this! Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: [PATCH RFC] fork: reduce chances for "address space is already occupied" errors
Hi Brian, hi Achim,
Thanks a lot for your input!
On 3/30/19 5:09 PM, Brian Inglis wrote:
> On 2019-03-30 02:22, Achim Gratz wrote:
>> Brian Inglis writes:
>>> On 2019-03-29 14:23, Achim Gratz wrote:
Brian Inglis writes:
>> If you are packaging your own exes and dlls with your own local Cygwin
>> distro,
>> you should point to your local utility directory with a path in a file
>> under
>> /var/lib/rebase/user.d/$USER for each Cygwin userid on each system, or
>> perhaps
>> you might also need to add your own production exes and dlls into
>> /var/cache/rebase/rebase_user and /var/cache/rebase/rebase_user_exe: see
>> /usr/share/doc/Cygwin/_autorebase.README.
>>>
>>> I was wondering as my first para above stated, whether rebase_user{,_exe}
>>> would
>>> be the proper place to add 3rd party Cygwin dlls and exes, that are
>>> distributed
>>> with Cygwin (internally)?
>>
>> Well, if you are distributing something (even just locally), then
>> preferrably you make proper Cygwin packages and you will never have to
>> deal with rebase yourself.
>>
>> The options you allude to above are meant for cases where that just
>> isn't possible and so you install things without using setup and often
>> also outside the Cygwin install (permanently, not temporarily until it
>> gets packaged). You still need to run setup after each change so
>> autorebase can pick up on it.
>
> Thanks Achim,
>
> I think that those are possibly the answers the OP Michael was looking for,
> depending on how they are using Gentoo Prefix: it did not seem like they were
> installing their dlls and exes using Cygwin setup, but they could still run
> autorebase under dash.
Beyond being portable across many operating systems (*nix, MacOS, Cygwin, ...),
one of the main goals for Gentoo Prefix is to provide it's packaging mechanism
without the need for any privilege elevation on the underlying operating system,
nor coping with the various underlying operating system's packaging mechanisms.
On a side note:
To get it working as intended on Cygwin, I had to extend Cygwin fork() to allow
for updating dlls and executables while the process is running, as the Gentoo
Prefix package manager is a Cygwin program by itself - unlike Cygwin setup.exe,
which is a non-Cygwin executable and requires Cygwin processes to be terminated.
Before I really can tell what I need regarding the rebase, I need to learn what
exactly is recorded into the rebase database, and probably how the recorded data
does influence the rebase procedure right now.
My thoughts so far for what I probably need:
* First, rebase new dlls before being installed into the target file system
directory with respect to currently installed dlls (the --oblivious option),
* Second, register new dlls just installed into the target file system
directory into the rebase database without performing a rebase, and
* Third, unregister dlls being removed from the rebase database.
Also, it may make sense to allow for reusing the base address of an installed
dll by it's update replacement - while the old version dll still is in use and
the new version dll is in some temporary staging directory.
As there may be multiple instances of Gentoo Prefix within one single operating
system instance, it does not make sense to record the dll's base addresses into
the rebase database of the underlying Cygwin instance in /etc, but still the
base addresses already recorded there should be respected when rebasing dlls
for within a particular Gentoo Prefix instance.
Furthermore, with so called "Stacked Prefix", it is possible to have a second
level of Gentoo Prefix, so what I'm after is some option to tell the rebase
utility which database to record dll base addresses into, and which multiple(!)
databases take into account while performing a rebase.
Thanks!
/haubi/
Re: [PATCH RFC] fork: reduce chances for "address space is already occupied" errors
On 4/1/19 5:56 PM, Corinna Vinschen wrote: > On Apr 1 16:56, Corinna Vinschen wrote: >> On Apr 1 16:28, Michael Haubenwallner wrote: >>> On 3/28/19 9:30 PM, Corinna Vinschen wrote: can you please collect the base addresses of all DLLs generated during the build, plus their size and make a sorted list? It would be interesting to know if the hash algorithm in ld is actually as bad as I conjecture. >>> >>> Please find attached the output of rebase -i for the dlls after bootstrap >>> on Cygwin 3.0.4, each built with ld from binutils-2.31.1. > > Oh, wait. That's not what I was looking for. The addresses are ok, but > the paths *must* be the ones at the time the DLLs have been created, > because that's what ld uses when creating the image base addresses. The > addresses combined with the installation paths don't make sense anymore. So I have intercepted the ld.exe to show 'rebase -i' on any just created dll, tell about the exact -o argument to ld, and the current directory. This is with binutils-2.31.1 Anything else needed? /haubi/ dll-info.txt.xz Description: application/xz
