Make the login dialogue bigger?

[HubKing]

The login dialogue is too small, especially when using a 4K monitor. I can hardly see the text.

Even if it cannot resize itself intelligently depending on the resolution and DPI, since there is a lot of empty space, if only I could simply double the size, it would be much better.

[metalefty]

I also think that needs to be addressed.

[matt335672]

There's also the point that if NLA was working (which I admit we are a long way from), this dialog would be less needed anyway.

[TOMATO-ONE]

I use xrdp as my RDP Proxy gateway.
So I can agree with Hubking's opinion.

The size of the login screen is defined in the Globals section of xrdp.ini.
The size can be increased by setting appropriate values.

xrdp/xrdp.ini
[Globals]
ls_width=350
ls_height=430

However, it does not seem to be possible to change the font size.

A quick check of the source code shows that
I think the font used in dialogues etc. is sans-10.fv1.

xrdp/xrdp_types.h
#define DEFAULT_FONT_NAME "sans-10.fv1"

[TOMATO-ONE]

To test this hypothesis, I would like to replace it with a larger font.

I think I can use fontdump/fontdump.c to create a font in fv1 format.
fontdump.c is supposed to be a binary for Microsoft Windows.
I didn't quite understand how to build it.
Can anyone give me some advice on how to do this?

[metalefty]

It is just making dialog bigger. If the screen is small, dialog becomes too big.
It should be handled as scaling by desktop scale factor.

[TOMATO-ONE]

Thank you for pointing this out.

Ideally scaling should be implemented in the future.
However, it would require major changes to xrdp_wm.c and xrdp_loing_wnd.c.
I think a lot of work is needed.

I find it relatively easy to allow arbitrary fonts to be specified in the global section of xrdp.ini.
A fix to allow administrators to specify an arbitrary fv1 font would be an immediate work-around to this issue.

[matt335672]

@TOMATO-ONE - I've done a bit of analysis on the .fv1 file. From what I can tell, the status of this is:-

• It is, as you say, the default font for the xrdp login dialog
• The format appears to be proprietary to xrdp. I can find no documentation on this format on the web. There is some information within xrdp/xrdp_font.c
• Features of the file:-
  • Based on DejaVu Sans 10 point
  • Unicode characters 0x20-0x4dff are included.
  • Glyphs are bitmaps only with no scaling support.

It should be possible to port the fontdump utility to Un*x by using something like the freetype2 library. This is a dependency of the X server in any case, so adding this in to xrdp isn't going to cause any additional difficulties. That might be easier than trying to get fontdump built on Windows.

We're going to need something like this anyway in the future - see #1637 for some thoughts I've had on this earlier, in particular this post

I'm a bit stalled on some other work at the moment due to personal commitments, but I'll have a look at the above.

[TOMATO-ONE]

Thank you.

I agree with you about the implementation of calculating and scaling the DPI of the monitor based on the device information.
I think it would be great if implemented.

However, the immediate workaround until implementation should also be considered.
I am only skilled enough to make slight improvements to the source code.
I cannot say that the Un*x porting of fontdump.c is easy.

Microsoft Windows binaries can be expected to work in most Windows environments due to backwards compatibility if built properly.
I don't know if it is Cygwin, Visual C or MinGW, but I will prepare an old compile environment and investigate how to build fontdump.c.

If I get any good results I will share them with the community.

[matt335672]

I've decided not to work with fontdump directly.

I'm now looking at producing a utility to convert a ttf file to an fv1 file at a certain pixel size. If I get something useful working I'll post a link here.

This is still a workaround. If it works OK, I think the next step is to update xrdp to work with ttf files directly. That solves some of the internationalisation issues and should make scaling a lot easier. It's a bit too much for me to do in a single step though, which is why I'm looking at the utility. Also, I think some of the sesman stuff I'm working on is higher priority.

If you discover an easy way to build fontdump we can add a README to the xrdp distribution for it - that would be useful I think.

[TOMATO-ONE]

Thank you.
And apologies.

I am sorry for the disappointing result.

I have looked into how to BUILD fontdump.c.

• It appears to be code written in C++ Builder.
• The code appears to be a GUI application, not a Win32 console application.
• The GUI project file is not included in the code, so even if I could prepare a compile environment, I would not be able to build it.
• If you build with C++ Builder Community Edition, the binary application cannot be freely redistributed or used due to licence rules.

For these reasons, the current fontdump.c cannot be used as is.
I had to rebuild it based on Un*x, as you said.

With my skills, it would be difficult to deal further with the current fontdump.c.

[matt335672]

Thanks for the feedback anyway - it's all useful.

I'm currently working on relocating the font-specific code in the xrdp program into the common library so I can get some Unix font utilities built. I've got some encouraging results so far, but it's early days. I'll post something here as soon as I get something useful working.

[matt335672]

I've got a font dump program for fv1 files working now, which is a necessary step to solving problems with new font files.

Next step is to get a font file created, which I'm relatively close to, I think.

The code is a bit of a mess at the moment, but I'll tidy it up as I'm going along.

https://github.com/matt335672/xrdp/tree/unix_fontdump

[TOMATO-ONE]

Thanks for your work !!

In the weekend time I will try your code.

[matt335672]

Just build xrdp as normal, and you should get a program xrdp-dumpfv1. It gives you view info about a font file, or lets you dump out a single glyph.

Use it like this:-

 ./xrdp-dumpfv1 -i ../xrdp/sans-10.fv1 
Font name : DejaVu Sans
Point size (96 DPI) : 10
Style : 1
Min glyph index : U+0020
Max glyph index : U+4DFF
Max glyph width : 21 (U+2031)
Max glyph height : 15 (U+0020)
Min glyph y-baseline : -15 (U+0020)
Max glyph y-dropdown : 1 (U+0300)
Min glyph x-offset : -13 (U+0488)
Max glyph x-offset : 9 (U+2595)
Max glyph x-inc_by : 23 (U+2031)
Max glyph datasize : 48 (U+01C4)

and:-

$ ./xrdp-dumpfv1 -c U+0040  ../xrdp/sans-10.fv1 
Glyph : U+0040
  Width : 11
  Height : 15
  Baseline : -15
  Offset : 1
  Inc By : 13
  Data :
    -15: ...........
    -14: ...........
    -13: ...........
    -12: ...XXXXX...
    -11: ..X.....XX.
    -10: .X.......X.
     -9: X...XXXX..X
     -8: X..X...X..X
     -7: X..X...X..X
     -6: X..X...X.X.
     -5: X...XXXXX..
     -4: .X.........
     -3: ..X.....X..
     -2: ...XXXXX...
     -1: ...........

A manpage will be coming!

One thing that's clear is there's a lot of horizontal padding in the existing file. I don't yet know if this is needed or not. Removing it will shrink the file a bit.

[matt335672]

Also, my branch is under quite a bit of development at the moment, so the history is a bit of a mess currently.

[TOMATO-ONE]

Thanks for the explanation. It is helpful.

I was able to build on my CentOS7 x86_64 build system using the following steps.

./bootstrap
CFLAGS="-Wno-error=missing-braces" ./configure
make

I try with some fonts .

[matt335672]

Here's my first attempt at making sans-10.fv1 using a UNIX program:-

I'm not sure exactly what's going on in the painter to cause this, but I suppose it's progress of sorts!

[matt335672]

I'm getting closer now, but I still need to figure out a better way to get the font heights calculated:-

It's noticeable that all the non-blank characters in the sans-10.fv1 font file have a height of 15 pixels and a baseline of -15 pixels. I can go with this model, but it does waste a lot of space in the file.

[TOMATO-ONE]

Thanks for the great work you do.
Can you please tell me what parameter is used to create the fv1 font?

[matt335672]

It's a separate program called xrdp-mkfv1

At the moment all the parameters it takes are hard-coded. As soon as I can get something useful out of it I'll publish the details and make it a bit more user-friendly.

I've had a think about how the .fv1 fonts are put together. I can see where I'm going wrong with the heights - it seems there's some missing information that should probably be provided as part of the font, but which is compensated for by all the characters having extra top padding in them. I think the first thing to do is to get something working, and then we can decide if the format should be optimised, or whether it might be better to load a ttf font directly in xrdp.

[matt335672]

Getting there.
Here is a shot of the login screen with a Liberation Serif font:-

And here's one with the hideous Comic Sans:-

These are created with the xrdp-mkfv1 program on the UNIX side.

At the moment it's a bit of a mess. Over the next couple of days I'll try to get it tidied up and documented so that we can try it out on bigger fonts. By all means try it. You'll need to build xrdp from the branch above with --with-freetype2 and then directly edit fontutils/mkfv1.c to change the parameters.

I've come to the conclusion that the fv1 format is a bit of a work-in-progress. I've had to make a few small changes to the painter to get this working. To progress to xrdp directly loading a scalable font needs more information on the glyph baselines adding to the fv1 file (I think).

[matt335672]

OK - I've managed to get a few hours in this afternoon to tidy up xrdp-mkfv1

You need to build xrdp with --with-freetype2 from my branch to get the utility. Also there's a small painter modification, so the files it produces won't work on a vanilla xrdp build - use xrdp from my branch.

Usage:-

xrdp-mkfv1 [-p <point-size>] [-n <font-name>] -m [<max-unicode-char>] -s [<max-scan-char>] [input-file] [output-file]

• FV1 fonts are always 96 DPI, so you have to use 'p to get a bigger font.
• -m sets the number of characters in the file.
• -s says how many characters are scanned to find out the top and bottom margins of the characters. For compatibility only the first 256 characters are scanned. As a result, some of the later glyphs are truncated on the top and bottom. This replicates the existing font behaviour.

Here's an example of generating a big font:-

$ xrdp-mkfv1 -p20 /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf temp.fv1

Then look at characters with the dump program. Here's what the 'A' character looks like:-

$ xrdp-dumpfv1 -c @A temp.fv1
Glyph : U+0041
  Width : 18
  Height : 26
  Baseline : -32
  Offset : 0
  Inc By : 18
  Data :
    -32: ..................
    -31: ..................
    -30: ..................
    -29: ..................
    -28: ..................
    -27: ..................
    -26: .......XXXX.......
    -25: .......XXXX.......
    -24: .......XXXX.......
    -23: ......XXXXXX......
    -22: ......XXXXXX......
    -21: .....XXXXXXXX.....
    -20: .....XXX..XXX.....
    -19: .....XXX..XXX.....
    -18: ....XXXX..XXXX....
    -17: ....XXX....XXX....
    -16: ....XXX....XXX....
    -15: ...XXX......XXX...
    -14: ...XXX......XXX...
    -13: ..XXXXXXXXXXXXXX..
    -12: ..XXXXXXXXXXXXXX..
    -11: ..XXX........XXX..
    -10: .XXXX........XXXX.
     -9: .XXX..........XXX.
     -8: .XXX..........XXX.
     -7: XXX............XXX

Here's a bold big font:-

$ xrdp-mkfv1 -p20 /usr/share/fonts/truetype/dejavu/DejaVuSans-Bold.ttf temp.fv1
$ xrdp-dumpfv1 -c @A temp.fv1
Glyph : U+0041
  Width : 21
  Height : 26
  Baseline : -32
  Offset : 0
  Inc By : 21
  Data :
    -32: .....................
    -31: .....................
    -30: .....................
    -29: .....................
    -28: .....................
    -27: .....................
    -26: .......XXXXXXX.......
    -25: .......XXXXXXX.......
    -24: ......XXXXXXXXX......
    -23: ......XXXXXXXXX......
    -22: ......XXXXXXXXX......
    -21: .....XXXXXXXXXXX.....
    -20: .....XXXXX.XXXXX.....
    -19: .....XXXXX.XXXXX.....
    -18: ....XXXXXX.XXXXXX....
    -17: ....XXXXX...XXXXX....
    -16: ....XXXXX...XXXXX....
    -15: ...XXXXXX....XXXXX...
    -14: ...XXXXX.....XXXXX...
    -13: ..XXXXXXXXXXXXXXXXX..
    -12: ..XXXXXXXXXXXXXXXXX..
    -11: ..XXXXXXXXXXXXXXXXX..
    -10: .XXXXXX.......XXXXXX.
     -9: .XXXXX.........XXXXX.
     -8: .XXXXX.........XXXXX.
     -7: XXXXXX.........XXXXXX

I still need to add manpages, but this should be usable.

If you want one that works without painter modifications let me know and I'll add a compatibility switch to the font generator.

[TOMATO-ONE]

Thank you for your time.

I did not think that modifications to the xrdp itself were necessary.
I had thought that simply generating a larger font would be enough to deal with this problem.
I admit that my outlook was naive.

In any case, thanks again for your excellent work.
I will take some time this weekend to try it out.

[matt335672]

I've now added a '-C' compatibility switch to xrdp-mkfv1. If you use this, you should be able to use the fonts it generates on an existing xrdp installation.

My apologies - I hadn't really thought about simplifying the user testing. This should help a bit.

[matt335672]

Latest pushes add manpages for xrdp-mkfv1 and xrdp-dumpfv1.

[TOMATO-ONE]

I was able to get xrdp 0.9.19 to load the generated fonts using the -C option.
However, the xrdp.ini associated with loginscreen does not seem to have a parameter for setting the height of dialogs etc.

I now realise that this problem cannot be solved without modifying the xrdp itself.
It is going to be a lot of work........

[matt335672]

I'd not got that far. I'll take a look. It's hard to say at the moment how much work it will be...

Thanks for looking into this.

[TOMATO-ONE]

I also checked the source code.
The height of the combo box and edit box were specified as constants in xrdp_types.h.

#define DEFAULT_COMBO_H 21
#define DEFAULT_EDIT_H 21

I rewrote each value to 38 to build xrdp.
I replaced the sans-18.fv1 generated with 18 points in xrdp-mkfv1 with the following display.

It may be possible to read the values of DEFAULT_COMBO_H and DEFAULT_EDIT_H from xrdp.ini together with the font file name.

[matt335672]

Good work!

I've not got that far. I'll take a look.

Alternatively, we could read the character height from the font file, and add 6 pixels. That might work better.

What version of xrdp are you working with? Is it devel, or xrdp v0.9.x?

[TOMATO-ONE]

Thanks.
I tried it on your unix_fontdump branch #78d44ed.
As you say, automatically determining the height from the font file is a good idea.

[matt335672]

Some progress today, but a way to go:-

• I've added a font= parameter to [Globals] in xrdp.ini, and calculated the combo and edit heights from the font.
• I've generated a sans-18.fv1 and adjusted other parameters to suit.

I need to figure out the title height (not done that yet), and also fix the logging box

[TOMATO-ONE]

Great work!!

I think we are approaching a practical level.

Where is the title height defined in the source code?
I could not find it in xrdp_types.h.

[matt335672]

I couldn't find it yesterday, and I'm a bit short of time today. I'll have a look ASAP.

[matt335672]

@TOMATO-ONE - I've just set a breakpoint on xrdp_painter_draw_text() and I think the text box height is being set in xrdp_bitmap_invalidate() around lines 683-696. There are a couple of hard-coded uses of 18 there which probably need to be font height + 3. I've got absolutely no time right now due to family commitments, but I'll get to it tomorrow.

I think since we need to make changes to xrdp anyway, I'll update the fv1 file format to include more information on the font height and baseline. It should make it easier to move to ttf files later on, which has to be what we want to do.

[TOMATO-ONE]

I was too busy with work to comment.
Thank you for looking up the source code for me while I don't have time to avoid this work.

[matt335672]

That's cool - we've all got other things to do

[matt335672]

With some rejigging, I've got this:-

and:-

Code is on the usual branch.

It shows what's possible, but I'm not at all happy that the user has to hack the xrdp.ini file about to get this to work. It makes upgrades harder (which is not good), and on shared servers with some high-res displays and some low-res displays there are still no good solutions.

I think a better solution might be to work out a font to load for the display, and then apply a scaling factor to the parameters in xrdp.ini so that the user doesn't have to edit anything. Initially we can go with a couple of fv1 fonts, and then later work out how to properly use a TrueType font.

@TOMATO-ONE - I'd appreciate your thoughts on this.

[TOMATO-ONE]

@matt335672
Thanks for the excellent work.

I was thinking of allowing the administrator to define it manually in xrdp.ini.
But that was only because I thought my programming skills could handle it (if I spent a lot of time).

As you claim, adding more configuration items to xrdp.ini unnecessarily is not a good practice.
I agree with your idea that the goal is to eventually introduce TrueType fonts, and in the process switch fv1 to use them.
I think this is a realistic and appropriate plan.

[matt335672]

My current plan is:-

• Move the xrdp front-end size-based config options (i.e. widths, heights, x and y values) into a separate struct
• Have two instances of the struct called 'unscaled' and 'scaled'
• Populate 'unscaled' values from the config.
• When the client sends over its monitor configuration, work out (initially) which one of two fv1 fonts to use.
• Populate the 'scaled' values from the 'unscaled' values using the font info.
• Build the front-end from the 'scaled' values.

It's quite a bit of change, but I can do it in several bits. The result should be something that works with existing configurations, and which can be moved to TrueType fonts quite easily later on.

[matt335672]

First three bits now done. More work required though.

[matt335672]

More scaling work. I've moved more scaling values to the struct, and tries to get most of the scaling code in one place. The login box and the (disconnected) help box now work OK.

Next step is to make the font load dependent of the client.

[matt335672]

More internal stuff done now that I didn't know I needed to do.

When xrdp is built with --disable-painter, the front end fonts are drawn using orders and the glyph cache. These weren't areas I was familiar with, so it's taken me a while to get them working properly.

The font utilities are also updated, but the manpages aren't. I'm going to get those done next.

The next thing before this is ready for more serious testing is the font selector. My current thinking is that I use a string like the following in xrdp.ini

; Select a font for the login screen.
; This parameter is a comma-separated list of DPI:name pairs.
; The list is scanned from left-to-right. The font used is the first
; font whose DPI value is less-than-or-equal to the vertical DPI of
; the monitor used for the login screen.
#fv1select=130:sans-18.fv1,0:sans-10.fv1

I'm just sticking with two fonts for now in the standard distribution, as these files are still quite large - I think sans-18.fv1 should be quite readable on a 24 inch 4K monitor which is around 183dpi I think. Users can add others if they feel the need.

What do you think @TOMATO-ONE ?

[TOMATO-ONE]

I think it's good.
I'll take a closer look this weekend.

I salute your continued work.

[matt335672]

Another update - the code to read physical monitor sizes is somewhat incomplete in xrdp_sec.c. In particular, the TS_UD_CS_MONITOR_EX PDU is not processed during client startup, and as a result, with a two screen Windows client, the DPI information is not available.

This needs to be fixed, as this is a fairly common configuration. I'll work on a separate PR to implement the processing of TS_UD_CS_MONITOR_EX, and then rebase by font work off of that one.

[matt335672]

Sorry about the radio silence @TOMATO-ONE. I've been away, and then I caught something nasty. All OK now.

I've just pushed an update to the branch which I think is just about there. It adds a font file sans-18.fv1 which it loads for 130 DPI or more. The login screen is scaled appropriately. Minor changes only are needed for the config files.

It needs a bit more work, to better document the fv1 file format, and to sort out the commit history which is a real mess.

Feel free to give it a go and let me know what you think.

[matt335672]

I've had a look with a Windows 10 21H2 client, and the behaviour seems to be as follows:-

1. Full-screen multiple monitors - Complete size information is sent for all monitors using the Client Monitor Data PDU and the Client Monitor Extended Data PDU
2. Full screen, single monitor - Complete size information is sent in the Client Core Data PDU
3. Partial screen session - The desktop size is sent, but the physical components are zero, so the desktop DPI cannot be calculated.

Also:-

4. Connect full screen single monitor, cancel on xrdp, then connect partial screen - the physical size is sent by the client in this instance!

So the sending of the physical size in case 4) appears to be a bug in the RDP client.

After all this, I think my actions are:-

1. Improve logging for "unable to calculate DPI"
2. Possibly, do not scale the login screen for small desktop resolutions

Does this make sense @TOMATO-ONE? I appreciate I've not presented this information very clearly.

[TOMATO-ONE]

@matt335672
Thank you for your detailed explanation.
I understand.

I have tried the following method.

I created a 14-point fixed font sans-14.fv1 with xrdp-mkfv1 and copied it to /usr/local/share/xrdp/.
Next, I put the following settings in xrdp.ini

fv1_select=160:sans-18.fv1,130:sans-14.fv1,0:sans-10.fv1
default_dpi=96

This gives the following 800x600 pixel screen on a CHUWI 8" tablet

Your excellent code works very well.

Support for small desktop resolutions in a HiDPI environment is
Attaching a 14-point font and adjusting the scaling threshold by the user is sufficient in my opinion.

[matt335672]

That's great news @TOMATO-ONE.

Thanks in particular for the testing you've done in this area - it's really important as developers like me never completely understand how users actually want to use the software.

I'll work on sorting out a proper PR for review now with the changes you've helped me with. If you've got any additional comments at that stage, feel free to add them.

[matt335672]

PS - I'll probably disable scaling if the vertical window size is less-than (say) 768 pixels. This won't be a monitor these days, and otherwise we'll get caught by the MS bug I mentioned above.

[TOMATO-ONE]

Thank you for your dedicated work.
I am happy to have contributed to the improvements.

[matt335672]

See #2341

[matt335672]

THe above PR has now been merged into devel. See also https://github.com/neutrinolabs/xrdp/wiki/Scaleable-login-screen

[TOMATO-ONE]

@matt335672
Thank you for your excellent work!!