I see that kdm does have a patch, kubuntu_104_kdm_active_vt_plymouth.diff, which is meant to make kdm take over smoothly from plymouth. However, plymouth's upstart job is currently configured "stop on starting kdm", so kdm will never be able to query plymouth for the active VT because it's already stopped before kdm starts.
That being the case, I can't actually see how the current problem is a kdm bug /at all/. The only thing the kdm patch does is check /var/spool/gdm/force-display-on-active-vt to decide whether to use the current VT, and I don't see anything that would create that file. So the current kdm implementation should *always* start X on a new VT, AFAICS.
I see that kdm does have a patch, kubuntu_ 104_kdm_ active_ vt_plymouth. diff, which is meant to make kdm take over smoothly from plymouth. However, plymouth's upstart job is currently configured "stop on starting kdm", so kdm will never be able to query plymouth for the active VT because it's already stopped before kdm starts.
That being the case, I can't actually see how the current problem is a kdm bug /at all/. The only thing the kdm patch does is check /var/spool/ gdm/force- display- on-active- vt to decide whether to use the current VT, and I don't see anything that would create that file. So the current kdm implementation should *always* start X on a new VT, AFAICS.