Red Hat Bugzilla – Bug 9003
gnome doesn't do anything with a second screen
Last modified: 2008-05-01 11:37:54 EDT
gdm, only display a login screen on the first screen. (I have a dual monitor setup) gnome-session when started only uses the first screen, the second one stays empty. fvwm for example starts itself on all screens a server has. Talking about having 2 monitors, in order to get them both to work a commandline option has to be passed to X. For startx this is doen through xserverrc, it would be nice if gdm would honor this too.
This is a deeply-rooted architectural problem, namely that the GTK toolkit used to write all the GNOME stuff does not support multiple screens. It's extremely time-consuming to fix, and since very few people have multiple monitors, the GNOME project hasn't made it a high priority. The bug is unlikely to be fixed in the near future unless someone donates programming time or money for hiring programming time. :-( Still it is a valid bug. Newer versions of GNOME should at least work a lot better with multiple displays, though we still won't be able to support multiple screens on the same display.
I just tested this, but when I use AnotherLevel as desktop I can start gtk apps (I tried it with gtop) on both screens. I can believe that gtk doesn't now anything about multiple screens. But it does use the screen set in the DISPLAY var, not just screen 0. so it does work. So having a wrapper around gnome session / gdm starting it on both: :0.0 :0.1 Should work, this seems to be what fvwm does too, I just get 2 fvwm's, but figures it out itself and forks. Doing it in gdm has the advantage you can be 2 different users on each screen dunno if this is a bug or a feature though. What I suggest is: -change gdm and / or gnome-session to: -don't init gtk immediatly -determine wether or not there are multiple screens. using Xlib -fork once for each additional screen -setenv DISPLAY to match the screen -init gtk -continue as usual Reopen ?!
I'll reopen the bug and send your suggestion upstream to the gdm maintainer. Sounds pretty scary though. :-)
Moving bug to gdm.
Since we aren't going to fix this on the Red Hat level but leave it to upstream, closing it in our bugtracker.