xrandr backend doesn't update atom _NET_WORKAREA

[Walther]

The root atom _NET_WORKAREA should hold the size of the desktop, and can be used by applications (for instance, OpenOffice impress uses it for size to use for presentations).

You can check the value with: "xprop -root _NET_WORKAREA"

For some reason, using disper 0.3.0 (at least with the xrandr backend) doesn't get this atom updated while the command xrandr does. Curiously, xrandr is not using any x11 calls, so it appears the problem is in the arguments for the xrandr methods used.

I've been trying to solve this for a while, but I thought I'd report it in case somebody else can get around to it first.

[Walther (walther-md)]

Okay, I figured out what's happening... apparently, it might be a bug in xrandr or the documentation for it.

When you check your own code, it has this nice comment in apply_output_config (xrandr/core.py):

        # Seems that this line should go here, because:
        # "All active monitors must be configured to display a
        # subset of the specified size, else a Match error results."
        # (from XrandR protocol specification,
        # http://cgit.freedesktop.org/xorg/proto/randrproto/tree/randrproto.txt)
           self.set_size(self._width, self._height,
                      self._width_mm, self._height_mm)

However, in practice, when you set each individual monitor, and then do a call to "set_size", the root atom is not updated. However, if instead, I just do what the xrandr program does, which is to disable each screen which "won't fit", then "set_size," and THEN apply the config, the atom is properly updated >.<

Actually, thinking about it, it appears that the original call to "set_size" is not working, because when I ran these two commands:
./disper.py -s -v -r 1400x1050
./disper.py -s -v -r 1680x1050

The second invocation will skip calling XRRSetScreenSize, because the check "if (width, height, width_mm, height_mm) == self.get_size()" returns true. So it would seem the real bug is that the call to "XRRSetScreenSize" is actually invalid? Unfortunately that function returns void, so you can't really check if this is the case...

I attach a patch against version 0.3.0 which "fixes" disper to work. Though now I am wondering if the real bug isn't somewhere else... I'll keep working on this as time allows :x

[Walther (walther-md)]

All right.... some final reading on that link found me this gem:

from RRSetCrtcConfig:

This request sets the CRTC to the specified position, mode, rotation
 and reflection. The entire area of the CRTC must fit within the
 screen size, else a Match error results. As an example, rotating the
 screen so that a single CRTC fills the entire screen before and
 after may necessitate disabling the CRTC, resizing the screen,
 then re-enabling the CRTC at the new configuration to avoid an
 invalid intermediate configuration.

So the proper behaviour seems to be what xrandr already does:

1. Disable any active outputs whose screen-size won't match the new size
2. Call RRSetScreenSize
3. Call RRSetCrtcConfig for all outputs to be configured.

So my patch is already a "proper" solution, except that it needs to disable any outputs that "are active and won't fit" on the new size, rather than blindly disabling all of the "changed" outputs... but I am too exhausted to work on this right now.

[Walther (walther-md)]

All right, I think I have fixed this issue in the attached patch.

I did what xrandr does:
1. Go through active crtcs and disable those whose "active, current configuration" would not match the new calculated dimensions.
2. Invoke set_size
3. Go through crtcs and apply changes to any which have been tagged as modified.

And now the _NET_WORKAREA is properly updated when changing resolutions. I would like to have some more testing done here, such as support for rotations, but it seems disper doesn't support rotation at all yet, so there appears to be little that can be tested.

[wvengen (wvengen)]

Hi Walther, thank you! I do not see this problem, but your patch does not seem to have negative effects. Could you please test if it's ok with current trunk?