Actually, I'm a bit confused what the correct location of this file in Gentoo is; it's referred to under different names in different places: /etc/X11/xinit/xinitrc and /etc/X11/xdm/Xsession look for /usr/X11R6/lib/X11/xinit/.Xresources /etc/X11/Sessions/Xsession looks for /etc/X11/Xresources and /etc/X11/xinit/Xresources Anyway, tried them all and they are all ignored when using xdm as well as startx. Calling xrdb manually works though!
After talking with hax on #gentoo, I came up with this: If ~/.xinitrc exists, the system xinitrc won't be called, which means the Xresources stuff won't be read, wherever it is, unless your ~/.xinitrc says to read the Xresources files. Does ~/.xinitrc exist? I'm not sure whether both the system xinitrc and ~/.xinitrc should be read, or if the system xinitrc should be ignored if ~/.xinitrc exists. Comments, anyone?
Reporter, are you using xfce3? Xfce comes with its own set of xinitrc/xclients files that do not look for Xresources, neither system-wide nor per-user. Spyderous: As for global/per-user xinitrc, traditionally if ~/.xinitrc existed, it used to be used intead of the global file (usually users would copy the global one to their home and make their customizations)... although I'm almost sure I've seen a setup that treats ~/.{Xclients,xsession} as a separate session type that users can select in kdm,gdm,... (not sure what distro did that and what happens if the user didn't have personal copies of these files...I'll have to do some research here...)
Umm... please ignore the first part of Comment #2. That was supposed to read "does not look for Xressources[...] IFF X is started with `startxfce'", but since you've said your using startx...please ignore that question.
Lots of questions... 1. No, I don't have ~/.xinitrc 2. Yes, I'm using xfce 3. No, I don't use startxfce Odd thing is, ~/.Xresources IS used, even IF I use startxfce, even though xfce's xinitrc does NOT call xrdb. Maybe these are really 2 different bugs: 1. xfce completely ignores global resources 2. Different ways to start X don't agree on name and location of the global Xdefaults. 2a. Hidden config files outside of $HOME are highly unusual. 2b. Because xfree ebuild doesn't install a default Xdefaults, it should be documented somewhere where to put it.
[aww, why did I bring up xfce? never even used it...] Upon closer inspection, xfce resets the resource data base everytime it starts up and everytime the user changes color preferences. Each time that happens it re-reads ~/.Xdefaults ~/.Xresources ~/.xrdb and nothing else. Would be a more-than-trivial patch to fix this, however... 1. I don't like hard-wired paths 2. doing this kind of stuff wouldn't be consistant with what other window managers / desktop environments do 3. your original bug about the location of `Xdefaults' would have to be resolved first. *bartron pokes <xfree@gentoo.org> 4. this looks more like an upstream bug to me. 4a. did you check if it is a known issue? 4b. did you report it to xfce maintainers? Easiest fix for now is to put all resources into `~/.Xdefaults' or one of the two other files.
That doesn;t seem right. Even if I put all the global stuff into ~/.Xresources, what about the settings added manually when xfce is running if I change colors? Looks to me like a bug in xfce too.
As far as I can tell, the system Xresources file should be /usr/X11R6/lib/X11/xinit/.Xresources when using startx to start X. When using a *dm, it looks like it should be 1) /etc/X11/xdm/Xresources (according to /etc/X11/xdm/xdm-config), or 2) /usr/X11R6/lib/X11/xinit/.Xresources according to (/etc/X11/xdm/Xsession). or 3) /etc/X11/Xresources (according to /etc/X11/Sessions/Xsession), I can't really see. You tried the second two with xdm. Could you try the first, /etc/X11/xdm/Xresources, using xdm? I'm not sure what's going on with startx not seeing the one it "should."
Hmmm, this looks more complicated than I thought. After this turned out to look like a bug in xfce, I've created the following file in /etc/X11/Sessions /etc/X11/Sessions/twm: ---8<--- #!/bin/sh /usr/X11R6/bin/twm ---8<--- for testing purposes and set XSESSION="twm" in rc.conf. Using startx, /etc/X11/xinit/.Xresources is now used, and I was almost about to vote for this bug to be closed (or changed to a minor enhanchement request; system-wide configuration file names starting with "." do look kind of odd; Xresources without the "." looks much better) BUT after changing configuration back to xdm, neither the file in /etc NOR ~/.Xdefaults are used (this only seemed to work with xfce because xfce is doing its own ~/.Xdefaults processing). /etc/X11/xinit/xinitrc and /etc/X11/xdm/Xsession do seem to reference the same files, => I'm running out of ideas here again. The part in /etc/X11/Sessions/Xsession that references $sysrecources ("/etc/X11/Xresources") and $rh6sysresources ("/etc/X11/xinit/Xresources") doesn't seem to be used. (neither does /etc/X11/xdm/xresources) It almost looks like there is some other script somewhere in the middle, I'm also not getting the nice standard X background. (?)
ok, since there seems to be no solution to this; what I'm trying to do is change some settings of nedit via xresources like described in nedit help. The provided appdefault file is documented no working, and indeed, if it is used, some parts of the program dont work anymore. Any ideas?
Hmm... looking at `/etc/X11/xinit/xinitrc' (this is what startx uses), it merges `$xinitdir/.Xresources' and `$HOME/.Xresources' right at the top. `/etc/X11/xdm/Xsession' (this is what xdm uses), however, only merges them if (a) chooser.sh returns an empty string, i.e. $XSESSION is unset or empty, and (b) `$HOME/.xsession' exists. Not sure about the exact reason (I remember there may have been a comment explaining it in a previous version, but can't find it right now...), but if that reason doens't exist anymore, the segments reading .Xresources and .Xmodmap should probably be moved to the top of `Xsession'. [poking bug-owner again here] (xdm/Xresources is only active while the login-screen is shown) [commenting on comment #9] If you just want to customize nedit, it's perfectly ok to have an app-defaults file (but make sure to update it with every new version), just not the one in nedit's doc-directory. Nedit people have always had this strange obsession that app-defaults files are bad :), and to prove their point the one distributed with nedit-5.3 belongs to nedit-5.1 with everything commented out. Installing that one will just reset all fallback-resources and add absolutely nothing (mouse-bindings in online-help and menu shortcuts won't work anymore). Best way is to extract `fallback_resources' from nedit.c and start from there.
(one month later...) (using resources from nedit.c worked, tahnks) (but its called fallbackResources)
ok, just to keep this bug alive to summarize 1. some DEs process resources and keyboard maps themself and throw anything else away, like xfce3, gnome, kde. 2. for that reason, Xsession proceses .Xresources and .Xmodmap only if ~/.xsession is used. Us poor users who do not use the standard DEs are out of luck. 3. yet xinit does read .Xresources and .Xmodmap, systemwide and per user always. 4. that just doesnt make sense! 5. I don't see this problemm in suse. 6. I still have NO IDEA what is /etc/X11/Xsession for. I tried to make it verbose, it is simply never used!
*BUMP* In 3 of my bug reports people have suggested kludges that require adding something to my ~/.Xdefaults. THIS STILL DOES NOT WORK!!! BARTRON, ccing you because you seem to be the only person who knows what she's talkign about!
[Erm... *she*? That seems just wrong in so many ways...] Look, I already told you how to solve the problem in comment #10... Alternatively, * if xrdb has never been invoked after server (re)start, i.e, there's no XM_RESOURCE_MANAGER and/or XM_SCREEN_RESOURCES property set on the current root window, you can just symlink `~/.Xresources' to `~/.Xdefaults' (the more correct name until some major distro chose to change it)... in that case the resource manager will read .Xdefaults itself for backwards compatibility with previous X11 versions. * create a file named `~/.Xdefaults-hostname', where "hostname" is the name of the client host... Xlib will read this file regardless whether xrdb has been used or not.
Sorry, typo! But I don't want the file in ~ (see summary)! 1. it's a pain in the ass to mess with many user's files. 2. users don't appreciate anybody besides themselves messing with their $HOME. 3. #ifdefs seem to be broken in $HOME
[`#ifdef's only work if xrdb is used (xrdb runs its input through cpp)] Here are some quick patches that solves the initial problem, with the following limitations... - lots of duplications... it would be lower maintenance if `xinitrc' and `Xsession' do only things unique to `xinit' and `xdm', respectively, and then converge into a single script. - if a user has their own `.xsession', they may expect a more pristine X server state (i.e. want to run xmodmap and xrdb themselves)... not sure though if this would break existing setups that rely on the current behavior. - `~/.Xdefaults' processing should probably be optional (restricted accounts). - does not affect kdm and wdm.
Created attachment 22010 [details, diff] Xsession.diff suggested changes to `/etc/X11/xdm/Xsession'
Created attachment 22011 [details, diff] xinitrc.diff suggested changes to `/etc/X11/xinit/xinitrc'
As an update there is a way around this that we are investigating the effects of... Basically the idea is to add the lines #ifdef COLOR *customization: -color #endif To the system wide Xresources file /etc/X11/xinit/.Xresources and then modify the startx script so that it disables direct usage of the ~/.xinitrc #if [ -f $userclientrc ]; then # defaultclientargs=$userclientrc #elif [ -f $sysclientrc ]; then defaultclientargs=$sysclientrc #fi This can be done similar to the above. This then forces startx to read the system wide xinitrc file, which in turn directs the process to read (if existant) ~/.xinitrc, in theory there should not be any problems arising from this, at least as far as my testing has shown. We need to confirm this before any changes will be commited though...
Andrew, as I was mentioning to you a while back, if you do this: #elif [ -f $sysclientrc ]; then defaultclientargs=$sysclientrc #fi then AFAICT nothing ever reads /etc/X11/xinit/xinitrc, at least according to the startx script and man xinit. The best way to test this would probably be to make those changes, then do something funky in /etc/X11/xinit/xinitrc and see whether it has any effect.
My apologies, I misread your code and didn't realize the system one was uncommented despite your obvious remarks. Nevermind.
this i do not understand
If startx is forced to use $sysclientrc (/etc/X11/xinit/xinitrc), it should always use the .Xresources files. $sysclientrc will use $userclientrc (~/.xinitrc) if it exists. However, since you said you didn't have ~/.xinitrc in comment #4, I'm not sure how this is supposed to solve your problem because it's effectively doing the same thing for you as before. But it can't hurt to try commenting out the four lines suggested in comment #19 and see if it helps read the Xresources files using startx.
but, but, but, I dont have problems with startx! except for unusual location and name (all other linuxes have /etx/X11/Xreources), startx works perfectly fine! comment #8 its more of a xdm-only breakage.
Allright I think I have it worked out If you are using startx, then the above fix is suitable. In fact the above fix is actually more correct behaviour, because it allows the system to be have system wide options overridden, as opposed to never read in the first place. That is all that should be done for startx (as Gentoo provides a startx script this should be changed). Secondly for desktop login managers (xdm/kdm/etc) there is something else we need to do, basically what happens (in the case of xdm which is the relevent one) if XSESSION is set in /etc/rc.conf then that session is executed from /etc/X11/xdm/Xsession and nothing else is processed, from that point forward it is up to the window manager to configure the environment, which is generically a bad idea. This problem can be rectified by vastly restructuring the the Xsession layout. We should put all settings/resource loading into Xresources and then source this file before anything else in both Xsession and startx. In fact we could actually have Xresources do server / client config reading and then just return to Xsession and / or startx to issue the commands based off the settings. Of course we should place all Xresources to one file (say /etc/X11/xinit/Xresources recommended as its not going to be xdm or startx unique). Im going to play around with setting up Xsession, startx, Xresources in this fashion later this evening / tomorrow. This way of initialisation makes it standard across both cli and gui startup. If I get this working we will probably put it into the next releases of both lines of XFree.
PLEASE TEST I have changed the scripts around a whole lot but to the extend of my testing (ie, startx, /etc/init.d/xdm start, and /usr/X11R6/bin/xinit <options>) the system now works with colours, and resource / modmap files in a uniform and simple configuartive place. Basically everything now acts as a wrapper for /etc/X11/xinit/xinitrc which merges resources, the system resources are merged first and then the users, so that user preferences over-ride the system ones :) Files of NOTE /etc/X11/xinit/ - xinitrc : The file to configure for system wide changes, startup prefs - Xresources : colours etc... - Xmodmap : keybindings etc... /etc/X11/xdm/ - Xservers : important to change this so -nolisten tcp is used as an option - Xsession : wraps to xinitrc with some fancy variable passing /usr/X11R6/bin/ - startx : wraps to xinitrc with some fancy variable passing I have left debugging outputs to boot in the 0.1 version of these scripts so IF you exeperience any difficulty please use at least the xinitc script from this tarball so I can see where you are having difficulty. There are two tarballs available containing the changed files http://dev.gentoo.org/~cyfred/xfree/ xinit-scripts-{0.1,0.2}.tar.bz2, as noted above if you dont want to see lots of echo'd lines on your console and logs, use the 0.2 version unless you have problems. The tarball has full paths to the files that it should replace so extract to a tmpdir and then copy them over the top, make sure you back up first!!!! Duplicating this comment on bug #25075 for consistency
see comments in #25705
I am also not satisfied with the way X is start up on most systems and do my own cutomizations. The problems are a) startx and *dm use different startup scripts solution: make a common scripts that set up the environment and source them b) different sessions do different parts of configuration ie some sessions are just windowmanagers, some are session managers an restart clients automatically the configuration can be split in several parts: I) set up X server ie enable dpms, check xauthority, ... II) set up X resources, keymaps, ... - windowmanagers usually need this, but kde or xfce would do this automagically III) start some services related to the X session - ie xscreensaver - most windowmanagers do not do this but kde or gnome do I think it is better to put the common parts in a script which is then called from both startx and xdm session so that it can be used elsewere. Calling the xinitrc script with some weird parameters would easily break and would probably need changes to the script for ie Xvnc. It would be also good idea to create directories where system admins and package maintainers could put scripts that are run at X startup, separately for different categories of scripts
