For completeness here's a screenshot that shows the situation on a TERM=sun-console text console with the latest code :

After thinking a little more about this issue, I am of the opinion that the best option here is to provide a compile time configure option :

It would be convenient if the -c option could be easily set in the gpg-agent.conf or in some configuration file for pinentry. The workaround that I use now to create a script that I can then use as pinentry-program is extra work because it requires an additional script.

The typo is fixed now and after pulling the latest sources from the repo and configure --disable-ncurses :

Thanks for testing. I pushed a fix for my typo: rPb713f31c5b04: curses: Fix the previous commit.

My previous patch is not perfect as the screenshot in attach shows. The clear() is not really sufficient as it only redraws the portion below the frame in the new background color (black instead of white).

In the patch in attach I do a clear screen in the non-ncurses case.

Hello Tim and Yukata Iibe (gniibe),

Thank you for locating the bug!

Hi gniibe!

Thank you for your investigation.

Hi gniibe!

After testing about a dozen different term types and doing some library tracing, it appears to be that any terminfo type for which has_colors() is false (so the start_color code is never called) works correctly.

Hi gniibe!

Another link: http://hea-www.harvard.edu/~fine/opinions/xterm-problems.html

All of my testing has been done while connecting via ssh to my OpenIndiana workstation. I'm using PuTTY 0.76 as my terminal/SSH client.

It appears to you identified the problem really quickly again. If I select the entire screen and paste it, the dialog text is there:

@mooney Just in case when it's color related problem, could you try to cut&paste the text of the screen when pinentry should display a dialog box?

I found some links:
XTerm FAQ:
https://invisible-island.net/xterm/xterm.faq.html
Why not just use TERM set to "xterm"?
https://invisible-island.net/ncurses/ncurses.faq.html#xterm_generic
What $TERM should I use?
https://tools.ietf.org/doc/xterm/xterm.faq.html#xterm_terminfo

I see, I wasn't aware of this. Thanks for fixing!

Thanks for commenting. I close this bug then.

Your proposed fix (in your first comment) has actually already been applied (commit 1305baf0994059f458b1d5ca28a355c12932fab3 in master, backported to the -2.2 branch in 455ba49071dea7588c9de11785b3092e45e4560b). It is part of gnupg-2.2.31 released today. :)

The Qt upstream bug report has just been rejected. I hope something can be done here...

Package maintainer from PLD here. We still ship Qt4 and therefore provide pinentry qt4 for as long as it's supported. I have no problem with dropping it if it's no longer support, but last release still supported Qt4, there's no mention of dropping such support in NEWS and both code as well as configure.ac appear to still carry Qt4 support which is a bit confusing.

Qt4 is no longer supported. Please use the previous released version plus commit rP2859eddfb0c9: qt: Fix build against Qt4 to build pinentry for Qt4. For everything else use 1.2.0.

I have rather created D536 as IMO the timeout should be changed, not the documentation.

@fvogt I've now added a logging category. Thanks for the suggestion.

Yeah, that sounds good to me.

In T5551#148510, @werner wrote:

I would prefer to see a fix/hack in pinentry-qt instead.

I see. Thanks!

To minimize the risk of regressions.

Not to be bothersome, but why? DISPLAY seems like the universal method of selecting a display to put things on, where a lot of applications don't support --display or equivalent, especially now there's no equivalent for wayland. It's especially confusing to me when the keep-display option will pass DISPLAY instead of --display. This would also prevent other such scenarios with 3rd party qt/gtk plugins or alternative pinentry implementations.

As far as I understood, $WAYLAND_DISPLAY does not need to be set because there is a well-defined default, but I guess most of the time it's set anyway.

QGuiApplication checks $XDG_SESSION_TYPE maybe to find out whether to use X11 or Wayland if $DISPLAY and $WAYLAND_DISPLAY are both set.

I gave it a try and it works here now with $DISPLAY unset, thanks!

Should now work for pinentry-qt on Wayland even if DISPLAY is not set.

This has been fixed with rP9dd46926f8d5: qt: Fix showing of pinentry window on Wayland.

Notification when trying to enter empty passphrase:

@aheinecke Please test this on Windows

Huh, can't believe I somehow missed that this actually got a reply three years ago...

It's worth noting that this issue is particularly impactful for devices with small screens whose sizes cannot be changed. A Raspberry Pi with an Adafruit touchscreen would almost certainly have issues, for example.
This also applies to mobile devices. For context, I use Termux on my Android phone, and this issue manifests there. I can enter the passphrase for an existing key and decrypt/sign with it, but any attempt to create a new key throws me into the same loop that the OP describes. (Interestingly, this happens whether or not I actually supply a new passphrase.)
Since I am on a mobile device in this scenario, my terminal dimensions are 56x115. I'm not familiar with the implementation details of GPG, but is there any chance we could fall back to a single-line, sudo-style password prompt if pinentry fails (or have pinentry fall back to that internally if the normal mode fails)? That should work on terminals of just about any size.
(As an additional note, I've also tried flipping into landscape orientation, hoping that would increase my screen width sufficiently. However, my keyboard then occupies most of the screen, and I receive the expected error message, gpg: agent_genkey failed: Screen or window too small.)
EDIT: I'm running GPG 2.3.1 and pinentry 1.1.1.

Implemented for X11 and Windows.

For formatting there are four modes: Formatting forced off (the default)/force on/on/off. The latter two modes allow the user to change the option.

That might depend on your pinentry version. With a pre-1.1.1 pinentry and 2.2.28 I get this:

Thank you all for the help. I thought this was a bug with pinentry itself but appears to be dbus related based on the above command.