Setting DPI manually
I'm not an Archlinux user, but Google sends me to this Wiki often. As a non-user, I cannot confirm this error on Archlinux unless I find time to learn how to install it. That's unlikely to happen in the foreseeable future.
The example 'Option "DPI" "96 x 96"' is invalid, because 96 x 96 is forced by the Xorg Xserver to start with as default to match Mac and Windows.
Unless the Archlinux X servers are different from other distros I've used, Option "DPI" "120 x 120" and others (144, 192, 108, etc) AFAICT only work for users of proprietary NVidia drivers, fail for certain on MGA (e.g. G400), Intel (e.g. 810, 845, 865, 915, 945, 3000, 4000), Radeon (e.g. rv200, rv250, rv380) & Nouveau (e.g. nv11, G84) on openSUSE 12.2, openSUSE 13.1, Fedora 20 and Mageia 4. I've been using Xorg for many many years and have never yet found any version in which this option is valid using any of the 4 FOSS drivers indicated. Mrmazda (talk) 05:25, 10 December 2013 (UTC)
- As you probably noticed, Xorg#Display_size_and_DPI is marked as inaccurate with links to several bug reports about Xorg forcing 96x96. Part of Arch's philosophy is to avoid patching of packages whenever possible, but I see that uses several patches (see ). I don't know which patches other distros use, but this option is not likely to depend on the patches.
- Anyway, if you know a functioning method of manually setting DPI, feel free to share it - even a link to external documentation might be better than the current inaccurate information.
- -- Lahwaacz (talk) 07:34, 10 December 2013 (UTC)
- As help situations arise I point people to my http://fm.no-ip.com/Share/DisplaySize which is mostly a lookup table designed to avoid need to calculate values for DisplaySize that will produce a desired DPI. DisplaySize in 'Section "Monitor"' has been reliable long-term with non-broken drivers, but since KScreen was released last summer, a workaround is required to get xorg.conf* to be obeyed at all by KDE. According to Alex Fiestas, KScreen 1.1 is proposed to allow xorg.conf* to be obeyed by default on single display systems. The workaround is to put [Module-kscreen]\nautoload=false in kdmrc. Whether other DEs have similar obstacles I have no idea. It would really be nice for those only wishing to force the hardware native DPI instead of an arbitrary one (which is usually what 96 is) for https://bugs.freedesktop.org/show_bug.cgi?id=41115 to be fixed, which means letting the server automatically as it already knows how make logical and physical DPI match. http://www.gentoo-wiki.info/HOWTO_Set_DPI_Dots_Per_Inch is one place that shows how to perform the calculations.
- I question the validity of the claim that Xorg always sets the DPI to 96 mainly because of this issue: https://bbs.archlinux.org/viewtopic.php?id=197624. Quite a lot of people are having problems with the latest versions of Chromium because Xorg is not automatically setting the DPI to 96, and Chromium is now high-DPI-sensitive. The result is really bad font and bitmap scaling on most webpages. —This unsigned comment is by Silverhammermba (talk) 20:17, 5 June 2015. Please sign your posts with ~~~~!
- Having fought this problem with a gen4 Intel email@example.com LVDS---over the last two days, I reread the man page and found the newish option "ReprobeOutputs". After enabling, the driver correctly detects the panel geometry and size for slightly rectangular pixels and DPI higher than 96x96. This suggests that udev's hardware probing is failing to detect the real hardware configuration or Xorg server is failing to process the information correctly. Unfortunately neither the ati not nv drivers allow for direct reading of the EDID information and you are left to resort to the kind of monitor configuration hackery mentioned above. Vorbote (talk) 14:17, 7 October 2015 (UTC)
- I did some experiments in my Radeon HD6310 and discover somethings... lets start:
- efectively, set the dpi in the xorg file is meaningless, as is ignored
- set the CORRECT size for you screen, the size taked manually with rule and seting the correct resolution (if not detected) WILL affect the Xorg dpi.
- My monitor is 1366x768 with 309x174 millimeters, those were measured either with software and with my oun measuring rule here in RL, then I set them in Xorg and then the dpi change from 96x96 to 112x112. I use this page to help me: https://www.sven.de/dpi/
- —This unsigned comment is by Jristz (talk) 05:40, 19 April 2016 (UTC). Please sign your posts with ~~~~!
- I did some experiments in my Radeon HD6310 and discover somethings... lets start:
- If you are having problems with Xorg DPI, be sure to check if any programs are overriding your settings. In my case for example: I found that Xorg actually was respecting the DisplaySize entry in the config file, but xfsettingsd (a component of xfce) was setting this back to 96 DPI immediately after I started Xorg. See https://bugzilla.xfce.org/show_bug.cgi?id=10633 for some discussion of this behavior which is hardcoded into xfsettingsd. Apparently this is their solution for dealing with the possibility of a "Screen" spanning multiple monitors, each of which may have different sizes and/or resolutions (DPI). Running xrandr --dpi XXX after xfsettingsd is started is a workaround, but I think the long-term solution is to file bugs against applications, such as evince, which are incorrectly relying on the "Screen" DPI reported by Xorg. Dc46and2 (talk) 02:34, 9 June 2016 (UTC)
- In July 2015, a patch was submitted to GTK3 that forces Xft.dpi to 96 whenever 'xrdb -query | grep dpi' would return a null Xft.dpi value. https://bugzilla.gnome.org/show_bug.cgi?id=757142 was filed when the impact of the change became apparent. It was immediately wontfixed. Xft.dpi is not required for Xorg functionality, being an interloper created by the Gnome people(?) as a tool to force DPI, the Gnome device for scaling its UI. The impact of this patch started to become more widely apparent when GTK3 became the default Firefox release build toolkit in 2016, most commonly among users of physical display densities between 96 and 192. I filed Mozilla bug 1269274 "GTK+ 3.18 - UI text sizes no longer inherited from Linux system" on account of this. It too was promptly wontfixed. Users of both GTK libs >3.16 and DEs that don't depend on Xft.dpi but instead utilize whatever >96 DPI logical density to which Xorg is configured find UI fonts in Firefox 46+ smaller than non-GTK3 apps, appreciably so even with configured density as low as 108 DPI. Such users not used to having Xft.dpi set, e.g. KDE users, will need to set it to match their Xorg DPI if they want supported GTK3-built Firefox (or SeaMonkey and/or Thunderbird) releases to have UI text matching their other apps. In KDE it's not a hard thing to do, because Xft.dpi is the means through which forced DPI in its systemsettings is implemented, but it will require manual intervention to keep Xorg and Xft.dpi in sync when switching among displays of different densities. Alternatively, and with other non-Gnome users, Xresources can be utilized to manage Xft.dpi, as explained on the parent page. Mrmazda (talk) 06:45, 1 February 2017 (UTC)
Add xhost si:localuser:$USER ?
Access to the X server is usually regulated via the hostname, so if it changes unexpectedly (e.g. see BBS#202704, Connman#Avoid_changing_the_hostname), things stop working. The user name is (or should be) less prone to change, so you could use for access:
$ xhost si:localuser:$USER
man Xsecurity says on this:
localuser & localgroup On systems which can determine in a secure fashion the credentials of a client process, the "localuser" and "localgroup" authentication methods provide access based on those credentials. The format of the values provided is platform specific. For POSIX & UNIX platforms, if the value starts with the character '#', the rest of the string is treated as a decimal uid or gid, otherwise the string is defined as a user name or group name. If your system supports this method and you use it, be warned that some programs that proxy connections and are setuid or setgid may get authenticated as the uid or gid of the proxy process. For instance, some versions of ssh will be authenticated as the user root, no matter what user is running the ssh client, so on systems with such software, adding access for localuser:root may allow wider access than intended to the X display.
However, X apps failing is the symptom; the cause lies in Network configuration, or an issue with the (static) hostname not being respected. So I'm not sure where to mention this, if at all. One way would be to expand Xhost and add a link there under Xorg#Troubleshooting. -- Alad (talk) 17:51, 21 September 2015 (UTC)
- For what it's worth using xhost is probably prefered (for example GDM does this) as xauth was mostly used in an era when hostname changing was very rare. I'm now using xhost instead of maintaining xauth along with the accompanying xauthority file which reduces quite a few dependencies on my end.
Location of Xorg.0.log
On my desktop with Gnome 3 and my laptop with KDE 5, my `Xorg.0.log` file is only located in `/var/log/Xorg.0.log`. In the article the location goes back and forth between:
There is a note at the end," `/var/log/` or, for the rootless X default since v1.16, in `~/.local/share/xorg/`". Shouldn't we pick one and put this note at the start? ---- unsigned, by User:Slacka, 20170112
Reverted edit by Alad: "useless without reference, i.e. a bug report " And why is it not enabled without KMS in the first place? Who says problems with forced rootless xorg are a bug, and not a technical limitation by design? Aufkrawall (talk) 16:14, 6 November 2017 (UTC)