According to Sean Cody:

First of all this is under OpenBSD 3.9 but that should be immaterial to the issue.

Basically if I run startx from a shell X starts and my .xinitrc is parsed/executed and all is well. Since I'm using X more I decided to enable xdm (via echo "xdm_flags="" > /etc/rc.conf.local; reboot; ) instead of launching manually from a shell. Now when I log in through XDM my .xinitrc isn't parsed/executed and I have to run it manually (fvwm notices my .fvwmrc so that part is working as expected).

I'm not doing anything too complex and everything is rather 'stock' with changes to the default install are overridden in my home directory such as .Xdefaults and .fvwmrc . I'm using .xinitrc to set a pretty background (via xv(l) and to start an ssh-agent)

Any ideas on how I can figure this out? I should probably investigate how XDM is launched and actually read the startx script, but I'm going to gamble on someone else already knowing why this happens.

Essentially, .xinitrc is only used by the startx script, which invokes xinit. It's not used by any of the typical X display managers (xdm, kdm, gdm, etc.). They typically have a different set of startup scripts they use. In the case of xdm, there are system-wide startup, session and reset scripts, which are specified in a resource file (typically, these are called Xstartup, Xsession, and Xreset, and the resource file is xdm-config, all located in the same system-wide directory). The startup and reset scripts are always run as root, and are used (as their names suggest) to do special tasks before and after the session is run. Furthermore, the Xsession file (which is run as the logged-in user) will typically look for and exec a user-specific ~/.xsession file.

If what you're doing in your .xinitrc file is fairly generic, you can probably link it to .xsession as well, to use the one script for both environments (startx/xinit and xdm/kdm/whatever). Of course, you'll want to look at the system-wide session script for your display manager, to make sure it does look for a user-specific script, and if so, which one.