From ArchWiki
(Redirected from Talk:Xorg Input Hotplugging)
Jump to: navigation, search

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 xorg-server uses several patches (see [1]). 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 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 to be fixed, which means letting the server automatically as it already knows how make logical and physical DPI match. is one place that shows how to perform the calculations.
"To reduce scaling artifacts to GUI that use bitmaps" is not the only reason to choose +25% steps (96, 120, 144, 168, 192...). Most scalable fonts are tuned to 96 DPI, and step from pixel size to pixel size best at specific steps, of which +25% are the best. Mrmazda (talk)
I question the validity of the claim that Xorg always sets the DPI to 96 mainly because of this issue: 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 laptop---1280x800@14.1in 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: —This unsigned comment is by Jristz (talk) 05:40, 19 April 2016 (UTC). Please sign your posts with ~~~~!

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 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)

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 xorg-xhost 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.
As for where this should go? I have no idea. Earnest (talk) 23:54, 13 March 2016 (UTC)

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