On Wednesday, 22. October 2008, Michel Dänzer wrote: > > Still, all other drivers, including Windows, agree on "first" vs. > > "second" output connector, regardless of RandR 1.2 or not -- point is, if > > I switch drivers or OS, my primary display suddenly isn't primary > > anymore, kdm appears on the wrong screen, as does the taskbar or yakuake. > > The thing is, I don't think RandR 1.2 defines a 'primary' CRTC/output at > all. It sounds like things should be fine if clients remembered things > from the names or geometry of outputs rather than their arbitrary > enumeration order.
Well, RandR defines an order. It's the order the "xrandr" utility shows. Semantically, order may not be considered significant. In practice, a defined (but implementation-dependent) order exists and will be used for default settings all over the place. Providing sane defaults that agree with everyone else are IMHO worth quite a bit, especially since current software doesn't allow connector-name based configuration. Given that RandR 1.2 has the notion of a "compat" output (see hw/xfree86/doc/README.modes), one connector actually does have special semantics. It is a kind of 'primary' output for all X extensions that are unaware of RandR 1.2 (e.g., XVidMode). I agree that name-based settings make a lot of sense in the long run. Hence, my patch doesn't change the names, just the order in which they are registered. Current software, however, just honours the order in which screens are returned by RandR (or Xinerama, in the case of fglrx). And even with name- aware software, default settings will still be based on the order, and so radeon will behave opposite to everyone else by default, for no benefit. BTW, the two RandR-1.2 compatible drivers radeon and radeonhd disagree on names as well: "DVI-1" vs. "DVI-I_2/analog" for the second connector. Who knows what fglrx will bring... I don't care a lot about the exact naming scheme, and when software begins to remember screens by name, it hopefully can remember multiple "preferred" screens in order to cope with different naming schemes. -- CU Jörg _______________________________________________ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati