Disclaimer: I don't really have any skin in this game so you can tell me I'm stupid or whatever you want, however... On Mon, 2009-10-26 at 16:05 +0100, Lennart Poettering wrote: > > Yepp, and I'd argue the non-xinerama setup is useless. /me looks over from his primary display (with it's separate desktops. separate panels and where he can't drag windows -- but he can drag desktop icons -- so nautilus is a bit more knowledgeable than the window manager is about screens, but I digress) to the e-mail he is composing on his secondary, non-xinerama'd display. Been doing it that way for the better part of a decade. Xinerama seems more useless to me than this. With Xinerama, do I really want most windows (terminals, web-browsing, e-mail composing and reading) split across a physical monitor barrier where there is a few inches of "plastic" between the screen real-estate? Not usually. So what (would I, were I using Xinerama) do I do most of the time with windows that do open up split between two screens? I (would) move them in one direction or another to get them entirely on one of the physical screens. So if that's how I am going to operate, why bother with Xinerama and its' particular short-coming(s), at which separate screens is good, like being able to easily maximize an application to use up a full physical monitor, but no more and yet no less. Yes I could stretch it out from corner to corner of a separate screen, but that maximize button is so handy. And I cannot switch viewports independently on the two screens with Xinerama, which reduces the usefulness of keeping something displayed on one screen all the time while I flip viewports on the other screen. Another very good use case (and this one is going to segue into this particular thread very well in a minute) is the computer in the bedroom. Another dual-head machine (that's 2-0 for dual-head vs. xinerama in my house) that does not use Xinerama. Why's that? Because it's composed of a real monitor on screen 0 and an LCD TV on screen 1. Regular desktop computing (e-mail, browsing, playing games, doing homework, etc.) is done on screen 0 and on screen 1 there is a MythTV instance left running (for the convenience of just having to turn on the TV to watch). So the bedroom computer doubles as the family computer as well as the bedroom TV (for a value of TV that equals PVR). Now, how this fits with OP's original propsal is that the TV in this setup has it's own speakers which are being driven by a separate sound card in this machine. This machine also has it's own speakers a different sound-card. So two sets of speakers, two sound cards. So as for why two... I don't want to have to turn on the TV just to get sound for gaming (or music while "computing", etc.) on screen 0 but I also want to have MythTV's audio come through the TV's speakers, where the picture is coming from. It's just natural to have the sound come from where you are looking. Of course, I've hobbled this together to work with Pulse's static sound routing, where I've mapped mythtv to use the sound card connected to the TV and everything else defaults to the "other" sound card. But that means if I use MythTV on screen 0 (for whatever strange reason), I do have to turn the TV on to get sound, (or mess with the PA routing of course, but then also remember to fix it when I am done). But if OP's proposal were accepted such that one could choose to route sound to hardware by the screen the application is running on (with the existing per application overrides still effective of course), this would all "just work" for me too. > I don't think this is a realistic use-case. It's very much fabricated. Really? The above dual-screen configuration I have in my bedroom where one screen is a TV is fabricated? I'll have to go tell the wife to stop watching, right now. :-) b. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20091028/03470231/attachment.pgp>
