[winswitch] neither --dpi switch or dpi setting in xpra.conf allows me to set the DPI to fixed value

Antoine Martin antoine at nagafix.co.uk
Tue Oct 4 16:23:06 BST 2016 

On 04/10/16 21:43, Thomas Esposito wrote:
> On Tue, Oct 4, 2016 at 4:52 AM, Antoine Martin via shifter-users
> <shifter-users at lists.devloop.org.uk
> <mailto:shifter-users at lists.devloop.org.uk>> wrote: 
>     On 04/10/16 03:18, Thomas Esposito via shifter-users wrote:
>     > I'm not sure if this is related to my issue,
>     Probably is.
> 
>     > but I have reason to doubt
>     > that the shared libraries that I extracted from the rpm files are actually
>     > being loaded.
>     This may severely impact your experience: missing picture codecs, wrong
>     DPI, etc..
> 
> Actually, I think the one of the issues contributing to my DPI problem
> are that I can't seem to load the dummy_drv.so instead of the patched
> version from the rpm. I'm guessing that Xorg is using a hard-coded path
> to /usr/lib64/xorg/modules/drivers/, and using that without even looking
> at my LD_LIBRARY_PATH. I'm not sure there is any way around this without
> directly replacing the lib in /usr/lib64/xorg/modules/drivers.
Yes, like I said just below, use the patched dummy driver.
In your case, you may need to build your own patched Xorg server from
source to get it loaded.

(snip)
>     > Also, despite my LD_LIBRARY_PATH setting, my Xorg.:100.log file (I'm using
>     > display :100) reports that it is loading the standard
>     > /usr/lib64/xorg/modules/drivers/dummy_drv.so, rather than the patched
>     > driver in
>     > <my_xpra_extract_directory>/usr/lib64/xorg/modules/drivers/dummy_drv.so..
>     This will be the source of your DPI problems: you won't be using a
>     patched dummy driver.
^ See here.

>     > How can I be sure that any of the libraries that I have downloaded are
>     > actually being loaded?
>     That depends on how the application loads its shared objects.
>     In the case of Xorg, this is probably a hard-coded path you can do
>     nothing about. (and you probably won't be able to LD_PRELOAD it either)
> 
> Nope, I can't seem to LD_PRELOAD your dummy_drv.so (I get ERRORs). 
> 
> 
>     > On Mon, Oct 3, 2016 at 3:07 PM, Thomas Esposito <thomase00 at yahoo.com <mailto:thomase00 at yahoo.com>> wrote:
>     >
>     >> The fonts rendered by Xorg are very small, and I suspect the reason is
>     >> because the DPI is being set to an unreasonably low value (i.e. 42x28 now,
>     >> but varies depending on the monitor setup). Rather than deal with the
>     >> patched dummy driver, I'm assuming that I should be able to simply fix the
>     >> X DPI to a reasonable value (i.e. 96x96), since that is what I'm accustomed
>     >> to anyway, being a Windows user primarily. I know there are quasi-religious
>     >> arguments about a fixed DPI of 96, particularly with all the high-res
>     >> monitors available now, but I'd rather not get into that.
>     The issue you're hitting is that the applications you use do not honour
>     any of your DPI settings but they try to calculate their own "hardware
>     DPI" based on the monitor dimensions and screen resolution.
>     This never works well, which is why we have use a patched dummy driver
>     to simulate the "correct" values.
> 
> I'm not sure about this explanation.
OK.

> For example, when I use TigerVNC, I
> can set the DPI directly on the vncserver command line with the '-dpi'
> switch. When I do this, the "resolution" reported by xdpyinfo matches
> the value that I set on the command line. More importantly, when running
> the very same X applications that I am having DPI problems with when
> using xpra, the Xvnc server fonts scale EXACTLY according the the
> reported "resolution" value (at least when application requests a
> DPI-scaled font). When using xpra (at least without the patched
> dummy_drv.so), the "--dpi" switch has absolutely NO effect on the
> "resolution" reported by xdpyinfo. Rather, it seems to ALWAYS be
> calculated based on the Modeline resolution and the DisplaySize (I think
> we agree on this). In particular, what doesn't make sense to me is the
> idea that individual X applications will be doing their OWN DPI
> calculation. According to my understanding, the X application simply
> asks the X server to render a font.
Those days are long gone, "most" applications use toolkits nowadays and
not X11 core rendering.

> It may asks for an unscaled font
> (e.g. RHEL6 xemacs seems to do this), which will always be rendered the
> same regardless of DPI, but otherwise it is up to the X server how to
> render it based on its own understanding of DPI. It seems that the issue
> is NOT that some X applications calculate their own DPI, but rather that
> the X server itself (when using the standard dummy_drv.so) effectively
> IGNORES the DPI switch that Xorg was started with and instead calculates
> it based on Modeline resolution and DisplaySize.
Almost, but not quite: the dpi is not ignored, it is scaled.
When the client connects, the dummy virtual screen is resized to match
your client's resolution as best we can, and at that point the dummy
screen does have a "fixed virtual size" of sorts.

ie with trunk: when we change the default ~8K resolution down to
1080p... the original DPI value is divided by ~4.

The patched dummy driver will not only keep the DPI constant when the
screen is resized, it will also try to honour the value supplied by the
client. (obviously, not all clients have the same DPI settings)

> I suppose that the end
> result is ultimately the same, and dummy_drv.so needs to be fixed in
> such a way that it respects the DPI. As you say, I imagine that if I was
> actually able to use the patched dummy_drv.so (it seems I can't though),
> I would see that the "resolution" reported by xdpyinfo is what I have
> requested and DPI-scaled fonts will look "right".
Yes, that's why it's there.

> Ultimately, I believe that the only input the individual X applications
> provide into the equation is effectively binary. That is, it either
> requests a scaled on un-scaled font.
> Also, I think it's confusing to refer to the X server DPI and Xft.dpi in
> the same context. These are associated with 2 TOTALLY different font
> rendering systems. Xft is for modern client-side (i.e. X application
> side) font rendering. This is totally independent of the X server DPI
> and it explains why I don't have any problems with the fonts in my
> gnome-terminal for example.
As far as xpra is concerned, whether the forwarded applications will be
using X11 rendering or client-side rendering is totally irrelevant: all
options must be supported.

So we synchronize all the DPI settings we can get our hands on in the
hope that all applications will render using the correct settings.
In some cases, this requires a patched dummy driver be achieved.

> All that being said, forgive me if I'm being presumptuous. ;-) I can
> certainly be convinced otherwise, but right now, something just isn't
> adding up regarding this explanation. 
There should be enough information above, otherwise there is *a lot*
more on the wiki and the DPI related tickets.

Cheers
Antoine


>  
> 
> 
>     If you want to fix this without using the patched dummy driver, your
>     only option is to edit your etc/xpra/xorg.conf and change the
>     DisplaySize of the monitor to get the desired DPI value:
>     https://wiki.archlinux.org/index.php/xorg#Display_size_and_DPI
>     <https://wiki.archlinux.org/index.php/xorg#Display_size_and_DPI>
>     This will not adapt when you connect clients with different resolutions.
> 
>     You may also want to try to switch to Xvfb instead of Xdummy by changing
>     the "xvfb=" line in your xpra config file.
> 
>     >> Anyway, I've attempted to fix the Xorg DPI by using the '--dpi=96' switch
>     >> on the xpra command line AND by uncommenting the 'dpi = 96' line from the
>     >> default xpra.conf file included with the install (which I have copied to
>     >> ~/.xpra/xpra.conf). In both cases, this does not seem to have any effect,
>     >> and my fonts and DPI remain unreasonably small.
>     >>
>     >> What am I missing?
>     >>
>     >> Also interesting, although most likely unrelated,
>     It is related and very relevant, but sadly it is also ignored by many
>     applications.
> 
>     >>is the output I get when
>     >> running 'xrdb -q':
>     >>
>     >> gnome.Xft/DPI: 98304
>     >> Xft.hinting: 1
>     >> Xft.antialias: 1
>     >> Xft.dpi: 96
>     >> Xft.rgba: none
>     >> Xcursor.size: 21
>     >> Xft/DPI: 98304
>     >> Xft.hintstyle: hintmedium
>     >>
>     >> I know the DPI here is for client-side/fontconfig fonts and is unrelated
>     >> to Xorg-rendered fonts, but I find the value of 98304 to be strange here.
>     That's the DPI value multiplied by 1024, see:
>     https://wiki.debian.org/MonitorDPI <https://wiki.debian.org/MonitorDPI>
> 
>     Cheers
>     Antoine
> 
> 
>     >>
>     > _______________________________________________
>     > shifter-users mailing list
>     > shifter-users at lists.devloop.org.uk
>     <mailto:shifter-users at lists.devloop.org.uk>
>     > http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>     <http://lists.devloop.org.uk/mailman/listinfo/shifter-users>
>     >
> 
>     _______________________________________________
>     shifter-users mailing list
>     shifter-users at lists.devloop.org.uk
>     <mailto:shifter-users at lists.devloop.org.uk>
>     http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>     <http://lists.devloop.org.uk/mailman/listinfo/shifter-users>
> 
>

More information about the shifter-users mailing list