Re: xrandr dual-screen usability survery (Was: Dual-head config broke with update to 1.4.2)
On Sun, Feb 21, 2010 at 2:26 PM, Martin Cracauer craca...@cons.org wrote: Alex Deucher wrote on Wed, Feb 17, 2010 at 12:38:16PM -0500: So fine, here's the yearly zaphod fix: http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=579cdcf9b4e38c791a497b747a055fc0a07d8dd6 I'm afraid this doesn't quite do it. It corrects the mistake of detecting DVI (see log). But I still don't get dual screens, it still drops the internal LCD screen and I end up with one screen, mirroed. That happens both with the fresh xorg.conf and with the xorg.conf that worked before with just the new option put in. Any ideas? Maybe I just overlooked some config option for a changed default? I'll take a look today. conf/log/backported-patch here: http://www.cons.org/xorg-problem201002/firstpatch/ I also noticed that the Xv extension on the VGA output is not functional in that mirrored mode. The LCD displays the video picture but the VGA has a blue window. This might be normal. The video overlay one works one crtc at time. You have to select which one you want to use it with using the XV_CRTC Xv attribute (you can use xvattr to change Xv attributes). Textured video Xv support has been available for a while now (several years) and that has no head limitations, although if you are using an old version of the driver it might be missing. xvinfo will show you the available adapters. Alex Martin -- %%% Martin Cracauer craca...@cons.org http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/ ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xrandr dual-screen usability survery (Was: Dual-head config broke with update to 1.4.2)
Alex Deucher wrote on Wed, Feb 17, 2010 at 12:38:16PM -0500: So fine, here's the yearly zaphod fix: http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=579cdcf9b4e38c791a497b747a055fc0a07d8dd6 I'm afraid this doesn't quite do it. It corrects the mistake of detecting DVI (see log). But I still don't get dual screens, it still drops the internal LCD screen and I end up with one screen, mirroed. That happens both with the fresh xorg.conf and with the xorg.conf that worked before with just the new option put in. Any ideas? Maybe I just overlooked some config option for a changed default? conf/log/backported-patch here: http://www.cons.org/xorg-problem201002/firstpatch/ I also noticed that the Xv extension on the VGA output is not functional in that mirrored mode. The LCD displays the video picture but the VGA has a blue window. This might be normal. Martin -- %%% Martin Cracauer craca...@cons.org http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/ ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xrandr dual-screen usability survery (Was: Dual-head config broke with update to 1.4.2)
On Wed, 17 Feb 2010 09:10:07 -0600 Jesse W. Hathaway je...@mbuki-mvuki.org wrote: Martin Cracauer: Overall my original impression has been reinforced: you basically dropped what hackers need when getting work done on a desktop Unix machine in favor of what managerish types coming from Windows need when standing in front of a projector and need to get their single-task thing done. Have you looked at any of the window managers that are more oriented to this type of workflow: [...] Those are all tiling window managers, which is what I prefer, I still use ion2, which is not actively being developed. Are you aware that you are proposing a change in working style? Ie. someone who has configured his system to behave exactly how he can work most efficiently has now to switch to a totally new, unconfortable style of working, just because someone thought that some feature is not important anymore? Users are different, users are individuals. Each of them has his own needs, own ways of working. You cannot force them to use The One True Window Manager[tm], because it does not fit the way they are doing things. A tool (and the computer is nothing more than just a mere tool, a complicated one though) should adapt to its user. The tool should not force the user to adapt to the tool. Otherwise it'll be like forcing everyone to use a hammer, no matter what he wants to do, even if it's planting some flowers in his garden. I advice anyone working on OSS, no matter what field, to read some books/articles on usability and design. It's the human that should be in the center of our efforts, not the technical problem that is so much fun to work on. Of course, working on these technical problems is what keeps us going, but if we make it the only thing we live for, then there will be no user for our nice and shiny solutions. Attila Kinali -- Why does it take years to find the answers to the questions one should have asked long ago? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xrandr dual-screen usability survery (Was: Dual-head config broke with update to 1.4.2)
Am 17 Feb 2010 12:38:16, Alex Deucher alexdeuc...@gmail.com schrieb: And aside from that, didn't you say earlier that the Intel driver actually has it removed and that it is official Xorg policy that keeping classic dual-screen alive is not intended? Yes, the intel driver has removed it. It's not policy to remove zaphod mode, but none of the active Xorg developers that I know of use it and very few users overall use it, so it doesn't get tested much. We are all busy so it's not a high priority. Is it correct to deduce, nvidia software engineers either (1) are not busy, or (2) don't discriminate less widespread X11-technology use cases? (Looking statistically computer users on the planet run windows anyways, so following this argument why fiddle with X11 at all, then?) :-) Greetings, Eeri Kask ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xrandr dual-screen usability survery (Was: Dual-head config broke with update to 1.4.2)
Eeri Kask wrote: Am 17 Feb 2010 12:38:16, Alex Deucher alexdeuc...@gmail.com schrieb: And aside from that, didn't you say earlier that the Intel driver actually has it removed and that it is official Xorg policy that keeping classic dual-screen alive is not intended? Yes, the intel driver has removed it. It's not policy to remove zaphod mode, but none of the active Xorg developers that I know of use it and very few users overall use it, so it doesn't get tested much. We are all busy so it's not a high priority. Is it correct to deduce, nvidia software engineers either (1) are not busy, or (2) don't discriminate less widespread X11-technology use cases? or (3) have paying customers who want it to be supported, so it's worth them spending the time needed on it? (I have no knowledge of whether that's the case or not, it just seems like an obvious possibility that you overlooked, since Nvidia pays developers to work on Xorg drivers because it brings in revenue for them.) -- -Alan Coopersmith- alan.coopersm...@sun.com Oracle Solaris Platform Engineering: X Window System ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xrandr dual-screen usability survery (Was: Dual-head config broke with update to 1.4.2)
Am 02/18/2010 03:57 PM, Alan Coopersmith schrieb: or (3) have paying customers who want it to be supported, so it's worth them spending the time needed on it? (I have no knowledge of whether that's the case or not, it just seems like an obvious possibility that you overlooked, since Nvidia pays developers to work on Xorg drivers because it brings in revenue for them.) Oh indeed ... which pragmatically implies the dual economic imperative, (4) lacking significant paying customer base demanding removal of classic multiscreen support... Jokingly, Eeri Kask ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xrandr dual-screen usability survery (Was: Dual-head config broke with update to 1.4.2)
Martin Cracauer, le Wed 17 Feb 2010 09:45:25 -0500, a écrit : Before I pass final verdict, what would be involved in -say- hacking up fvwm2 to deal with xrandr? Note http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=395500 Actually you just need to restart fvwm to make it notice the new layout, so it's not _so_ bad. Samuel ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xrandr dual-screen usability survery (Was: Dual-head config broke with update to 1.4.2)
Martin Cracauer: Overall my original impression has been reinforced: you basically dropped what hackers need when getting work done on a desktop Unix machine in favor of what managerish types coming from Windows need when standing in front of a projector and need to get their single-task thing done. Have you looked at any of the window managers that are more oriented to this type of workflow: 1. xmonad: http://www.xmonad.org/ 2. awesome: http://awesome.naquadah.org/ 3. i3: http://i3.zekjur.net/ Those are all tiling window managers, which is what I prefer, I still use ion2, which is not actively being developed. wikipedia has an exhaustive list of window managers: - http://en.wikipedia.org/wiki/X_window_manager -Jesse ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xrandr dual-screen usability survery (Was: Dual-head config broke with update to 1.4.2)
Martin Cracauer wrote: Here are the results of my quick survey of Window Managers present in Debian/Stable. That is the same Debian that has the Xorg server with classic dualhead effectively removed. Isn't classic dualhead removed by the specific drivers? I didn't think anything had changed in the Xorg server itself, and that drivers like nvidia's closed driver that chose to provide this mode still work. -- -Alan Coopersmith- alan.coopersm...@sun.com Oracle Solaris Platform Engineering: X Window System ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xrandr dual-screen usability survery (Was: Dual-head config broke with update to 1.4.2)
On Wed, Feb 17, 2010 at 9:45 AM, Martin Cracauer craca...@cons.org wrote: Here are the results of my quick survey of Window Managers present in Debian/Stable. That is the same Debian that has the Xorg server with classic dualhead effectively removed. The goal is to see how practical xrandr is for dual-screen purposes, today. I started the X11 server with 1400x1050 on the internal LCD of my Thinkpad and then added a monitor on the VGA port via randr. fvwm2: completely broken, cannot even get keyboard focus to the second screen, although you can move clients there with the mouse. Enlightenment only has E16 in Debian/stable. I will compile E17 later to see whether it has virtual desktop support with xrandr but I did give E16 a spin. Entirely broken. The second desktop cannot pan, so you never get to see the WM bars at the bottom. There is graphical corruption when moving windows (leaves the trace) and graphical corruption from some other action I didn't identify (black goo under top bar). I took photos in case you want to see. GNOME and KDE are behaving the same: kinda works but as expected it has no support for individual virtual desktop switching (yet?). But there are problems with GNOME/KDE even if you accept the lack of virtual desktops. Just opening GIMP in the xrandr'ed X11 server under GNOME makes GIMP come up half on the left screen and half on the right screen (photo available). It even has single dialog boxes that are obviously hardcoded to open in the middle of what GIMP thinks is the display, and that means it has a dialog box coming up between the screens with the yepp buttom on the main screen on the nah on the second screen. I assume this is the same as if you had used Xinerama, and it is one other major reason why I used individual displays for dual-head, and never used Xinerama. What version of GONE/KDE did you test? If it's as old as your xserver it may not support xinerama hints. All recent versions from the last few years support xinerama hints and handle window and dialog message placement appropriately on multi-head displays. Even outside of GIMP problems there's more trouble when running KDE and GNOME, namely that the second screen doesn't pan so you can never reach (or read) the bottom taskbar. That works just fine in classic dualhead. I also noticed that even GNOME's internal dialogs are confused. For example, the battery status pop-up indicator for battery status comes up half on the left and half on the right display. Compiz: broken, hangs. No idea whether that's due to the xrandr or something else. Compiz requires 3D support, you'd need to make sure that is enabled. Anyway... It looks to me like removing classic dualhead has been done way ahead of time. The above is certainly not usable for dual-screen setups the way I and people I know get their work done, and annoying for many other people, witness the GIMP misbehavior. No one removed zaphod support. As I've said several times, we've attempted to keep the feature alive (in fact I think radeon is the only xrandr capable driver that does), but in some cases, like yours, the wrong outputs get selected. What I've said again and again is that it's not a priority for us developers to fix this for all cases. It should not be too hard to fix the driver to select which head you want to use for zaphod mode, I just don't have the time at the moment. If you want to have a crack at it, I'm happy to point you in the right direction. I originally thought that KDE/GNOME might work well enough if you accept the lack of individual virtual desktop switching, but it is just not the case. Just GIMP is basically confused to the point of unusability and if I used GNOME or KDE - how am I supposed to live without the bottom taskbar? And that's after me only trying GIMP, who knows which other multi-window programs are broken. In any case, myself I am not willing to live without individual virtual desktop switching in the first place. There's a reason why I picked a Unix over Windows, and that is that vendor's can't easily decide that my features without me being able to fight back. Overall my original impression has been reinforced: you basically dropped what hackers need when getting work done on a desktop Unix machine in favor of what managerish types coming from Windows need when standing in front of a projector and need to get their single-task thing done. Before I pass final verdict, what would be involved in -say- hacking up fvwm2 to deal with xrandr? I think you are confused. Most window managers already deal properly with xrandr. xrandr provides xinerama hints as to the geometry of the heads so that window managers can place windows appropriately. What you are trying to implement is head specific desktop switching which has nothing to do with xrandr. Alex Martin -- %%%
Re: xrandr dual-screen usability survery (Was: Dual-head config broke with update to 1.4.2)
On Wed, Feb 17, 2010 at 10:50 AM, Martin Cracauer craca...@cons.org wrote: Alan Coopersmith wrote on Wed, Feb 17, 2010 at 07:34:01AM -0800: Martin Cracauer wrote: Here are the results of my quick survey of Window Managers present in Debian/Stable. That is the same Debian that has the Xorg server with classic dualhead effectively removed. Isn't classic dualhead removed by the specific drivers? I didn't think anything had changed in the Xorg server itself, and that drivers like nvidia's closed driver that chose to provide this mode still work. Right, that is why my main desktops all still work with the same Xorg version, because they use the NVidia binary driver. Please read that as an Xorg server with non-randr dual-head support removed, as the X11 server process in use. The server and the driver still support zaphod mode. It should read, xserver with broken zaphod support for my specific system Alex Thanks for the fvwm2 tip, I'll try that later. Of course it won't do anything about the other client problems and the virtual desktop switching. Martin -- %%% Martin Cracauer craca...@cons.org http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/ ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xrandr dual-screen usability survery (Was: Dual-head config broke with update to 1.4.2)
Alex Deucher wrote on Wed, Feb 17, 2010 at 10:35:37AM -0500: On Wed, Feb 17, 2010 at 9:45 AM, Martin Cracauer craca...@cons.org wrote: Here are the results of my quick survey of Window Managers present in Debian/Stable. ?That is the same Debian that has the Xorg server with classic dualhead effectively removed. The goal is to see how practical xrandr is for dual-screen purposes, today. I started the X11 server with 1400x1050 on the internal LCD of my Thinkpad and then added a monitor on the VGA port via randr. fvwm2: completely broken, cannot even get keyboard focus to the second screen, although you can move clients there with the mouse. Enlightenment only has E16 in Debian/stable. ?I will compile E17 later to see whether it has virtual desktop support with xrandr but I did give E16 a spin. ?Entirely broken. ?The second desktop cannot pan, so you never get to see the WM bars at the bottom. ?There is graphical corruption when moving windows (leaves the trace) and graphical corruption from some other action I didn't identify (black goo under top bar). ?I took photos in case you want to see. GNOME and KDE are behaving the same: kinda works but as expected it has no support for individual virtual desktop switching (yet?). But there are problems with GNOME/KDE even if you accept the lack of virtual desktops. ?Just opening GIMP in the xrandr'ed X11 server under GNOME makes GIMP come up half on the left screen and half on the right screen (photo available). ?It even has single dialog boxes that are obviously hardcoded to open in the middle of what GIMP thinks is the display, and that means it has a dialog box coming up between the screens with the yepp buttom on the main screen on the nah on the second screen. ?I assume this is the same as if you had used Xinerama, and it is one other major reason why I used individual displays for dual-head, and never used Xinerama. What version of GONE/KDE did you test? If it's as old as your xserver it may not support xinerama hints. All recent versions from the last few years support xinerama hints and handle window and dialog message placement appropriately on multi-head displays. It is from the same Debian/stable that has the ATI driver that broke non-xrand. In fact all the testing I have done and reported on is made with a brand-new install with no local changes of Debian-stable as of last week. Just thought I mention this so that people don't think I messed with things. I have put the list of installed packages with version numbers on: http://www.cons.org/tmp/list-of-packages.txt Looks like GNOME 2.20-2.22 and KDE 4.3. Even outside of GIMP problems there's more trouble when running KDE and GNOME, namely that the second screen doesn't pan so you can never reach (or read) the bottom taskbar. ?That works just fine in classic dualhead. I also noticed that even GNOME's internal dialogs are confused. ?For example, the battery status pop-up indicator for battery status comes up half on the left and half on the right display. Compiz: broken, hangs. ?No idea whether that's due to the xrandr or something else. Compiz requires 3D support, you'd need to make sure that is enabled. name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group client glx vendor string: SGI client glx version string: 1.4 client glx extensions: Anyway... It looks to me like removing classic dualhead has been done way ahead of time. ?The above is certainly not usable for dual-screen setups the way I and people I know get their work done, and annoying for many other people, witness the GIMP misbehavior. No one removed zaphod support. As I've said several times, we've attempted to keep the feature alive (in fact I think radeon is the only xrandr capable driver that does), but in some cases, like yours, the wrong outputs get selected. What I've said again and again is that it's not a priority for us developers to fix this for all cases. It should not be too hard to fix the driver to select which head you want to use for zaphod mode, I just don't have the time at the moment. If you want to have a crack at it, I'm happy to point you in the right direction. Sorry that really doesn't count. You can't just go and select the DVI port on a notebook that has no DVI output, subsequently drop that screen without as much as an error message (how Windowsish) and offer no config option. On a notebook where everything worked fine and dandy with the same software just one release
Re: xrandr dual-screen usability survery (Was: Dual-head config broke with update to 1.4.2)
Martin Cracauer, le Wed 17 Feb 2010 10:50:12 -0500, a écrit :
Thanks for the fvwm2 tip, I'll try that later. Of course it won't do
anything about the other client problems and the virtual desktop
switching.
Note that virtual desktop switching is handled by fvwm2 too. Initially
I thought having independent virtual desktop switching would be useful.
Since fvwm2 doesn't do it, I ended up just sticking windows on one
screen, and thus only get virtual desktop on the other screen. This
{ static on one hand, dynamic on the other hand } setup is in the end
quite good.
Samuel
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xrandr dual-screen usability survery (Was: Dual-head config broke with update to 1.4.2)
Samuel Thibault wrote on Wed, Feb 17, 2010 at 05:10:19PM +0100:
Martin Cracauer, le Wed 17 Feb 2010 10:50:12 -0500, a ?crit :
Thanks for the fvwm2 tip, I'll try that later. Of course it won't do
anything about the other client problems and the virtual desktop
switching.
Note that virtual desktop switching is handled by fvwm2 too. Initially
I thought having independent virtual desktop switching would be useful.
Since fvwm2 doesn't do it, I ended up just sticking windows on one
screen, and thus only get virtual desktop on the other screen. This
{ static on one hand, dynamic on the other hand } setup is in the end
quite good.
Hmmm.
On first sight that works for the situation with the movie on the
right screen all right.
But what do I do about the situation where the off-screen is switched
between a bunch of monitoring/IRC/IMs and a gimp session? (gimp is
multi-windowed)
Apart from that, in the movie situation wouldn't clients that open
dialog boxes in the middle of what they think is the screen obscure
parts of the movie at random times?
I still see problems here and no advantages.
Martin
--
%%%
Martin Cracauer craca...@cons.org http://www.cons.org/cracauer/
FreeBSD - where you want to go, today. http://www.freebsd.org/
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xrandr dual-screen usability survery (Was: Dual-head config broke with update to 1.4.2)
Samuel Thibault wrote on Wed, Feb 17, 2010 at 05:29:12PM +0100: Martin Cracauer, le Wed 17 Feb 2010 11:17:52 -0500, a ?crit : Apart from that, in the movie situation wouldn't clients that open dialog boxes in the middle of what they think is the screen obscure parts of the movie at random times? If they properly use the xinerama information that provides the sizes of the various screens, they wouldn't. But in practice, in just 10 minutes of testing, I have seen both GNOME-panel and GIMP do it, in the same distribution that has the offending Xorg driver. I don't see a strong argument here that makes me drop my original objections to Xinerama. Martin -- %%% Martin Cracauer craca...@cons.org http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/ ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xrandr dual-screen usability survery (Was: Dual-head config broke with update to 1.4.2)
On Wed, Feb 17, 2010 at 11:03 AM, Martin Cracauer craca...@cons.org wrote: Alex Deucher wrote on Wed, Feb 17, 2010 at 10:35:37AM -0500: On Wed, Feb 17, 2010 at 9:45 AM, Martin Cracauer craca...@cons.org wrote: Here are the results of my quick survey of Window Managers present in Debian/Stable. ?That is the same Debian that has the Xorg server with classic dualhead effectively removed. The goal is to see how practical xrandr is for dual-screen purposes, today. I started the X11 server with 1400x1050 on the internal LCD of my Thinkpad and then added a monitor on the VGA port via randr. fvwm2: completely broken, cannot even get keyboard focus to the second screen, although you can move clients there with the mouse. Enlightenment only has E16 in Debian/stable. ?I will compile E17 later to see whether it has virtual desktop support with xrandr but I did give E16 a spin. ?Entirely broken. ?The second desktop cannot pan, so you never get to see the WM bars at the bottom. ?There is graphical corruption when moving windows (leaves the trace) and graphical corruption from some other action I didn't identify (black goo under top bar). ?I took photos in case you want to see. GNOME and KDE are behaving the same: kinda works but as expected it has no support for individual virtual desktop switching (yet?). But there are problems with GNOME/KDE even if you accept the lack of virtual desktops. ?Just opening GIMP in the xrandr'ed X11 server under GNOME makes GIMP come up half on the left screen and half on the right screen (photo available). ?It even has single dialog boxes that are obviously hardcoded to open in the middle of what GIMP thinks is the display, and that means it has a dialog box coming up between the screens with the yepp buttom on the main screen on the nah on the second screen. ?I assume this is the same as if you had used Xinerama, and it is one other major reason why I used individual displays for dual-head, and never used Xinerama. What version of GONE/KDE did you test? If it's as old as your xserver it may not support xinerama hints. All recent versions from the last few years support xinerama hints and handle window and dialog message placement appropriately on multi-head displays. It is from the same Debian/stable that has the ATI driver that broke non-xrand. In fact all the testing I have done and reported on is made with a brand-new install with no local changes of Debian-stable as of last week. Just thought I mention this so that people don't think I messed with things. I have put the list of installed packages with version numbers on: http://www.cons.org/tmp/list-of-packages.txt Looks like GNOME 2.20-2.22 and KDE 4.3. Works here on all recent-ish systems; ubuntu and redhat systems from the last couple years. Even outside of GIMP problems there's more trouble when running KDE and GNOME, namely that the second screen doesn't pan so you can never reach (or read) the bottom taskbar. ?That works just fine in classic dualhead. I also noticed that even GNOME's internal dialogs are confused. ?For example, the battery status pop-up indicator for battery status comes up half on the left and half on the right display. Compiz: broken, hangs. ?No idea whether that's due to the xrandr or something else. Compiz requires 3D support, you'd need to make sure that is enabled. name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group client glx vendor string: SGI client glx version string: 1.4 client glx extensions: You need to check the full output. Also, compiz requires texture_from_pixmap which means you need to start it with LIBGL_ALWAYS_INDIRECT=1 Anyway... It looks to me like removing classic dualhead has been done way ahead of time. ?The above is certainly not usable for dual-screen setups the way I and people I know get their work done, and annoying for many other people, witness the GIMP misbehavior. No one removed zaphod support. As I've said several times, we've attempted to keep the feature alive (in fact I think radeon is the only xrandr capable driver that does), but in some cases, like yours, the wrong outputs get selected. What I've said again and again is that it's not a priority for us developers to fix this for all cases. It should not be too hard to fix the driver to select which head you want to use for zaphod mode, I just don't have the time at the moment. If you want to have a crack at it, I'm happy to point you in the right
Re: xrandr dual-screen usability survery (Was: Dual-head config broke with update to 1.4.2)
On Wed, 17 Feb 2010 11:38:18 -0500 Martin Cracauer craca...@cons.org wrote: Samuel Thibault wrote on Wed, Feb 17, 2010 at 05:29:12PM +0100: Martin Cracauer, le Wed 17 Feb 2010 11:17:52 -0500, a ?crit : Apart from that, in the movie situation wouldn't clients that open dialog boxes in the middle of what they think is the screen obscure parts of the movie at random times? If they properly use the xinerama information that provides the sizes of the various screens, they wouldn't. But in practice, in just 10 minutes of testing, I have seen both GNOME-panel and GIMP do it, in the same distribution that has the offending Xorg driver. I don't see a strong argument here that makes me drop my original objections to Xinerama. Martin I think you should take this to a debian list... I'm on Gentoo and have no problems with apps popping up between my two screens. (using fluxbox, gnome or kde) i thought the ratpoison wm would work like you want? maybe that is something you gonna like. On the premise, that it is too hard to maintain both modes (zaphod and xrandr) i'm all for the xrandr scheme because it is the more powerful of the two schemes. You can't put windows half on one and half on the other screen with zaphod. while you can emulate zaphod with xinerama hints on xrandr. cheers, Flo ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
