Re: [PATCH app/xdpyinfo v4] Use XRANDR 1.2 extension for reporting dimensions and resolution per output
Hello, can you review 4th version of this patch below?
On Monday 07 May 2018 23:34:22 Pali Rohár wrote:
> XServer with enabled XRANDR 1.2 extension does not provide correct
> dimensions from DisplayWidthMM() and DisplayHeightMM() calls anymore.
> Values are calculated from fixed DPI 96.
>
> Therefore when XRANDR 1.2 extension is enabled, present and user requested
> for it, instead use XRRGetScreenResources() and XRRGetOutputInfo() calls to
> get correct dimensions and resolution information. Core dimensions from
> DisplayWidthMM() and DisplayHeightMM() are still reported.
>
> Otherwise when XRANDR 1.2 extension is enabled, present and user did not
> request for it (which is default), show note that printed dimension does
> not have to be correct and instruct user to run xdpyinfo with -ext RANDR.
>
> Also update manual page and add information that xdpyinfo does not provide
> correct information about DPI.
>
> Signed-off-by: Pali Rohár
> ---
> Changes since v3:
> * Always show core x screen output
>
> Changes since v2:
> * Fixed dimensions calculation when rotation is active
> * Show XRANDR output only when explicitly requested
> * Update manpage
>
> Changes since v1:
> * Fixed detection of presence of XRANDR 1.2
> * Fixed resolution calculation when dimensions are zero
> ---
> Makefile.am | 2 +
> configure.ac | 12 ++
> man/xdpyinfo.man | 7 +++
> xdpyinfo.c | 129
> ++-
> 4 files changed, 140 insertions(+), 10 deletions(-)
>
> diff --git a/Makefile.am b/Makefile.am
> index 2f21dda..496094e 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -35,6 +35,7 @@ AM_CFLAGS = \
> $(DPY_XCOMPOSITE_CFLAGS) \
> $(DPY_XINERAMA_CFLAGS) \
> $(DPY_DMX_CFLAGS) \
> + $(DPY_XRANDR_CFLAGS) \
> $(DPY_XTST_CFLAGS)
>
> xdpyinfo_LDADD = \
> @@ -49,6 +50,7 @@ xdpyinfo_LDADD = \
> $(DPY_XCOMPOSITE_LIBS) \
> $(DPY_XINERAMA_LIBS) \
> $(DPY_DMX_LIBS) \
> + $(DPY_XRANDR_LIBS) \
> $(DPY_XTST_LIBS)
>
> xdpyinfo_SOURCES = \
> diff --git a/configure.ac b/configure.ac
> index 73dce26..4473faa 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -132,6 +132,18 @@ else
> echo "without dmx"
> fi
>
> +AC_ARG_WITH(xrandr, AS_HELP_STRING([--without-xrandr],[Disable xrandr 1.2
> support.]),
> + [USE_XRANDR="$withval"], [USE_XRANDR="yes"])
> +if test "x$USE_XRANDR" != "xno" ; then
> + PKG_CHECK_MODULES(DPY_XRANDR, xrandr >= 1.2,
> + [SAVE_CPPFLAGS="$CPPFLAGS"
> + CPPFLAGS="$CPPFLAGS $DPY_XRANDR_CFLAGS $DPY_X11_CFLAGS"
> + AC_CHECK_HEADERS([X11/extensions/Xrandr.h],,,[#include
> ])
> + CPPFLAGS="$SAVE_CPPFLAGS"],[echo "not found"])
> +else
> + echo "without xrandr 1.2"
> +fi
> +
> PKG_CHECK_MODULES(DPY_XTST, xtst,
> [SAVE_CPPFLAGS="$CPPFLAGS"
> CPPFLAGS="$CPPFLAGS $DPY_XTST_CFLAGS $DPY_X11_CFLAGS"
> diff --git a/man/xdpyinfo.man b/man/xdpyinfo.man
> index c3d5c6d..5df44ea 100644
> --- a/man/xdpyinfo.man
> +++ b/man/xdpyinfo.man
> @@ -51,6 +51,13 @@ Detailed information about a particular extension is
> displayed with the
> \fBall\fP, information about all extensions supported by both \fIxdpyinfo\fP
> and the server is displayed.
> .PP
> +Do not use this utility for determining dimensions of monitor when XRANDR
> 1.2+
> +extension is enabled for X screen, because it does not provide them. For
> +determining physical dimensions or DPI of particular monitor use either
> +.IR xrandr (__appmansuffix__)
> +utility or call xdpyinfo with parameter \fB\-ext RANDR\fP (supported since
> +xdpyinfo version 1.3.3).
> +.PP
> If \fB-version\fP is specified, xdpyinfo prints its version and exits,
> without
> contacting the X server.
> .SH ENVIRONMENT
> diff --git a/xdpyinfo.c b/xdpyinfo.c
> index 152e32c..8d24b40 100644
> --- a/xdpyinfo.c
> +++ b/xdpyinfo.c
> @@ -76,6 +76,10 @@ in this Software without prior written authorization from
> The Open Group.
> # define DMX
> # endif
>
> +# if HAVE_X11_EXTENSIONS_XRANDR_H
> +# define XRANDR
> +# endif
> +
> #endif
>
> #ifdef WIN32
> @@ -137,6 +141,9 @@ in this Software without prior written authorization from
> The Open Group.
> #ifdef DMX
> #include
> #endif
> +#ifdef XRANDR
> +#include
> +#endif
> #include
> #include
> #include
> @@ -442,6 +449,10 @@ print_visual_info(XVisualInfo *vip)
> vip->bits_per_rgb);
> }
>
> +#ifdef XRANDR
> +static Bool print_xrandr = False;
> +#endif
> +
> static void
> print_screen_info(Display *dpy, int scr)
> {
> @@ -455,6 +466,14 @@ print_screen_info(Display *dpy, int scr)
> double xres, yres;
> int ndepths = 0, *depths = NULL;
> unsigned int width, height;
> +Bool has_xrandr = False;
> +#ifdef XRANDR
> +int event_base, error_base;
> +int major, minor;
> +XRRScreenResources *res;
> +XRROutputInfo *output;
> +XRRCrtcInfo *crtc;
> +#endif
>
> /*
> *
Re: [PATCH app/xrandr] Fix checking for valid argument of --dpi
Gentle reminder for a patch which I sent 5 months ago...
On Monday 07 May 2018 23:38:10 Pali Rohár wrote:
> Hello, can you review my patch below?
>
> On Thursday 12 April 2018 20:52:21 Pali Rohár wrote:
> > Function strtod() sets strtod_error to the pointer of the first invalid
> > character and therefore it does not have to be first character from input.
> > When input is valid then it points to nul byte. Conversion error is
> > indicated by setted errno. Zero-length argument and zero DPI is invalid
> > too.
> >
> > Update also error message about invalid argument.
> >
> > Signed-off-by: Pali Rohár
> > ---
> > xrandr.c | 7 ---
> > 1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/xrandr.c b/xrandr.c
> > index 7f1e867..1960bbf 100644
> > --- a/xrandr.c
> > +++ b/xrandr.c
> > @@ -3115,9 +3115,10 @@ main (int argc, char **argv)
> > }
> > if (!strcmp ("--dpi", argv[i])) {
> > char *strtod_error;
> > - if (++i >= argc) argerr ("%s requires an argument\n", argv[i-1]);
> > + if (++i >= argc || !argv[i][0]) argerr ("%s requires an
> > argument\n", argv[i-1]);
> > + errno = 0;
> > dpi = strtod(argv[i], _error);
> > - if (argv[i] == strtod_error)
> > + if (*strtod_error || errno || dpi == 0)
> > {
> > dpi = 0.0;
> > dpi_output_name = argv[i];
> > @@ -3567,7 +3568,7 @@ main (int argc, char **argv)
> > XRROutputInfo *output_info;
> > XRRModeInfo *mode_info;
> > if (!dpi_output)
> > - fatal ("Cannot find output %s\n", dpi_output_name);
> > + fatal ("%s is not valid DPI nor valid output\n",
> > dpi_output_name);
> > output_info = dpi_output->output_info;
> > mode_info = dpi_output->mode_info;
> > if (output_info && mode_info && output_info->mm_height)
>
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC] Allow fd.o to join forces with X.Org
On Tue, 16 Oct 2018 at 08:17, Peter Hutterer wrote:
> On Mon, Oct 15, 2018 at 10:49:24AM -0400, Harry Wentland wrote:
> > + \item Support free and open source projects through the
> > freedesktop.org
> > + infrastructure. For projects outside the scope of item (\ref{1})
> > support
> > + extends to project hosting only.
> > +
>
> Yes to the idea but given that the remaining 11 pages cover all the legalese
> for xorg I think we need to add at least a section of what "project hosting"
> means. Even if it's just a "includes but is not limited to blah". And some
> addition to 4.1 Powers is needed to spell out what the BoD can do in regards
> to fdo.
Yeah, I think it makes sense. Some things we do:
- provide hosted network services for collaborative development,
testing, and discussion, of open-source projects
- administer, improve, and extend this suite of services as necessary
- assist open-source projects in their use of these services
- purchase, lease, or subscribe to, computing and networking
infrastructure allowing these services to be run
Cheers,
Daniel
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC] Allow fd.o to join forces with X.Org
On Wed, Oct 17, 2018 at 2:05 PM Daniel Stone wrote:
>
> On Tue, 16 Oct 2018 at 08:17, Peter Hutterer wrote:
> > On Mon, Oct 15, 2018 at 10:49:24AM -0400, Harry Wentland wrote:
> > > + \item Support free and open source projects through the
> > > freedesktop.org
> > > + infrastructure. For projects outside the scope of item (\ref{1})
> > > support
> > > + extends to project hosting only.
> > > +
> >
> > Yes to the idea but given that the remaining 11 pages cover all the legalese
> > for xorg I think we need to add at least a section of what "project hosting"
> > means. Even if it's just a "includes but is not limited to blah". And some
> > addition to 4.1 Powers is needed to spell out what the BoD can do in regards
> > to fdo.
>
> Yeah, I think it makes sense. Some things we do:
> - provide hosted network services for collaborative development,
> testing, and discussion, of open-source projects
> - administer, improve, and extend this suite of services as necessary
> - assist open-source projects in their use of these services
> - purchase, lease, or subscribe to, computing and networking
> infrastructure allowing these services to be run
I fully agree that we should document all this. I don't think the
bylaws are the right place though, much better to put that into
policies that the board approves and which can be adapted as needed.
Imo bylaws should cover the high-level mission and procedural details,
as our "constitution", with the really high acceptance criteria of
2/3rd of all members approving any changes. Some of the early
discussions tried to spell out a lot of the fd.o policies in bylaw
changes, but then we realized it's all there already. All the details
are much better served in policies enacted by the board, like we do
with everything else.
As an example, let's look at XDC. Definitely one of the biggest things
the foundation does, with handling finances, travel sponsoring grants,
papers committee, and acquiring lots of sponsors. None of this is
spelled out in the bylaws, it's all in policies that the board
deliberates and approves. I think this same approach will also work
well for fd.o.
And if members are unhappy with what the board does, they can fix in
the next election by throwing out the unwanted directors.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
