Re: x-display-pixel-width/height inconsistency

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 28 Apr 2013 19:16:25 +0200, "Jan D." <address@hidden> said:

>>> A general objection is that XRandr/Xinerama is not used, so the
>>> non-Gtk+ code relies on a freedesktop compliant window manager,
>>> rather than taking the general approach.  If XRandr/Xinerama is
>>> used, no split between Gtk+ and non-Gtk+ code is needed.
>>> Xrandr/Xinerama is what Gtk+ use anyway so we are not adding any
>>> new dependencies.
>> 
>> Of course, patches welcome.  (And also for implementations for
>> other platforms.)  I guess XRandR 1.2 covers most of the current
>> uses.

> Patch attached. The patch includes your code.  Actually 1.3 is
> better, it has XRRGetOutputPrimary.  Without it we have to guess.

Thanks.  It was so quick!

I found a couple of trivial mistakes in the patch:

  * In x_get_monitor_attributes:
    `XRenderQueryExtension' should be `XRRQueryExtension'.

  * In x_make_monitor_attribute_list:
    `return attributes_list' is missing at the end.

Even with the above fixes, I got different results between GDK and
XRandR implementations with Xquartz 2.7.4 on OS X 10.8.

  GDK:

  (((geometry (left + 0) (top + 22) (width . 2560) (height . 1418))
    (workarea (left + 0) (top + 22) (width . 2560) (height . 1418))
    (mm-size (width . 677) (height . 374))
    (frames #<frame address@hidden 0x1042b4050>))
   ((geometry (left + 2560) (top + 0) (width . 960) (height . 600))
    (workarea (left + 2560) (top + 0) (width . 960) (height . 600))
    (mm-size (width . 254) (height . 158))
    (frames)))

  XRandR:

  (((geometry (left + 0) (top + 0) (width . 3520) (height . 1440))
    (workarea (left + 0) (top + 0) (width . 3520) (height . 1440))
    (mm-size (width . 0) (height . 0))
    (frames #<frame address@hidden 0x1022ae850>)))

  (Xinerama gave the same result as GDK did.)

As you can see, there is a difference even in the number of monitors.

Maybe you need to register some callback to call
XRRUpdateConfiguration?  XRANDR manual says:

  Xlib notification

  Clients must call back into Xlib using XRRUpdateConfiguration when
  screen configuration change notify events are generated (or root
  window configuration changes occur, to update Xlib’s view of the
  resolution, size, rotation, reflection or subpixel order. Generally,
  toolkits will perform this operation on behalf of applications; we
  did not want to change display structure data behind the back of
  toolkits, as in multithreaded clients, various race conditions might
  occur. Toolkits should provide clients some mechanism for
  notification of screen change, of course.

  (http://www.x.org/archive/current/doc/man/man3/Xrandr.3.xhtml)

> Another comment: Your defun is x-display-monitor-attributes-list.
> Aren't we supposed to try to avoid the use of x-prefixed functions?
> display-monitor-attributes-list sounds fine to me.

Actually I'm not so familiar with this naming convention matter, and
just followed the other old x-display-* functions.  Feel free to
adjust it for (new?) convention.

                                     YAMAMOTO Mitsuharu
                                address@hidden