The video at boot is usually controlled by the BIOS. Video drivers don’t kick in until after the kernel is loaded. Do you get two splash screens from the BIOS??
I left that out because it doesn’t matter: the issue is the same even with a Debian in a VM (with 2 monitors) which emulates completely different hardware.
ok At login the video driver is started but not totally set until you log in since different user can have different settings. So the screen is cloned until the desktop tells it otherwise. Maybe some xorg.conf setting may change the mode since those settings are in charge until hand off to the desktop.
Don’t know Intel GPU’s so you will have to find the needed setting with the help of Google.
I’ve explained how to do it in these very forums on a number of occasions:
use xrandr to configure your setup
save that as a script and then call it in your Display Manager’s config file or
use one of the setup scripts the DM already calls, by placing your xrandr line into it
[ul]
[li]The DM starts and then loads X. Once X is up, the DM’s greeter screen is displayed (i.e. the screen with the login box). [/li][li]The DM loads X via the instructions in its config file.[/li][LIST]
[li]Several of the various DMs have their config files are found directly in /etc (e.g. /etc/sddm.conf) or a relevant subdirectory of /etc (e.g., IIRC, lightdm uses /etc/lightDM/lightdm.conf … but don’t hold me to that … the pt was it will be something along those lines) [/li][li]KDM uses /usr/share/kde4/config/kdm/kdmrc [/li][/ul]
[li]Reading through the DM config files and familiarizing yourself with their appropriate documentation, you will see[/li][ul]
[li]that most (if not all?) load X via the old XDM startup scripts (contained in /etc/X11/xdm/ ) [/li][li]some provide facility to load your own script [/li][li]that you can get creative in the way you want to accomplish your goal [/li][/ul]
[/LIST]
For my own purposes, (currently using KDM) I have evoked my own Setup line (which otherwise defaults to loading he Xsetup script) that runs my own script. This script simply, in turn,
[ul]
[li]runs a xrandr script I created (which tailors my desired monitor setup) and [/li][li]then runs the vanilla xdm Xsetup script [/li][/ul]
Notes:
[ul]
[li]KDM is a PITA, because whenever a new build is brought in, the kdmrc is regenerated and it comments out my desired Setup line (consequently, resulting in the default being used intstead) and I then have to manually restore this … and while its a simple edit to revert things to how I want them (via deleting the “#” which comments out my desired Setup line), that behaviour is simply bad as its disrespectful of my changes. Bad KDM, bad … This isn’t so much a problem in the regular release (where KDM likely is seldom updated), but in TW its more annoying as newer KDM builds are brought in on a much more frequent basis [/li][li]KDM allows you to tailor which monitor you want to place the login box on (see KDM docs/manual found online) … that works for single graphics adapters IIRC, but does not work in the case of multiple adapters (whereby you’ve merged everything via xrandr’s setproviders) [/li][/ul]
Looking at the script you’ve proposed, I’d hazard that you have a laptop. If that (script) is what works good enough for you, then go nuts with it by applying it to the concepts described above … I suspect that, given the info, you can figure out an even more eloquent solution.
Just an ordinary PC. I simply want to have the same behaviour that other OSes supply out of the box (see initial post).
To you this thing may seem like a no-brainer. In that case there would be lots of how-tos etc. around or it would work out of the box (and why not, btw?). But this isn’t so.
Anyway - thanks to your help I’m much closer now to a solution.
Here is the thing Linux is setup to do user level choices so one user may have things one one and another another way so DM settings are done at a different place because who’s preference do you use until you know who it is??. The default behaviours at log in is probably set as mirror for education or other situations where the second monitor is for all to see. For this situation the defaults are perfect. Most people generally would not really care if the login which lasts the time it takes to type a password is shown on one or two screens. You can of course change that but it takes digging into config files and those are different for any particular flavour of DM. So yes you must actually know something to override the defaults to your likes. Tyler_K has shown you one way I suggested another. Since Xorg.conf. is executed at X/video startup you should also be able to change the default monitor settings there. Nothing wrong using xrandr it is just where to put the commands is tricky and obviously different depending on DM. Changing things in xorg.conf (or xorg.conf.d directory) is more general and should work with about any DM
No, I appreciate that it isn’t readily apparent how one would accomplish this. My appreciation stems from the fact that at one time I didn’t know how to do this either and consequently had to do some digging to figure it out. I guess the point is that the info is out there, and if one seeks, one shall find.
Why isn’t there a lot of howtos for this? Beats me. Likely along the lines of what gogalthorp said – “Most people generally would not really care if the login which lasts the time it takes to type a password is shown on one or two screens.” … though, at the same time, I see plenty of people who get bent out of shape about the resolution used for their grub screen lol!, so perhaps the former sentiment doesn’t correctly explain it…shrugs.
Why it (spanning across all monitors) deoesn’t work right out of the box? Historical default relationship. Keep in mind the age of X. You don’t have to read it, but if interested, this article offers e a little bit of perspective: http://nouveau.freedesktop.org/wiki/MultiMonitorDesktop/
Anyway - thanks to your help I’m much closer now to a solution.
For a simple use case (for like what it turned out the OP’s is), using a xorg.conf (or the equivalent snippet files) is fine. But for other use cases (e.g. multiple adapters) it will not work. The route I suggested is robust to these. Yes, you have to figure out a config file, but the same applies the xorg.conf way too. And while what I outlined might seem like a lot, its actually really not – in the end its darn right easy at its simplest (e.g. add a single line to a single conf file) and extremely flexible at its best (e.g. use your own script files to really tailor your setup).
