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

Tue Oct 4 15:43:37 BST 2016

On Tue, Oct 4, 2016 at 4:52 AM, Antoine Martin via shifter-users <
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.

>
> > In a prior thread, I mentioned that since I don't have admin privileges,
> I
> > manually extracted the following rpms
> > https://www.xpra.org/dists/CentOS/6.6/x86_64/ :
> (snip)
> BTW, you don't need all of those RPMs installed, only the ones that are
> required for installing the main "xpra" package. See:
> rpm -qpR xpra*rpm
>
> > Specifically, I created a directory named on a shared disk
> > (i.e. <my_xpra_extract_directory>) and extracted the files in each
> package
> > in such a way that this directory was effectively the root directory. For
> > example, the *.so files were extracted to
> > '<my_xpra_extract_directory>/usr/lib64' directory tree.
> >
> > I found all of the directories to which I had extracted *.so files and
> > added those directories to LD_LIBRARY_PATH.
> >
> > When running certain X applications, I get the following error message,
> > although the application appears to run fine:
> >
> > ERROR: ld.so: object
> > '/projects/avenger_de1/thomase/xpra/usr/lib64/libfakeXinerama.so.1' from
> > LD_PRELOAD cannot be preloaded: ignored.
> See:
> http://xpra.org/trac/wiki/FakeXinerama
> Things should work reasonably well without it.
>
> > 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.
>
> > 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>
> 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. 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. 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. 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".

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.

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.

>
> 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
> 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
>
> Cheers
> Antoine
>
>
> >>
> > _______________________________________________
> > shifter-users mailing list
> > shifter-users at lists.devloop.org.uk
> > http://lists.devloop.org.uk/mailman/listinfo/shifter-users
> >
>
> _______________________________________________
> shifter-users mailing list
> shifter-users at lists.devloop.org.uk
> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>