xrandr dual-screen usability survery (Was: Dual-head config broke with update to 1.4.2)

[Martin Cracauer]

Alex Deucher wrote on Wed, Feb 17, 2010 at 10:35:37AM -0500: 
> On Wed, Feb 17, 2010 at 9:45 AM, Martin Cracauer <cracauer at 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 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?

> > 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.

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.

Martin
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer at cons.org>   http://www.cons.org/cracauer/
FreeBSD - where you want to go, today.      http://www.freebsd.org/