[winswitch] neither --dpi switch or dpi setting in xpra.conf allows me to set the DPI to fixed value
Thomas Esposito
tmesposito00 at gmail.com
Wed Oct 5 20:14:20 BST 2016
Adding the path to the usr/lib64/xorg/modules/drivers directory of my local
install to the LD_LIBRARY_PATH was not enough to force Xorg to use the
patched dummy driver. However, I discovered that I could add a "ModulePath"
line to my xorg.conf in order to change the effective module search path.
So, the DPI problem is solved. Thanks for the help!
The next 2 issues on my list are:
1.) My terminal of choice has been gnome-terminal for a while. This is
version 2.31.3 on RHEL6.6. The problem is that, when I maximize the window,
the edge of the window appears to extend beyond the bottom edge of my
monitor. As a result, the bottom row of text in the terminal is mostly cut
off. When I maximize to an extended display in a dual-monitor setup, it is
not quite as bad and I can see about the top 75% of the bottom row of text.
I wonder if this has something to do with this particular X application
being forced to relatively coarse-grained sizing increments (i.e. in units
of text columns-rows), and then rounding up to the next size increment
rather than down when the maximized window size doesn't exactly match one
of these coarse-grained increments.
2.) This is a bigger issue. I'm finding that compared to TigerVNC, which is
the officially-supported remote X solution in my office (and doesn't
support per-application windows like xpra), is MUCH faster than xpra. I
haven't ruled out some kind of network QOS prioritizing VNC traffic over
ssh, but I wanted to ask what kind of performance I should be expecting
relative to something like TigerVNC. We also have FreeNX working (but
again, not with per-application windows), which supposedly uses ssh as
well, but FreeNX performance is at least as good as TigerVNC, if not
better. xpra is in a DISTANT 3rd place.
On Tue, Oct 4, 2016 at 11:23 AM, Antoine Martin <antoine at nagafix.co.uk>
wrote:
> 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