Talk:Xorg

Xinput and how-to about InputClasses

Shouldn't this page also say something about how you are supposed to look for the properties that you can actually put in the conf files? I mean, there's no way you can "guess" which properties each device you own has or how xorg "identify it" to use the the Match* option. Maybe a reference to another page (non-existent atm) could help.

The closest thing I've found is the Mouse acceleration page, so it could work as a start. —This unsigned comment is by Pabloxcl (talk) 21:48, 21 August 2012‎. Please sign your posts with ~~~~!

As long as you comply with Help:Style#Hypertext metaphor you are free and encouraged to add whatever you want and especially link to other related articles if relevant. In particular, Mouse acceleration is what is called an "orphan" article, meaning that it's not linked from any other (which is usually bad), so if you can fix that it's nothing but a good thing ;) -- Kynikos (talk) 16:05, 23 August 2012 (UTC)

Close. Page link added. Configure option is referenced in man xorg.conf.--Fengchao (talk) 01:47, 12 December 2014 (UTC)

Sample configurations

Anyone who has a verified working current or unique xorg.conf file written up that works, go ahead and post a link to it here for others to look at. Please do not in-line the entire configuration file; upload it somewhere else and link to it.

Please post input hotplugging configurations only, otherwise note that your config is not using input hotplugging. (Xorg 1.8 = udev) (From original editor on the article's section in question. AdamT (Talk) 00:09, 24 August 2013 (UTC))

Most users do not need to touch those configure file right now. Is there any need to link to a sample file?

Is there any change between the sample file and system default? If no, we should remove them. If yes, it should provide the reason for such change.

--Fengchao (talk) 02:00, 12 December 2014 (UTC)

From my experience, xorg.conf is completely unnecessary for open-source drivers, but certain proprietary tools like nvidia-xconfig insist on creating it. The configuration can be manually split into files under /etc/X11/xorg.conf.d/, but it takes extra work.

Anyway, linking to sample configurations makes little sense considering that all the relevant options are explained in ATI, NVIDIA, Xorg#Multiple monitors etc.

-- Lahwaacz (talk) 08:15, 12 December 2014 (UTC)

I agree it's better for users to create their own files, or adapt sections, instead of copying complete "samples" they don't understand, or are not compatible to their particular setup. As we've had enough input on this, I've removed the section. Closing. -- Alad (talk) 12:37, 12 December 2014 (UTC)

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

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

Running / Manually

I'd like to rework this section. My suggestion would be to give a brief overview of how to start X manually using 'startx' and killing it appropriately (as of 1.16). I'd suggest, describing switch to console and then 'killall xinit'. This would basically be useful for beginners in order to test their graphical drivers. IIRC there was a section about this in the begginers guide I found very good. Unfortunately I couldn't find it currently, I think it was reorganized (???). Then for correctly setting up .xinitrc direct to the xinit wiki page. I'd remove the note about pkill, IMHO it's confusing and not needed in this context. Any objections ? Rebootl (talk) 13:09, 31 August 2014 (UTC)

I'm using dwm as my wm and it has a keybinding to exit (kill) X. It's possible to execute it blindly, e.g. when you get just a black screen. You can also set up a wm-agnostic key-combo to terminate X in your ~/.xinitrc: setxkbmap -option terminate:ctrl_alt_bksp. -- Karol (talk) 17:41, 31 August 2014 (UTC)

Not sure how killall xinit is any improvement over pkill, as both kill all X instances. Use a WM specific method or the terminate option as Karol said, or the PID from xprop. Only terminate: is not mentioned in the article. -- Alad (talk) 18:10, 31 August 2014 (UTC)

Ok, thanks for your feedback. I agree that using killall xinit isn't really better. I just tested and the pkill command still works. The binary executed is /usr/bin/Xorg.bin in any case. So maybe the dispute banner could be removed, maybe it was especially this disturbing me... My idea would've been to make this very simple/straightforward. More advanced methods like terminate would go into the xinit article. Rebootl (talk) 18:56, 31 August 2014 (UTC)

My initial motivation for this was the apparently quite confused user in this thread: https://bbs.archlinux.org/viewtopic.php?id=186437 I'm aware that there is a specific problem and he's actually trying to use a DM (not manual starting), but as mentioned above I'm still somewhat missing the basic instructions that I remember from the begginers guide I can't find anymore...

For example: It says nowhere that during the setup of the graphical interface it may be better/ a lot easier to debug/ when using manual starting first. If everything is working only then start to use a display manager! That's a general problem I find after the reorganisation of the beginners guide (of how I remember it). The users are guided very detailed through the installation but then after that, they are all of a sudden supposed to know what they want. But how can they. Can you see what I mean? Thanks. Rebootl (talk) 19:16, 31 August 2014 (UTC)

The part of the BG you are looking for is probably this old revision; the change that happened is that the multi-part guide (Preparation, Installation, Post-installation) was merged into a single wiki page (previously the main sections were maintained on separate pages and transcluded onto the main page). But I don't see any mention of systemctl start vs systemctl enable there. -- Lahwaacz (talk) 19:29, 31 August 2014 (UTC)

Yes, exactly that was it, thank you very much. Especially the Test X part there (https://wiki.archlinux.org/index.php?title=Beginners%27_guide/Post-installation&oldid=291951#Test_X), also note the friendly Tip: to use this when installing Arch for the first time.

No, sorry, I didn't mean the systemctl commands, I meant starting X manually (using 'startx') instead of starting with a display manager. This may as well not be specifically mentioned in the old guide, but note that this is what happens, when simply following it (that's even better). Whereas now, sorry to say, one simply get's a bunch of links to other wikis that contain links to other wikis again...(a bit exaggerated) I understand that restructuring may be needed but I think some information was lost here. Or as trying to explain above some basic guidance of what is best to do next is lacking.

Thanks again. Rebootl (talk) 20:38, 31 August 2014 (UTC)