x11: Implemented dpi detection

[27thLiz]

depends on XRandR

[27thLiz]

Mhh, how can the travis build find the header, but then doesn't have XRRMonitorInfo? Don't tell me it's not available in that version...

[akien-mga]

Hm, travis uses Xrandr 1.3.2, from 2009... i.e. this header: http://code.metager.de/source/xref/xorg/lib/libXrandr/include/X11/extensions/Xrandr.h?r=59c8812099f33d56b43044f999ffe5df16adf5ff
Indeed it lacks XRRMonitorInfo (it was maybe in another header back then, as I still find reference to it in Google from < 2008).

It would be nice to get new versions of those libs while keeping the glibc from 12.04 LTS :P

[akien-mga]

Looks like there might be a way to install the Xorg stack from 14.04 LTS on 12.04 LTS: https://pkgs.org/ubuntu-12.04/ubuntu-updates-main-amd64/libxrandr-dev-lts-trusty_1.4.2-1~precise1_amd64.deb.html

Would need someone with a bit more Ubuntu experience than I have though to find the proper package names to update (I guess we can't update just xrandr and keep the older xorg).

[27thLiz]

Alright, nice. I was about to load the symbol(s) at runtime, but updating the package would be a lot cleaner ^^

[akien-mga]

It doesn't work sadly, I gave it a try but it's not on the whitelist of Travis: https://travis-ci.org/godotengine/godot/jobs/133926740

We are using the container-based environment which is Travis' recommended build environment: https://docs.travis-ci.com/user/ci-environment/

On the other hand for the official builds on https://travis-ci.org/GodotBuilder/godot-builds we are using the Trusty (Ubuntu 14.04 LTS) platform, so there the xrandr version should be new enough hopefully.

So we could go back to the trusty forever-in-beta platform, but those are more limited and have lower priorities, so it might have a negative impact on our CI overall :(

[27thLiz]

Symbol loading it is then^^
It's just one function anyway, also that way we can fall back to XRRSizes if XRRGetMonitors is not available. We can't default to XRRSizes tho, as it only works for the first screen.

[27thLiz]

Ok, builds now.
Will need to list libxrandr-dev as a dependency in the docs.

[slapin]

Well, as X11 headers from Keith Packard and co often change in incompatible way
I think it is better to use standard way which works for both old and new Xorg.. The struct itself was made public in Xorg.commit 4109f29861a7066970a2afd079d0fc2c12828bcb
when was added do xrandrproto.h
This indicates only Xrandr monitor information. X11 does have support for multiple monitors from beginning, as well as GLX and OpenGL. I think Godot display should fallback on root window geometry
knowledge and/or configuration settings for these if relatively new Xrandr monitor API is not available.

[27thLiz]

X11 does provide some geometry information via GetDisplayWidthMM() and GetDisplayHeightMM().
In my tests however, these methods were not useful at all. The width I got for my 12" screen (243mm) was 707mm... So I don't know how much help such a fallback would be.
But If you know of any other ways to get this information without xrandr, please let me know ^^

[slapin]

The problem is generally because in all distros the X server DPI is
hardcoded to 100 or 120 due to how hacked the Keith Packard code is.
Apple had their fix for that in, but they won't share (probably hacky too),
this is due to how screen fonts worked at time of hacks,
and instead of fixing their code they decided to work it around and this
workaround is still here.
The only way to know real ppm (or ppi) is using EDID with current X11, no
standard interfaces will work, as hacks expect incorrect information
and many things will break if X server will provide real info. The EDID
information is only available via Xrandr, but in case
you can't access it you can fallback on configured values or standard
values (which might be correct or incorrect).
So my suggested path is: Xrandr -> configured values -> GetDisplayWidthMM()
I think Gimp works the same way, I don't see why we can't do this.
As real ppm values are only interesting in Editor i think this is way to go.
If for some strange reason a game will require real ppm values, these can
be provided via API,
so they can build similar constructions.

On Wed, Jun 1, 2016 at 5:09 PM, Hondres notifications@github.com wrote:

X11 does provide some geometry information via GetDisplayWidthMM() and
GetDisplayHeightMM.
In my tests however, these methods were not useful at all. The width I got
for my 12" screen (243mm) was 707mm... So I don't how much help such a
fallback would be.
But If you know of any other ways to get this information without xrandr,
please let me know ^^

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#4905 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAAX0xVxdN7s6B3e42EuuebFqt9Jlv8wks5qHZKegaJpZM4IpuLa
.

[cart]

The arch wiki has some relevant info. You could just try querying all of the different dpi sources mentioned in the wiki: X11 (xdpyinfo?) , gnome (gsettings), and toolkit environment variables (GTK = GDK_SCALE, QT = QT_AUTO_SCREEN_SCALE_FACTOR). I've never tried detecting dpi programmatically on linux so im afraid I won't be much help.

[cart]

Chromium's xrandr implementation: https://code.google.com/p/chromium/codesearch#chromium/src/ui/views/widget/desktop_aura/desktop_screen_x11.cc

[vnen]

@mcanders Seems to be using GTK: https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/ui/libgtk2ui/gtk2_ui.cc&sq=package:chromium&l=433&rcl=1464895056

[cart]

I'm guessing GTK just pulls that info from GetDisplayWidthMM() so maybe thats the best way to go. xdpyinfo uses that method https://cgit.freedesktop.org/xorg/app/xdpyinfo/tree/xdpyinfo.c.

[reduz]

how's the status of this?

[27thLiz]

Ok, added the fallback method.
We can always add support for reading the user config/env-overrides at a later point, if desired.
But imho, this should do for now.