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

[Alex Deucher]

On Wed, Feb 17, 2010 at 11:03 AM, Martin Cracauer <cracauer at 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 <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.

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 <cracauer at cons.org>   http://www.cons.org/cracauer/
> FreeBSD - where you want to go, today.      http://www.freebsd.org/
>