When trying to find out what the Custom entry was trying to do, I saw from strace that "/etc/kde3/kdm/Xsession custom" was getting run. (Incidentally, it first tries to open /usr/share/apps/kdm/sessions/custom.desktop, which doesn't exist on my system.)
So I tried changing ". /etc/X11/Xsession" to "exec sh -x /etc/X11/Xsession", and found that things then worked fine (i.e. the user's ~/.xsession gets run if allow-user-xsession is in Xsession.options). Changing "exec sh -x" to just "exec" also works. I haven't tried using "set -x; . /etc/X11/Xsession". Doing so might be interesting if we want to know why plain "." doesn't work, e.g. if there's a good reason why the script uses "." instead of "exec". The other part of the fix for this bug is to document the behaviour of Custom. (I did zgrep -il '\<custom\>' over all files in kdm, xdm and xfree86-common, without finding anything useful. There are no kdm-doc, xdm-doc or indeed relevant 'x.*doc' packages. Therefore I consider this a documentation bug.) AFAICT, the behaviour is that /usr/share/apps/kdm/sessions/custom.desktop is used if it exists, otherwise /etc/kde/kdm/Xsession is run with a first argument of `custom'. The default /etc/kde/kdm/Xsession file ignores its argument, and runs /etc/X11/Xsession. pjrm.
