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 <[email protected]> wrote: > On 04/10/16 21:43, Thomas Esposito wrote: > > On Tue, Oct 4, 2016 at 4:52 AM, Antoine Martin via shifter-users > > <[email protected] > > <mailto:[email protected]>> 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 < > [email protected] <mailto:[email protected]>> 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 > > > [email protected] > > <mailto:[email protected]> > > > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > > <http://lists.devloop.org.uk/mailman/listinfo/shifter-users> > > > > > > > _______________________________________________ > > shifter-users mailing list > > [email protected] > > <mailto:[email protected]> > > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > > <http://lists.devloop.org.uk/mailman/listinfo/shifter-users> > > > > > > _______________________________________________ shifter-users mailing list [email protected] http://lists.devloop.org.uk/mailman/listinfo/shifter-users
