On Wed, Feb 17, 2010 at 11:03 AM, Martin Cracauer <[email protected]> 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 <[email protected]> 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 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 earlier. You did > effectively remove dual-screen support other than randr from the ATI > driver for a substantial subset of hardware out there. > > 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. So fine, here's the yearly zaphod fix: http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=579cdcf9b4e38c791a497b747a055fc0a07d8dd6 It would be nice if someone that cared about it would actually pick up the torch to maintain it. >> > 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. > > No, there are just two different issues. > > I thought I only have a problem with the lack of independent virtual > desktop switching. > > What I found out now is that there are many more problems, namely: > - the inability to reach the lower taskbar in GNOME and KDE > - E16 being outright broken (which seems to be xrandr, not xinerama) > - confused clients such as GIMP and GNOME that have dialog boxes half > on one screen and half on the other > > This means that randr is in no way a suitable replacement for classic > dual-screen for a static desktop situation. Sure, it helps when you > carry around a notebook and want to use a projector. But for a static > desktop long-uptime work situation it's unusable even if you are > willing to use GNOME or KDE. LOTS of people, not just windows users, and not just people that want to use a projector prefer a single logical desktop. In fact I would say the vast majority prefers it. I rarely use a projector regularly; mostly I write code, but I prefer to be able to move windows between heads. > > You are effectively reducing both Linux and the BSD to some > Windows-equivalent - except that on Windows you have more clients that > are already hacked up to properly deal with the spanned single > screen. > Give me a break. X has supported single logical desktop multi-head as long as windows has. It's not a windows thing, it's a user preference thing. Alex > Martin > -- > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > Martin Cracauer <[email protected]> http://www.cons.org/cracauer/ > FreeBSD - where you want to go, today. http://www.freebsd.org/ > _______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
