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)
- That's all vague conjectures. There's no point to relate CPU usage and KMS without the homework to prove there's an actual relation. -- Alad (talk) 16:20, 6 November 2017 (UTC)
The suggestion at https://wiki.archlinux.org/title/Xorg#Using_xinitrc does not explain why you should use
startx instead of
exec startx, which might lead to confusion among people who are new to configuring Xorg (like me). It's also suggested here that this section should be edited/moved. Garfa (talk) 17:01, 22 May 2021 (UTC)
Remove/replace/update the xorg.conf config section?
"Xorg -configure" is broken since years and nvidia-xconfig creates a bunch of cruft around the Device section. In addition static configuration and the monolithic xorg.conf are, if not even deprecated, causing trouble for unexperienced users by their unflexibility. It is common on the bbs to ask for the log and tell forum users to remove that file to "fix" things.
Good reasons (and how) to write a server config (yourself) are indicated in the multihead and optimus articles and I'd suggest to remove that section resp. replace it by an explicit warning to refrain from overriding the autoconfig unwittingly. Also it should be explained that "Xorg -configure" is known to be "broken" (I cannot prove it, but believe it to be "accidentally broken" as deprecated), the error is normal and you should not be using it anyway ;-)
Best place for eGPU configs
Greetings, I'd like to add the following critical piece of information that's not easily available on the internet - I had to find it in the Xorg logs when run with a specific config.
To get eGPU working with external monitor and internal one disabled:
- Install the correct version and build of drivers (nvidia or nvidia-dkms or equivalent for other makes)
- Use something like the following for the Xorg config:
Section "Module" Load "modesetting" EndSection Section "Device" Identifier "nvidia" Driver "nvidia" BusID "PCI:6:0:0" Option "AllowEmptyInitialConfiguration" Option "AllowExternalGpus" EndSection
The critical thing is the Option "AllowExternalGpus". The existence of this isn't documented on the threads on nvidia support, or on egpu.io. First section turns off the internal display. If that's missing the systemd output will stay on screen, frozen. Nothing else is necessary, no DM config files, or nvidia-xconfig, or adding drivers to KMS, or using secure TB3 like Da_blitz's guide suggests.
This was particularly infuriating because the device is easy to work with, send CUDA processes to, and nvidia-xsettings --query-gpu-info recognizes the external monitor. Yet xrandr doesn't. And using most configs crashes Xorg with a multitude of errors, from "No screens found" to "no usable config", to "Failed to get display number from pipe". All were rabbit holes. This info needs to be out there somewhere.
Whats the best place to add this information? I was thinking under either NVIDIA/Tips or config or Xorg/Tips or config or start a new page "External GPUs"
- Since it is specific to the NVIDIA driver, add it to NVIDIA/Tips_and_tricks. -- Lahwaacz (talk) 18:41, 11 August 2018 (UTC)
systemctl --user in rootless Xorg
systemctl --user to work (as well as a device management I guess) with the rootless Xorg setup, I had to edit
/etc/pam.d/system-login so that
pam_systemd.so is required (that is remove the
- in front of
session and change
required). I am not sure why this isn't the default somehow. -- Kalessin (talk) 19:28, 6 November 2018 (UTC)
- to get
systemctl --userto work
- not sure what you mean by that but i use --user for cron like jobs without changing
/etc/pam.d/system-login--Ubone (talk) 09:07, 7 November 2018 (UTC)
As discussed in Talk:Wayland#XWayland, I would like to add a small section for XWayland.
Technically it is a part of the XServer, so where would you like it better, here or at Wayland?
generic video driver
previously under BIOS, there was the VESA graphic mode : this mode did not use all the available video capabilities but worked and often allowed to launch the graphic interface whatever the underlying video card.
VESA is no longer usable under UEFI (vesa: Refusing to run on UEFI in Xorg.0.log) : is there an equivalent for UEFI ? is it the modesetting driver (modesetting_drv.so) ?