[pulseaudio-discuss] pulseaudio-discuss] Automatic selection of an audio sink depending on value of ENV variable

[mark386]

> > Dude. This is nonsense.
> 
> To you maybe.
> 
> > WMs such as metacity are xinerama-aware and have been about
> > forever.
> 
> Guess I am showing my age because I have to admit that the last time I
> tired Xinerama was waaaay before metacity was around.
> 
> > Windows won't be maximized across the monitor boundaries
> 
> So I hit maximize on a window on a Xinerama screen and it will only
> maximize to the single screen underlying that portion of the Xinerama
> screen?  Neat.
> 
> But what if I really did want a window maximized across monitor
> boundaries?
> 
> > and
> > the monitor boundaries are "magnetic" when you move windows across
> > them.
> 
> Not really sure what means.  Maybe a maximized app on one screen can be
> moved to another and it will be maximized there, even if it needs
> resizing to do so?
> 
> > So Xinerama in WMs gives you about everything you explained
> > above,
> 
> Except one thing.  The most important for me in fact.  I must have not
> emphasized that enough.  But it's the ability to switch viewports on
> screens independently.  A common scenario for me is grouping work tasks
> on to different viewports on the screen on the right and switch between
> view ports to switch between tasks, all the while leaving the screen on
> the left on the same viewport reading e-mail.
> 
> > in addition to actually allow you to drag windows across the
> > border if you want to.
> 
> Yeah, sometimes that would be nice, but generally, I don't miss it.
> 
> > And that's why I am saying that multiple screens per display is just a
> > pointless excercise,
> 
> For how you work, perhaps it is.  Clearly for how I work it's not.
> 
> > since it gives you exactly NOTHING that multiple
> > montors per screen wouldn't give you -- no, it takes features away.
> 
> Does it really give me independently switchable viewports?
> 
> > That is a broken use case too, because in this case you should be
> > using two seperate displays, instead of one display with two screens.
> 
> Actually, I'd probably prefer that, then I don't have to have task bars
> on the second screen like I do with dual-head Gnome.
> 
> However, AFAIK, one is not able to run independent X servers on the two
> displays of a dual-headed video card.  Maybe I'm wrong.
> 
> > Really, multiple screens per display is just pointless. Its a useless
> > feature...
> 
> Every man has an opinion.

FYI, Xinerama is in the process of being deprecated and replaced by
RandR. Currently RandR is not fully functional as a replacement for
Xinerama. 

One result of faulty driver implementation of an incomplete RandR is
that using some recent nvidia or ati proprietary drivers to implement a
xinerama-like desktop stretched across two displays a full screen
maximization of a window would stretch across both displays. This is an
artifact of the incomplete RandR implementation and can be remedied by
disabling RandR when implementing this xinerama-like screen.

Please note that these drivers are not actually using xinerama but
proprietary code to do this.

Currently, if you are using the latest ati or nvidia drivers the only
reason to use Xinerama is to have independent displays which you can
drag windows across if you are using multiple gpus  When the latest
nvidia and ati proprietary drivers do use Xinerama, RandR is disabled.

One thing that can be done with these drivers (at least with ati's
fglrx) when using xinerama is that compiz can be enabled on one screen
and that screen can be rotated independent of the other displays.

Multiple independent displays with multiple independent view ports.
RandR has not been implemented for this yet in any display manager.

The open source driver devs are following X org and have already
deprecated xinerama in favor of randr.

Apparently the ability to rotate the screen on your notepad is far more
important than having more than one independent display/viewport since
it seems to be the driving reason for tossing xinerama into the trash
and adopting randr before it is ready to actually be implemented by the
display managers to replace xinerama.

meh

Anyway, I hope this clears up some of the confusion about this little
xinerama dust up.