Re: [pulseaudio-discuss] pulseaudio-discuss] Automatic selection of an audio sink depending on value of ENV variable
On 10/31/2009 02:16 PM, mark386 wrote: 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. This seems like it should be an inevitable development target so it's good to hear that it's in process. Thanks for clarifying. Cheers. Patrick Shirkey Boost Hardware Ltd ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Automatic selection of an audio sink depending on value of ENV variable
On Fri, 2009-10-30 at 18:43 +0100, Lennart Poettering wrote: 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 wy 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. b. signature.asc Description: This is a digitally signed message part ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Automatic selection of an audio sink depending on value of ENV variable
On Fri, 2009-10-30 at 18:43 +0100, Lennart Poettering wrote: And that's why I am saying that multiple screens per display is just a pointless excercise, since it gives you exactly NOTHING that multiple montors per screen wouldn't give you -- no, it takes features away. Sorry Lennart, in my (gaming) case, it allows the monitors to be placed a distance from each other, such that the mouse pointer cannot cross over. I use a small app (mouse-switchscreen) to allow the pointer to cross over if I want (ie. when not playing games). The other thing he mentioned which can't be done on xinerama is independent view-ports, where switching viewports on monitor 1 doesn't affect what's showing on monitor 2. Everyone has their own use-case =). But I think this is going pretty off-topic for the pulse list? ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] pulseaudio-discuss] Automatic selection of an audio sink depending on value of ENV variable
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 wy 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. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Automatic selection of an audio sink depending on value of ENV variable
On Sat, 2009-10-31 at 07:55 +0800, Ng Oon-Ee wrote: On Fri, 2009-10-30 at 18:43 +0100, Lennart Poettering wrote: And that's why I am saying that multiple screens per display is just a pointless excercise, since it gives you exactly NOTHING that multiple montors per screen wouldn't give you -- no, it takes features away. Sorry Lennart, in my (gaming) case, it allows the monitors to be placed a distance from each other, such that the mouse pointer cannot cross over. I use a small app (mouse-switchscreen) to allow the pointer to cross over if I want (ie. when not playing games). The other thing he mentioned which can't be done on xinerama is independent view-ports, where switching viewports on monitor 1 doesn't affect what's showing on monitor 2. Everyone has their own use-case =). But I think this is going pretty off-topic for the pulse list? Let me chip in another user-case: 1 monitor 2 TV; TV not always connected and in another room. I think we agree that Xinerama does not cut it in this case. Multiple displays? Maybe, but: NVidia *and* ATI graphical tools make it easy to set up a dual screen. To set up dual display, you have to get yourself dirty with xorg.conf - not an option for 90% of users. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Automatic selection of an audio sink depending on value of ENV variable
'Twas brillig, and Ng Oon-Ee at 29/10/09 04:47 did gyre and gimble: On Thu, 2009-10-29 at 12:03 +0800, Leszek Koltunski wrote: Well, the patch is there; you can go apply it, then load two 'module-x11-publish' : load-module module-x11-publish display=:0.0 sink=foo load-module module-x11-publish display=:0.1 sink=bar and voilla! It's working automagically. ( BTW, what is the best way to load the modules? I put the above two lines in /etc/pulse/default.pa, and it's working, but there's a comment there 'X11 modules should not be started from default.pa so that one daemon can be shared by multiple sessions' . So how? ) Not sure on the mechanics of it, but if not through default.pa you could always script a `pactl load-module module-x11` However, I'm sure there's reasons for the warning, so my suggestion is probably just another way of doing what's not a very good idea. Look at pulseaudio.desktop and start-pulseaudio-x11. These do exactly that just now. The script would need modified for this use case (as it registers X session handler too, not just the publication) but in theory, just running start-pulseaudio-x11 on each display should get you the necessary gubbins loaded (albeit one of session modules will fail to load, but you can probably just ignore that - the error is suppressed anyway). Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Automatic selection of an audio sink depending on value of ENV variable
Look at pulseaudio.desktop and start-pulseaudio-x11. These do exactly that just now. The script would need modified for this use case (as it registers X session handler too, not just the publication) but in theory, just running start-pulseaudio-x11 on each display should get you the necessary gubbins loaded (albeit one of session modules will fail to load, but you can probably just ignore that - the error is suppressed anyway). Hmm.. in that case my patch does not finish the job - potential users still have to modify the /usr/bin/start-pulseaudio-x11 binary in order to load the modules the right way. Couldn't we have something like '/etc/pulse/x11.conf' which would be read by /usr/bin/start-pulseaudio-x11 ? I could cook something like that together, but would that be accepted? Comments? ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Automatic selection of an audio sink depending on value of ENV variable
On Thu, 29.10.09 16:36, Leszek Koltunski (les...@koltunski.pl) wrote: Look at pulseaudio.desktop and start-pulseaudio-x11. These do exactly that just now. The script would need modified for this use case (as it registers X session handler too, not just the publication) but in theory, just running start-pulseaudio-x11 on each display should get you the necessary gubbins loaded (albeit one of session modules will fail to load, but you can probably just ignore that - the error is suppressed anyway). Hmm.. in that case my patch does not finish the job - potential users still have to modify the /usr/bin/start-pulseaudio-x11 binary in order to load the modules the right way. Couldn't we have something like '/etc/pulse/x11.conf' which would be read by /usr/bin/start-pulseaudio-x11 ? I could cook something like that together, but would that be accepted? Comments? I thought about that too. And I think it would make sense. However this should be a .pa file the same way as system.pa and default.pa, maybe called session.pa. However, I am not entirely sure how to implement this best. Just piping that file to pacmd is not enough since we need to do variable substitution. I haven't fully made my mind up on this yet. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Automatic selection of an audio sink depending on value of ENV variable
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. signature.asc Description: This is a digitally signed message part ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Automatic selection of an audio sink depending on value of ENV variable
Well, the patch is there; you can go apply it, then load two 'module-x11-publish' : load-module module-x11-publish display=:0.0 sink=foo load-module module-x11-publish display=:0.1 sink=bar and voilla! It's working automagically. ( BTW, what is the best way to load the modules? I put the above two lines in /etc/pulse/default.pa, and it's working, but there's a comment there 'X11 modules should not be started from default.pa so that one daemon can be shared by multiple sessions' . So how? ) ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Automatic selection of an audio sink depending on value of ENV variable
On Thu, 2009-10-29 at 12:03 +0800, Leszek Koltunski wrote: Well, the patch is there; you can go apply it, then load two 'module-x11-publish' : load-module module-x11-publish display=:0.0 sink=foo load-module module-x11-publish display=:0.1 sink=bar and voilla! It's working automagically. ( BTW, what is the best way to load the modules? I put the above two lines in /etc/pulse/default.pa, and it's working, but there's a comment there 'X11 modules should not be started from default.pa so that one daemon can be shared by multiple sessions' . So how? ) Not sure on the mechanics of it, but if not through default.pa you could always script a `pactl load-module module-x11` However, I'm sure there's reasons for the warning, so my suggestion is probably just another way of doing what's not a very good idea. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Automatic selection of an audio sink depending on value of ENV variable
On Tue, 27.10.09 16:39, Jeremy Visser (jer...@visser.name) wrote: On Mon, 2009-10-26 at 16:05 +0100, Lennart Poettering wrote: NVidia offers two ways to do it: you can setup the second monitor to be what they call a separate X screen ( and that it precisely what I have here ) or a TwinView (nvidia-speak for Xinerama ). this is bogus. gnome-panel is xinerama-aware and does not stretch panels across to monitors of the same screen. You are right, Lennart. Just FYI, TwinView is actually not the same thing as Xinerama. It is a proprietary and hacky NVIDIA solution to multiple monitors (been around for yonks -- before Xinerama was in X, I believe, but you wouldn't have heard of it unless you have had NVIDIA hardware). Yes, but the nvidia drivers actually implemented the xinerama interfaces pretty early so that clients that are xinerama-aware know where to put their stuff. gnome-panel was xinerama-aware. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Automatic selection of an audio sink depending on value of ENV variable
On Mon, 26.10.09 15:03, Leszek Koltunski (les...@koltunski.pl) wrote: We can do this, Not sure it makes a lot of sense though in the general case, and makes we wonder how long before someone wants to attach this informaton to a monitor, not a screen or display. And then again, running a display with multiple screens is kinda exotic in my eyes. The more common case is to have one screen with multiple monitors. And that's what we should optimize for. I'll try to argue with the above. If one runs NVidia proprietary drivers ( last time I used ATI - ~3ys ago - it was the same over there ) and wants to connect more than one monitor, NVidia offers two ways to do it: you can setup the second monitor to be what they call a separate X screen ( and that it precisely what I have here ) or a TwinView (nvidia-speak for Xinerama ). Now, the main difference between those two modes is this: Xinerama connects 2 or more monitors into one big desktop (gnome panels stretch across both monitors, one can drag windows between them etc this is bogus. gnome-panel is xinerama-aware and does not stretch panels across to monitors of the same screen. ) whereas 'separate X screen' creates 2 separate desktops (2 copies of gnome-panels appear, one on each monitor, dragging is impossible, each monitor has its own icons, trays etc ) . Yepp, and I'd argue the non-xinerama setup is useless. That means that if one chooses Xinerama, most probably his monitors are located physically next to each other. But in this case he likely does NOT need a separate sound sink for each monitor! If however one goes for 'separate X screen' , then he most probably wants some kind of a multiseat setup, or maybe - like in my case - his monitors are far away from each other. In precisely this case people tend to need separate sound sinks. I don't think that makes sense. Proper Multiseat means seperate authorization for both screens of your display, but X does not offer you that. Current strategy of attaching an X prop to a display gives this flexibility only to those who are knowledgeable enough to set this up manually in xorg.conf; NVidia and ATI graphical tools cannot do it. Uh? the xinerama stuff is what we support just fine. Attaching X prop to a screen would give this flexibility to 'dual screen' users, and those actually tend to need it. I don't think this is a realistic use-case. It's very much fabricated. Going for 'seperate sound sink for each monitor' first of all would require a radical redesign of Pulse, and second would not result in much additional benefit ( only Xinerama people would potentially gain, but those do not need this functionality anyway ) Radical redesign? Certainly not. I am not sure I sufficiently made the clear what the differences displays, screens, and monitors after all are. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Automatic selection of an audio sink depending on value of ENV variable
Yepp, and I'd argue the non-xinerama setup is useless. (...) I long had a feeling that I am being a pest with my dual screen, no-one seems to like it :) Least of all the people in the Gnome mailinglist... 1) Think about this usercase (that I already wrote about before): - a monitor and a soundcard 1 - a TV, standing in another room, soundcard 2 - bluetooth mouse keyboard. Connect the TV to your nvidia TV-out; fire up 'nvidia-settings'; setup the TV. You've got 2 options: - 'separate X screen' - 'TwinView' ( xinerama ) since TV is in another room, Xinerama makes little sense and actually makes things harder ( mostly because various windows which are supposed to pop up in the center of the screen pop up between the monitor and TV and you cannot easily see them, especially since the TV is most of the time disconnected! ) So you set up the separate X screen. This works very nicely (apart from a few little bugs in Gnome-panel ) You can enjoy watching movies or picture slides on your TV. It's really much better than Xinerama. ** Furthermore, I already have a simple patch which IMHO does not screw up anything for the single-monitor and Xinerama people while ALMOST-WORKING ;) for all those dual-screen pests. I'll post it in another message. L. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Automatic selection of an audio sink depending on value of ENV variable
My two cents : I agree that this setup (with 2 screens) isn't useless at all! I had the same setup a few years ago, when PA didn't exist, very nice. Someone could watch a movie on the TV while I was working on the other screen. But I thought that the multiple screen feature has been removed from X a while ago? Has it been readded? Anyway, I'm offtopic, so ignore me if you must ;) Regards JK 2009/10/26 Leszek Koltunski les...@koltunski.pl Yepp, and I'd argue the non-xinerama setup is useless. (...) I long had a feeling that I am being a pest with my dual screen, no-one seems to like it :) Least of all the people in the Gnome mailinglist... 1) Think about this usercase (that I already wrote about before): - a monitor and a soundcard 1 - a TV, standing in another room, soundcard 2 - bluetooth mouse keyboard. Connect the TV to your nvidia TV-out; fire up 'nvidia-settings'; setup the TV. You've got 2 options: - 'separate X screen' - 'TwinView' ( xinerama ) since TV is in another room, Xinerama makes little sense and actually makes things harder ( mostly because various windows which are supposed to pop up in the center of the screen pop up between the monitor and TV and you cannot easily see them, especially since the TV is most of the time disconnected! ) So you set up the separate X screen. This works very nicely (apart from a few little bugs in Gnome-panel ) You can enjoy watching movies or picture slides on your TV. It's really much better than Xinerama. ** Furthermore, I already have a simple patch which IMHO does not screw up anything for the single-monitor and Xinerama people while ALMOST-WORKING ;) for all those dual-screen pests. I'll post it in another message. L. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Automatic selection of an audio sink depending on value of ENV variable
On Mon, 2009-10-26 at 16:05 +0100, Lennart Poettering wrote: On Mon, 26.10.09 15:03, Leszek Koltunski (les...@koltunski.pl) wrote: *snip* ) whereas 'separate X screen' creates 2 separate desktops (2 copies of gnome-panels appear, one on each monitor, dragging is impossible, each monitor has its own icons, trays etc ) . Yepp, and I'd argue the non-xinerama setup is useless. *snip* I use the 'separate X' as well, even though my monitors are side-by-side. Its handy to 'lock' the mouse pointer into a particular monitor, which can be useful for mouse-heavy interaction while using the other screen to monitor (pun not intended) some processes or function. My normal use-case is full-screen gaming on one screen, if anyone's ever tried to play a side-scroller or FPS game with one side of the screen being 'transparent' and allowing the mouse to cross over, you'll know what I mean. Of course, for my purposes separate X11 properties for Pulse aren't necessary. Just thought I'd throw in a use-case where separate X DOES make sense. Similarly to the OP, it often seems to me like this is quite neglected, with most assuming that we'd all want our multiple monitors to act like one big monitor. Oh, and I just figured, you can't xinerama too many monitors together (4-6 screens, anyone?), at least not with nvidia... and xinerama hasn't been worked on in quite a while, to the best of my knowledge. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Automatic selection of an audio sink depending on value of ENV variable
On Mon, 2009-10-26 at 16:05 +0100, Lennart Poettering wrote: NVidia offers two ways to do it: you can setup the second monitor to be what they call a separate X screen ( and that it precisely what I have here ) or a TwinView (nvidia-speak for Xinerama ). this is bogus. gnome-panel is xinerama-aware and does not stretch panels across to monitors of the same screen. You are right, Lennart. Just FYI, TwinView is actually not the same thing as Xinerama. It is a proprietary and hacky NVIDIA solution to multiple monitors (been around for yonks -- before Xinerama was in X, I believe, but you wouldn't have heard of it unless you have had NVIDIA hardware). Basically, X thinks it has a giant monitor the size of all your screens (e.g. 2560x1024), and then the NVIDIA driver chops it up into viewports and sends it out across the various monitors, without X being aware of it. Totally not standards-compliant, and it's kind of redundant these days because recent versions of the NVIDIA driver support RandR 1.2 AFAIK. When nvidia-settings sets up a Separate X Screen, you can move the mouse between the two monitors, but you can't drag windows -- a window launched on one is trapped inside that monitor, and vice versa. Not sure what implications this has for Pulse, but I thought I'd just clear this up. signature.asc Description: This is a digitally signed message part ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Automatic selection of an audio sink depending on value of ENV variable
On Tue, 2009-10-27 at 16:39 +1100, Jeremy Visser wrote: Basically, X thinks it has a giant monitor the size of all your screens. Monitors, MONITORS, dammit. ;) signature.asc Description: This is a digitally signed message part ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Automatic selection of an audio sink depending on value of ENV variable
On Tue, 2009-10-20 at 18:32 +0200, Michał Sawicz wrote: Dnia 2009-10-20, wto o godzinie 17:18 +0100, Colin Guthrie pisze: Did you try setting the xprops manually? Make sure that works first (although if pax11publish is looking at the wrong display, it could be the pulse client libs are doing the same...) Doesn't 0.0 and 0.1 mean there's only one root window - thus only one default sink to be set through pax11publish? leszek# xprop -root -display :0.1 -f TEST 8s -set TEST test0.1 leszek# xprop -root -display :0.0 -f TEST 8s -set TEST test0.0 leszek# xprop -root -display :0.0 | grep TEST TEST(STRING) = test0.0 leszek# xprop -root -display :0.1 | grep TEST TEST(STRING) = test0.1 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Automatic selection of an audio sink depending on value of ENV variable
On Tue, 20.10.09 18:32, Michał Sawicz (mic...@sawicz.net) wrote: Dnia 2009-10-20, wto o godzinie 17:18 +0100, Colin Guthrie pisze: Did you try setting the xprops manually? Make sure that works first (although if pax11publish is looking at the wrong display, it could be the pulse client libs are doing the same...) Doesn't 0.0 and 0.1 mean there's only one root window - thus only one default sink to be set through pax11publish? Nah. On X11 there are displays, screens and monitors. A display consists of one or more screens. A screen consists of one or more monitors. A root window is something that is assigned to a screen. Having multiple monitors on a single screen is what people tend to refer to as Xinerama. PA always looks into the root window of screen 0 of the display -- under the assumption that it is actually the display we want to attach data to, and not a screen or a monitor. pax11publish does that, the client libs do it and the pa server too. However, as mentioned this is fixable. In this particular case outlined in this thread it seems to be requested to make those props per-screen and not per-display. We can do this, Not sure it makes a lot of sense though in the general case, and makes we wonder how long before someone wants to attach this informaton to a monitor, not a screen or display. And then again, running a display with multiple screens is kinda exotic in my eyes. The more common case is to have one screen with multiple monitors. And that's what we should optimize for. But hey, a clean patch can be a very convincing argument. Walk the walk, don't talk the talk! Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Automatic selection of an audio sink depending on value of ENV variable
'Twas brillig, and Leszek Koltunski at 20/10/09 16:20 did gyre and gimble: Seems to me that 'pax11publish' disregards the screen number given in its -D parameter and only pays attantion to the X server number. for every N, pax11publish -D :0.N overwrites the X11 properties of 0.0. Did you try setting the xprops manually? Make sure that works first (although if pax11publish is looking at the wrong display, it could be the pulse client libs are doing the same...) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Automatic selection of an audio sink depending on value of ENV variable
Dnia 2009-10-20, wto o godzinie 17:18 +0100, Colin Guthrie pisze: Did you try setting the xprops manually? Make sure that works first (although if pax11publish is looking at the wrong display, it could be the pulse client libs are doing the same...) Doesn't 0.0 and 0.1 mean there's only one root window - thus only one default sink to be set through pax11publish? -- Michał Sawicz mic...@sawicz.net ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Automatic selection of an audio sink depending on value of ENV variable
'Twas brillig, and Michał Sawicz at 20/10/09 17:32 did gyre and gimble: Dnia 2009-10-20, wto o godzinie 17:18 +0100, Colin Guthrie pisze: Did you try setting the xprops manually? Make sure that works first (although if pax11publish is looking at the wrong display, it could be the pulse client libs are doing the same...) Doesn't 0.0 and 0.1 mean there's only one root window - thus only one default sink to be set through pax11publish? I wasn't 100% sure of that, which is why I asked if he'd tried the xprop manually. The only thing that made me suspect that all was well was the fact that xprop -root on display 0.1 shows nothing whereas if they were the same, I'd have though this would return the same values for 0.0 and 0.1... but perhaps that's just not how xprop works. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Automatic selection of an audio sink depending on value of ENV variable
Here's my usercase: I've got a monitor and sound card hw:0.0 set up as my primary video/audio sinks. I've also got a TV , located in a different room, connected to a TV-Out and to another sound card, hw:1.0 I've also got a Bluetooth keyboard and mouse. So whenever I want to watch a video or show my guests a picture slideshow , I simply connect the (looong!) vidao/audio cables to the TV, move the keyboard and mouse (still work from ~8m away! ) and lie down on the sofa :) The TV is a separate X screen ( why would I use Xinerama? I don't need to move windows between the displays ) so when an application is launched on the monitor, DISPLAY is set to 0.0 and when I operate on the TV, it is 1.0. I hope you already know what I have in mind: the above works wonderfully, except for the sound. Every time I work on the TV, the sound should be sent to hw:1.0, so I have to fire up the new 'gnome-sound-properties 2.28' (BTW, wonderful app! simple and effective) and select hw:1.0 to be the audio sink for now. Worse, since the TV is on 2nd X screen, 'gnome-sound-properties' applet won't start there ( it claims there is already one running - sure there is, on the monitor - and refuses to start ). So it order to change the audio sink, I have to haul my lazy butt back to the monitor. Now, I would make me one happy duck if I could somehow tell Pulse to automatically route audio to hw:1.0 whenever I am working on the TV, that is, whenever DISPLAY is 1.0. Is that possible? ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Automatic selection of an audio sink depending on value of ENV variable
2009/10/19 Leszek Koltunski les...@koltunski.pl: Now, I would make me one happy duck if I could somehow tell Pulse to automatically route audio to hw:1.0 whenever I am working on the TV, that is, whenever DISPLAY is 1.0. It looks like PULSE_SINK environment variable is exactly what you need, see: http://pulseaudio.org/wiki/FAQ#WhatenvironmentvariablesdoesPulseAudiocareabout Maarten ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Automatic selection of an audio sink depending on value of ENV variable
'Twas brillig, and Leszek Koltunski at 19/10/09 09:38 did gyre and gimble: Now, I would make me one happy duck if I could somehow tell Pulse to automatically route audio to hw:1.0 whenever I am working on the TV, that is, whenever DISPLAY is 1.0. Should be simple, PULSE_SINK= env var does that for you. But a better option in your case is x11 properties. Pulse can get it's configuration from the X11 Root window, e.g. xprop -root Just set the PULSE_SINK xprop on the root window of DISPLAY 1.0 and you're all set. You can get the name you want to use via pacmd list-sinks Nice easy one to answer that :D Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Automatic selection of an audio sink depending on value of ENV variable
'Twas brillig, and Maarten Bosmans at 19/10/09 11:10 did gyre and gimble: 2009/10/19 Leszek Koltunski les...@koltunski.pl: Now, I would make me one happy duck if I could somehow tell Pulse to automatically route audio to hw:1.0 whenever I am working on the TV, that is, whenever DISPLAY is 1.0. It looks like PULSE_SINK environment variable is exactly what you need, see: http://pulseaudio.org/wiki/FAQ#WhatenvironmentvariablesdoesPulseAudiocareabout As noted in my reply, the x11 property is even better :) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Automatic selection of an audio sink depending on value of ENV variable
Ok, thanks guys! Pulse Convert On Mon, Oct 19, 2009 at 6:20 PM, Jeremy Visser jer...@visser.name wrote: On Mon, 2009-10-19 at 16:38 +0800, Leszek Koltunski wrote: Every time I work on the TV, the sound should be sent to hw:1.0, so I have to fire up the new 'gnome-sound-properties 2.28' (BTW, wonderful app! simple and effective) and select hw:1.0 to be the audio sink for now. Worse, since the TV is on 2nd X screen, 'gnome-sound-properties' applet won't start there ( it claims there is already one running - sure there is, on the monitor - and refuses to start ). Now I don't necessarily agree with their stance, but it is generally not regarded a good idea to have the same user logged in to the same GNOME profile twice. I know — I get bitten by this too when I want to set up a multiseat kiosk-type setup. If you want a solution that 'just works', then either log off your primary display, or use a separate user with a separate GNOME profile. (This is a bug in GNOME though, IMO, not your fault.) ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Automatic selection of an audio sink depending on value of ENV variable
'Twas brillig, and Jeremy Visser at 19/10/09 11:20 did gyre and gimble: On Mon, 2009-10-19 at 16:38 +0800, Leszek Koltunski wrote: Every time I work on the TV, the sound should be sent to hw:1.0, so I have to fire up the new 'gnome-sound-properties 2.28' (BTW, wonderful app! simple and effective) and select hw:1.0 to be the audio sink for now. Worse, since the TV is on 2nd X screen, 'gnome-sound-properties' applet won't start there ( it claims there is already one running - sure there is, on the monitor - and refuses to start ). Now I don't necessarily agree with their stance, but it is generally not regarded a good idea to have the same user logged in to the same GNOME profile twice. I know — I get bitten by this too when I want to set up a multiseat kiosk-type setup. If you want a solution that 'just works', then either log off your primary display, or use a separate user with a separate GNOME profile. (This is a bug in GNOME though, IMO, not your fault.) FWIW, pulse runs quite happily with the same user logged in twice, it simply loads an xsession management module for each desktop in use by the user. Jobs a good 'un :) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Automatic selection of an audio sink depending on value of ENV variable
On Mon, 19.10.09 16:38, Leszek Koltunski (les...@koltunski.pl) wrote: Now, I would make me one happy duck if I could somehow tell Pulse to automatically route audio to hw:1.0 whenever I am working on the TV, that is, whenever DISPLAY is 1.0. As the others already pointed out, the X11 props stuff is what you want. Try something along these lines: $ pax11publish -D :0 -O foobar -e $ pax11publish -D :1 -O waldo -e Where foobar and waldo are the two logical PA sink names to use. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
