Re: Physical vs logical DPI on X
le to combine two outputs into one monitor, to split a single > output into multiple monitors, Correct me if I'm wrong, but I don't think it's possible to split a single output into multiple monitors, since adding an output to a monitor will remove it from the other monitors. > or even to override the auto-generated monitor for a an output. And all these > allow you to pass a width and height, effectively setting the DPI. E.g. > > xrandr --setmonitor DUMMY0-DPIOVERRIDE 1600/200x1200/200+0+0 DUMMY0 > > This seems like the definition of logical DPI, where the desktop environment > can give the user a nice control panel on how to adjust these things, either > directly by adding/removing/moving monitors, or by setting a DPI or scale > (200% e.g.) on an individual monitor, and then reflect that as RandR updates. Now this is an interesting side effect. I believe the original intent of the Monitor concept was to improve support for video walls and physical monitors that require two streams because of how large they are, but the possibility to override the physical size definitely allows for user-selection of the presented DPI. Would you then go look for the physical DPI as reported by the corresponding output(s)? > Based on all of this, it seems Qt should do the following: > > 1. If Xft.DPI has been set, respect that as a global override, and reflect > that as the logical DPI for all QScreens > 2. If not, reflect the resolution and size of individual RandR 1.5 monitors > as logical DPI per QScreen > 3. If 1.5 is not available, reflect the resolution and size of the X Screen > as a global logical DPI for all QScreens > 4. Reflect the resolution and size of the individual outputs as physical > DPI, or read EDID ourselves > > As far as I can tell this should cover DEs like Ubuntu 20.04 that sets a > global 192 Xft.DPI to represent 200% scaling (and fractional scales in > between 100% and 200%), as well as DEs that (in the future) allow per-monitor > DPI/scale control via the 1.5 monitors. I suspect this might not be future-proof: DEs that allow per-monitor DPI/scale control via RANDR 1.5 may still want to use Xft.DPI for legacy applications. I don't think there's a way out of this without adding some kind of side-channel setting (_NET_PER_MONITOR_DPI boolean property on the root window). So the idea could be: 1. If _NET_PER_MONITOR_DPI is set, and RANDR 1.5 is present, use Monitor info for logical DPI per QScreen; 2. if _NET_PER_MONITOR_DPI is set, and RANDR 1.5 is not present use to-be-determined user-controllable per-output property for logical DPI per QScreen; (assuming we want to support this kind of configuration, with new DE/WM on pre-RANDR1.5 server); 3. fall back to Xft/DPI => Xft.dpi => X Screen dpi as global logical DPI for all QScreens; (note that the X Screen dpi can change with RR, and clients can get a notification when it happens; if possible, do keep this into consideration); Honestly while we're at it I would appreciate if Qt spearheaded the separation of DPI scaling from UI scaling (with a separate root window property or XSETTING or whatever), but I understand if this is considered being “too much” (especially since AFAIK other OSes/display servers don't have the concept either, but feel free to correct me if I'm wrong). Cheers, Giuseppe Bilotta ___ 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: [PATCH app/xdpyinfo v4] Use XRANDR 1.2 extension for reporting dimensions and resolution per output
Hello,
this is still not acceptable. _Do not alter the main section output_,
and move the XRANDR-specific information into its own
extension-dedicated output function, instead of hacking around it with
the print_none_info function.
On Mon, May 7, 2018 at 11:34 PM Pali Rohár wrote:
> -xres = double) DisplayWidth(dpy,scr)) * 25.4) /
> - ((double) DisplayWidthMM(dpy,scr)));
> -yres = double) DisplayHeight(dpy,scr)) * 25.4) /
> - ((double) DisplayHeightMM(dpy,scr)));
> -
> printf ("\n");
> printf ("screen #%d:\n", scr);
> -printf (" dimensions:%dx%d pixels (%dx%d millimeters)\n",
> - XDisplayWidth (dpy, scr), XDisplayHeight (dpy, scr),
> - XDisplayWidthMM(dpy, scr), XDisplayHeightMM (dpy, scr));
> -printf (" resolution:%dx%d dots per inch\n",
> - (int) (xres + 0.5), (int) (yres + 0.5));
> +
> +#ifdef XRANDR
> +if (XRRQueryExtension (dpy, &event_base, &error_base) &&
> +XRRQueryVersion (dpy, &major, &minor) &&
> +(major > 1 || (major == 1 && minor >= 2)))
> +has_xrandr = True;
> +#endif
> +
> +#ifdef XRANDR
> +if (has_xrandr && print_xrandr)
> +{
> +res = XRRGetScreenResources (dpy, RootWindow (dpy, scr));
> +if (res) {
> +for (i = 0; i < res->noutput; ++i) {
> +output = XRRGetOutputInfo (dpy, res, res->outputs[i]);
> +if (!output || !output->crtc || output->connection !=
> RR_Connected)
> +continue;
> +
> +crtc = XRRGetCrtcInfo (dpy, res, output->crtc);
> +if (!crtc) {
> +XRRFreeOutputInfo (output);
> +continue;
> +}
> +
> +/* width and height is reported according to rotation, but
> mm_width and mm_height not */
> +if (crtc->rotation == RR_Rotate_0 || crtc->rotation ==
> RR_Rotate_180) {
> +width = crtc->width;
> +height = crtc->height;
> +} else {
> +width = crtc->height;
> +height = crtc->width;
> +}
> +
> +printf (" output: %s\n", output->name);
> +printf ("dimensions:%ux%u pixels (%lux%lu
> millimeters)\n",
> +width, height, output->mm_width, output->mm_height);
> +
> +if (output->mm_width && output->mm_height) {
> +xres = double) width) * 25.4) / ((double)
> output->mm_width));
> +yres = double) height) * 25.4) / ((double)
> output->mm_height));
> +} else {
> +xres = 0;
> +yres = 0;
> +}
> +printf ("resolution:%dx%d dots per inch\n",
> +(int) (xres + 0.5), (int) (yres + 0.5));
> +
> +XRRFreeCrtcInfo (crtc);
> +XRRFreeOutputInfo (output);
> +}
> +XRRFreeScreenResources (res);
> +}
> +
> +printf (" screen output: (union of all configured monitors)\n");
> +printf ("dimensions:%dx%d pixels (%dx%d millimeters)\n",
> +DisplayWidth (dpy, scr), DisplayHeight (dpy, scr),
> +DisplayWidthMM(dpy, scr), DisplayHeightMM (dpy, scr));
> +
> +xres = double) DisplayWidth(dpy,scr)) * 25.4) /
> +((double) DisplayWidthMM(dpy,scr)));
> +yres = double) DisplayHeight(dpy,scr)) * 25.4) /
> +((double) DisplayHeightMM(dpy,scr)));
> +printf ("resolution:%dx%d dots per inch\n",
> +(int) (xres + 0.5), (int) (yres + 0.5));
> +}
> +else
> +#endif
> +{
> +printf (" dimensions:%dx%d pixels (%dx%d millimeters)\n",
> +DisplayWidth (dpy, scr), DisplayHeight (dpy, scr),
> +DisplayWidthMM(dpy, scr), DisplayHeightMM (dpy, scr));
> +
> +xres = double) DisplayWidth(dpy,scr)) * 25.4) /
> +((double) DisplayWidthMM(dpy,scr)));
> +yres = double) DisplayHeight(dpy,scr)) * 25.4) /
> +((double) DisplayHeightMM(dpy,scr)));
> +printf (" resolution:%dx%d dots per inch\n",
> +(int) (xres + 0.5), (int) (yres + 0.5));
> +
> +if (has_xrandr)
> +printf ("NOTE: above information is obsoleted and may be
> incorrect\n"
> +" instead run `%s -ext RANDR' for correct
> output\n\n",
> +ProgramName);
> +}
> +
> depths = XListDepths (dpy, scr, &ndepths);
> if (!depths) ndepths = 0;
> printf (" depths (%d):", ndepths);
> @@ -1316,6 +1410,10 @@ static int print_dmx_info(Display *dpy, const char
> *extname)
>
> #endif /* DMX */
>
> +#ifdef XRANDR
> +static int print_none_info(Display *dpy, const char *extname) { return 1; }
> +#endif
> +
>
Re: [PATCH app/xrandr] Fix checking for valid argument of --dpi
Hello,
On Thu, Apr 12, 2018 at 8:53 PM Pali Rohár wrote:
> - 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]);
I don't think this change is necessary, if arg[i][0] is NULL it means
there _was_ an argument, but it was empty. Getting different error
messages from `xrandr --dpi ''` and `xrandr --dpi ' '` doesn't seem
like a good idea to me.
> + errno = 0;
> dpi = strtod(argv[i], &strtod_error);
> - if (argv[i] == strtod_error)
> + if (*strtod_error || errno || dpi == 0)
While we're at it, I would make the check for dpi <= 0, since negative
values aren't valid either (in fact, negative values are effectively a
no-op, since they set the DPI from the current framebuffer settings,
and then set the virtual framebuffer physical dimensions from the
DPI).
Cheers,
Giuseppe Bilotta
___
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: Window scaling (aka owner sizes)
On Fri, Aug 31, 2018 at 6:53 AM Keith Packard wrote: > The root window size shouldn't be all that interesting to applications; > they really need to know the monitor sizes and positions, and that > information is available via RandR and Xinerama. So, I'm not all that > concerned about root window size; applications relying on that are > already broken. Well, the “global” (legacy) display size is still used by applications to get the global DPI as an Xft.dpi fallback (well, except for GTK3 for a while now), and Qt uses it in its mixed-DPI support (with the appropriate environment variable, it sets the internal per-window scaling based on the monitor DPI and the ratio of the global DPI to the DPI of the primary monitor). So arguably we could say that any application that does care about the legacy display size already has _some_ form of DPI support, so there should be no need to manipulate the reported value. > Ok, so to make this 'actually' work, I might have to scale not only the > window size, but the window position as well -- and then I might > actually have to scale *all* of the window sizes and positions for the > specified application. > Or, maybe we create a synthetic monitor and then pretend to applications > that their windows appear there instead. If the server is trapping screen resizing requests, then yes, one of these solutions would probably be necessary. The synthetic monitor is a very clean solution; the biggest danger is the “undebuggability” of the situation, unless xrandr (the tool) is extended to be able to peek into the per-application fake monitors as well. Or is this only for Xwayland? > I didn't want to change the owner position of the windows, but I now > wonder if that might not turn out ok? If you are meddling with global or RandR/Xinerama sizing, then yes, you probably need to scale the positions as well, since otherwise the application would be unable to do an e.g. “fake fullscreen” by setting a window size _and_ coordinates to match those of a Xinerama screen. However, “deep” scaling has a lot of corner cases where it may break down (e.g. do you also scale the value reported by Xft.dpi or Xcursor.size?) Also, what happens with multi-monitor setups? Do you only scale values for one of the monitors, or the whole setup? Consider the following setup (monospace required; and no, it's not made up, it's one of my actual setups): +---+-+ | | | | | L | | | | | V +-+ | | | | | H | | | | +---+-+ where V and L are standard-DPI monitors (say 1080p) with V rotated and L in portrait mode, and H is high DPI (say 4K) in portrait mode. H is the primary monitor, so when one “fullscreens” a game, that's generally going to happen on H. How does the scaling work if the game requests a fullscreen after a resizing of H? What happens if the same thing is done without V and L, or with V put on the right instead of the left? Or with a V1 on the left and a V2 on the right? -- Giuseppe "Oblomov" Bilotta ___ 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: Window scaling (aka owner sizes)
On Mon, Aug 27, 2018 at 7:38 PM Keith Packard wrote: > Giuseppe Bilotta writes: > > I guess the only way in which this can fail is if a client tries to > > draw its own decorations (or something) “outside” of their own window, > > assuming that origin+width or origin+height actually brings them there > > in the root context (I mean as opposed to using XTranslateCoords, > > which can be handled from within the server). > > They won't be able to draw 'outside' of their window -- all drawing to > the window is redirected to the composite pixmap and clipped to the > owner size. For applications with a border, the border also gets drawn > to the composite pixmap and then scaled to the current size, although > the border width is the same, so a tiled border may not look right. By drawing “outside” of their window I don't mean using the window's own GC context —that would actually work correctly, since it's the one that gets scaled— but rather using a (grand)parent window such as the root or vroot window(s). More in general, there could be issues with clients that interact with the geometry of other windows (the only examples I can think of are toys like AMOR or xsnow though, not sure if there's any “serious” program that could be affected by this). -- Giuseppe "Oblomov" Bilotta ___ 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: Window scaling (aka owner sizes)
Hello Keith, On Mon, Aug 27, 2018 at 8:25 AM Keith Packard wrote: > I'm doing a bit of work to help support applications that want to run at > a small fixed size. Wonderful endeavor. > The basic plan is to make the size-as-seen-by-the-owner different from > the size seen by the rest of the system, and then to either have the > server scale the output or get the compositing manager to do it. I guess the only way in which this can fail is if a client tries to draw its own decorations (or something) “outside” of their own window, assuming that origin+width or origin+height actually brings them there in the root context (I mean as opposed to using XTranslateCoords, which can be handled from within the server). > I'm wondering if there are others who would find this useful, and if > some of them might help get this into reasonable shape. Suggestions are > welcome! This sounds like an excellent solution to improve Hi- and most importantly mixed-DPI setups. I'm a bit swamped for the next month, but after that I can at the very least help test and debug the code, since I have multiple such setups. One thing that would definitely be useful for the mixed DPI case is some way to more or less automatically change the scaling factor based on window location (or at least Monitor it belongs to), at least in the case where the X server itself is doing the compositing. -- Giuseppe "Oblomov" Bilotta ___ 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: [PATCH app/xdpyinfo v3] Use XRANDR 1.2 extension for reporting dimensions and resolution per output
On Wed, Apr 18, 2018 at 3:33 PM, Pali Rohár wrote: > On Thursday 12 April 2018 16:34:15 Adam Jackson wrote: >> This should print the RANDR data in a separate stanza after the main >> output, like the other extensions do. Again: the purpose of the core of >> xdpyinfo is to tell you what the connection block says. Don't make it >> print something else. > > This patch does not change anything in the output when command line > option for RANDR is not used. Therefore you would get same output as > before (without applying patch). > > And when RANDR is explicitly requested then it outputs correct dimension > information. Yes, it hides what is reported by connection block, but the > main problem is that this tools is not already used like you said. Users > and also scripts expects that they would get correct monitor/output > dimension from xdpyinfo and not something which do not match with their > physical monitor device. > > As Giuseppe said, this seems like a good compromise. When no parameter > is specified then xdpyinfo reports exactly same data as without this > patch. And with this patch which adds support for optional RANDR > parameter, then it reports dimensions for each monitor/output correctly. > So users would see what they are already expecting and want. No, in the RANDR case you are still replacing the core output, which is not what I suggested. Instead, the RANDR information should be provided _separately_ and _in addition to_ the core output. So instead of defining a useless print_none_info, put the RANDR code in print_randr_info and add _that_ to the known_extensions array. -- Giuseppe "Oblomov" Bilotta ___ 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: [PATCH xserver] os: Call FlushClient() before sending FD-passing messages
On Tue, Apr 10, 2018 at 5:14 AM, Keith Packard wrote: >> libxcb stores received file descriptors in the buffer of size 16 >> (XCB_MAX_PASS_FD). >> Whether it's possible that the X server will send more than 16 fds in a >> single reply >> and overflow the libxcb's buffer? > > It wouldn't be if the X server were careful in flushing things, but as > that seems 'hard', we should probably fix xcb. I don't think that's > terribly urgent as it would take a very strange situation to pass 16 fds > in a short amount of time, especially in such close proximity as to end > up not getting a reply that processes any of them in the middle of the > sequence. Unless this is done intentionally by a malicious server to overflow the client's xcb buffer. -- Giuseppe "Oblomov" Bilotta ___ 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: [PATCH app/xdpyinfo v2] Use XRANDR 1.2 extension for reporting dimensions and resolution per output
On Sun, Apr 8, 2018 at 8:25 PM, Pali Rohár wrote: > On Sunday 08 April 2018 19:22:28 Giuseppe Bilotta wrote: >> The values reported by xdpyinfo aren't bogus, they are what the core >> protocol is providing. > > For users as human readable output from xdpyinfo, those values are > bogus. For users it does not matter how xdpyinfo obtain those values. > Just that it provides values which do not match reality. > > I understand that those values comes from X server and xdpyinfo just > print what it receive. But for end-users of xdpyinfo this is really > irrelevant. That tool worked correctly prior changes in X server (do not > remember version). If your issue is with the default DPI reported by the X server, that's the thing you should be fixing, not what xdpyinfo is reporting. >> > There are plenty of bugs and lot of reports about this problem. >> >> Because people are using the wrong tool. > > I agree, but you can look at it from other side. This tool worked with > older X servers. If it is stopped working with new X servers, then > either tool itself should write information about it or do not report > those values at all. > > Providing wrong information without any warning either in --help, > manpage or in stdout is really the worst solution. There is no other side. The tool still work as intended regardless of the X server release, the information it provides is still exactly the same, and as correct as it used to be —in the sense that it matches exactly what the server claims. Users using it for a different purpose fall in the category of this relevant XKCD https://xkcd.com/1172/ Again, your issue isn't what xdpyinfo reports, but what the _server_ reports, and you're trying to fix it in the wrong place. >> > Really what is the purpose of reporting bogus values? >> >> As mentioned, the purpose of xdpyinfo is to report what the core >> protocol reports (modulo use of the -ext flag and related ones). > > The main problem is that this is not documented, nor written anywhere. If you feel that the man page and usage help text should better clarify that all shown values are what the X core protocol reports, modulo -ext option usage, that can be fixed. > And output of xdpyinfo does not looks like core information for > end-users. > > What end user reads? He sees resolution (which for with the most common > variant for one monitor) matches what he has configured and the he sees > DPI which does not match his monitor. So it is fully bogus for him. And as above, xdpyinfo is not where this should be fixed. >> So it is important that xdpyinfo keeps reporting what is reporting >> because (1) it's its purpose and (2) it's the only way to get what >> legacy (non-RANDR-aware) clients get. > > Ok, it makes sense to retrieve this information, but for sure it should > not be used by new applications, scripts and also users to retrieve DPI. > > But main problem is that xdpyinfo does not look like for end-users that > it reports "legacy" values which end-users should not read for xrandr > 1.2+ display. And that's why the solution to this is to put support for the RANDR extension in xdpyinfo the correct way (i.e. accessible with -ext RANDR), and teach users and scripts to rely on that information as appropriate. >> Now one could argue that in the case of single output X11 could >> automatically set the DPI to the one of the only connected output >> (something I actually agree with), but that's (a) a separate issue and >> (b) not without its downsides (e.g. should it automatically change >> whenever the output changes? what should be done when a new output >> gets connected? what should be done when an output gets disconnected >> and we're left with one output again? etc). > > Those are separate issues, which are really out-of-scope of this > discussion. Personally I like idea that DisplayWidthMM() and > DisplayHeightMM() are calculated to 96 DPI as 96 DPI is sane default for > legacy applications. And special case for one monitor setup is bad > because it would change behavior of applications when more then one > monitor is connected. But that's the core of the issue: xdpyinfo reporting the core value when there are two monitors and the monitor value when there is a single one would be no less inconsistent. The only consistent solution is for xdpyinfo to keep working as designed, provide the RANDR data via -ext RANDR, consistently with the rest, and teach users and script to use that information when possible. Changes to what the core protocol should report by default remain a separate matter, which may be worth discussing, but which remains independent from the scope of this patch. -- Giuseppe "Oblomov" Bilotta ___ 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: [PATCH app/xdpyinfo v2] Use XRANDR 1.2 extension for reporting dimensions and resolution per output
On Sun, Apr 8, 2018 at 4:33 PM, Pali Rohár wrote: > The main problem is that majority of users use xdpyinfo for getting DPI > of their monitors. And in the case of multiple monitors, they'll have to get used to using `xdpyinfo -ext RANDR`, provided support for that information is offered this way. I think that's a good compromise between backwards compatibility and providing the correct information. > And xdpyinfo reports totally bogus values. The values reported by xdpyinfo aren't bogus, they are what the core protocol is providing. > There are plenty of bugs and lot of reports about this problem. Because people are using the wrong tool. > Really what is the purpose of reporting bogus values? As mentioned, the purpose of xdpyinfo is to report what the core protocol reports (modulo use of the -ext flag and related ones). Now why does core report bogus values by default? The root of the issue is that in the case of multiple monitors with potentially inconsistent DPI values, the core protocol value is ambiguous at best. It also has the downside that its value is only communicated at connection time, so it doesn't dynamically change even when the circumstances change (e.g. resolution change, move to a different output with a different DPI, etc). Clients need to be aware of the possibilities that different outputs may have different DPI values, and that the values can change, and that requires RANDR support and listening to the appropriate change notification masks. So it is important that xdpyinfo keeps reporting what is reporting because (1) it's its purpose and (2) it's the only way to get what legacy (non-RANDR-aware) clients get. Now one could argue that in the case of single output X11 could automatically set the DPI to the one of the only connected output (something I actually agree with), but that's (a) a separate issue and (b) not without its downsides (e.g. should it automatically change whenever the output changes? what should be done when a new output gets connected? what should be done when an output gets disconnected and we're left with one output again? etc). -- Giuseppe "Oblomov" Bilotta ___ 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: [PATCH app/xdpyinfo v2] Use XRANDR 1.2 extension for reporting dimensions and resolution per output
On Wed, Apr 4, 2018 at 5:12 PM, Adam Jackson wrote: > On Tue, 2018-04-03 at 22:15 +0200, Pali Rohár wrote: >> Gently reminder of this patch. Can you comment/review it? > > Nack. The whole point of (that part of) xdpyinfo is to show you what > was sent in the initial connection block. xrandr already exists, and > code exists that depends on xdpyinfo's output. Would it make sense to add the output from RANDR via an explicit `-ext RANDR` query similar to what is already done for XINERAMA, XInputExtension, etc? -- Giuseppe "Oblomov" Bilotta ___ 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: [PATCH app/xdpyinfo v2] Use XRANDR 1.2 extension for reporting dimensions and resolution per output
Hello,
I took the liberty of moving the last paragraph of your email to the
top because the reply I'm giving to that part covers both.
On Wed, Apr 4, 2018 at 11:26 AM, Pali Rohár wrote:
>> >> -printf (" dimensions:%dx%d pixels (%dx%d millimeters)\n",
>> >> - XDisplayWidth (dpy, scr), XDisplayHeight (dpy, scr),
>> >> - XDisplayWidthMM(dpy, scr), XDisplayHeightMM (dpy, scr));
>> >> -printf (" resolution:%dx%d dots per inch\n",
>> >> - (int) (xres + 0.5), (int) (yres + 0.5));
>>
>> I would unconditionally show the core output, regardless of RANDR
>> state. Even if it's fictitious when RANDR is enabled,
>> it can still be useful to spot inconsistencies. It also ensures that
>> the xdpyinfo output is "less" broken by this patch (search for
>> xdpyinfo grep resolution to get an idea of how used this is as a debug tool).
>
> XRANDR code below provides that 'grep resolution' support correctly and
> in the same format. It is there for all those scripts which expects
> resolution and dimensions to be correct.
But that's a different piece of information. You mention:
> This patch is just to fix long standing bug, that scripts which parse
> xdpyinfo output and users who looking at it too just get wrong
> information about dimensions and DPI.
For users, having both pieces of information would be better than
having just the
RANDR one, especially for debugging, as that's exactly what the server
is providing
via its core protocol, and what legacy (non-RANDR-aware) clients will
get and use.
For scripts, the situation is a bit hairier, but I wonder how such a
script would work on a
server with multiple active outputs, where you patch introduces
multiple “resolution”
lines anyway.
If you think it's important for the primary RANDR output information
to be first,
maybe you can move the core information to _after_ the RANDR information,
but I still think it's important enough that it should stick around.
(And of course it would be better to fix the scripts themselves, but I
assume not all of them are
open source.)
>> >> +
>> >> +#ifdef XRANDR
>> >> +if (XRRQueryExtension (dpy, &event_base, &error_base) &&
>> >> +XRRQueryVersion (dpy, &major, &minor) &&
>> >> +(major > 1 || (major == 1 && minor >= 2)) &&
>> >> +(res = XRRGetScreenResources (dpy, RootWindow (dpy, scr
>> >> +{
>>
>> I'm pondering whether it would be a good idea to print the RANDR
>> version here, something like:
>> printf(" RANDR (%d.%d) outputs:\n", major, minor);
>> and then nesting the per-output data even more.
>
> I as a user, would expect to find XRANDR version in "xrandr" utility
> output, not in xdpyinfo output.
>
> But if you really think that it would make sense to have it also in
> xdpyinfo, it can be included somewhere...
I'm not sure if it'd be useful or not, really. We could do without.
(I do show it in my xdpi
Re: [PATCH app/xdpyinfo v2] Use XRANDR 1.2 extension for reporting dimensions and resolution per output
Hello Pali,
I like the idea of this patch, wasn't aware of its existence, thanks
for pinging me about it. A few comments below:
On Tue, Apr 3, 2018 at 10:15 PM, Pali Rohár wrote:
>> @@ -455,27 +462,75 @@ print_screen_info(Display *dpy, int scr)
>> double xres, yres;
>> int ndepths = 0, *depths = NULL;
>> unsigned int width, height;
>> -
>> -/*
>> - * there are 2.54 centimeters to an inch; so there are 25.4 millimeters.
>> - *
>> - * dpi = N pixels / (M millimeters / (25.4 millimeters / 1 inch))
>> - * = N pixels / (M inch / 25.4)
>> - * = N * 25.4 pixels / M inch
>> - */
You may want to keep this comment here, rather than in the else block below,
since the formula applies to any conversion, regardless if it's core
or per-output DPI.
>> -xres = double) DisplayWidth(dpy,scr)) * 25.4) /
>> - ((double) DisplayWidthMM(dpy,scr)));
>> -yres = double) DisplayHeight(dpy,scr)) * 25.4) /
>> - ((double) DisplayHeightMM(dpy,scr)));
>> +#ifdef XRANDR
>> +int event_base, error_base;
>> +int major, minor;
>> +XRRScreenResources *res = NULL;
>> +XRROutputInfo *output;
>> +XRRCrtcInfo *crtc;
>> +#endif
>>
>> printf ("\n");
>> printf ("screen #%d:\n", scr);
>> -printf (" dimensions:%dx%d pixels (%dx%d millimeters)\n",
>> - XDisplayWidth (dpy, scr), XDisplayHeight (dpy, scr),
>> - XDisplayWidthMM(dpy, scr), XDisplayHeightMM (dpy, scr));
>> -printf (" resolution:%dx%d dots per inch\n",
>> - (int) (xres + 0.5), (int) (yres + 0.5));
I would unconditionally show the core output, regardless of RANDR
state. Even if it's fictitious when RANDR is enabled,
it can still be useful to spot inconsistencies. It also ensures that
the xdpyinfo output is "less" broken by this patch (search for
xdpyinfo grep resolution to get an idea of how used this is as a debug tool).
>> +
>> +#ifdef XRANDR
>> +if (XRRQueryExtension (dpy, &event_base, &error_base) &&
>> +XRRQueryVersion (dpy, &major, &minor) &&
>> +(major > 1 || (major == 1 && minor >= 2)) &&
>> +(res = XRRGetScreenResources (dpy, RootWindow (dpy, scr
>> +{
I'm pondering whether it would be a good idea to print the RANDR
version here, something like:
printf(" RANDR (%d.%d) outputs:\n", major, minor);
and then nesting the per-output data even more.
>> +for (i = 0; i < res->noutput; ++i) {
>> +output = XRRGetOutputInfo (dpy, res, res->outputs[i]);
>> +if (!output || !output->crtc || output->connection !=
>> RR_Connected)
>> +continue;
>> +
>> +crtc = XRRGetCrtcInfo (dpy, res, output->crtc);
>> +if (!crtc) {
>> +XRRFreeOutputInfo (output);
>> +continue;
>> +}
>> +
>> +printf (" output: %s\n", output->name);
>> +printf ("dimensions:%ux%u pixels (%lux%lu
>> millimeters)\n",
>> +crtc->width, crtc->height, output->mm_width,
>> output->mm_height);
>> +
>> +if (output->mm_width && output->mm_height) {
>> +xres = double) crtc->width) * 25.4) / ((double)
>> output->mm_width));
>> +yres = double) crtc->height) * 25.4) / ((double)
>> output->mm_height));
>> +} else {
>> +xres = 0;
>> +yres = 0;
>> +}
>> +printf ("resolution:%dx%d dots per inch\n",
>> +(int) (xres + 0.5), (int) (yres + 0.5));
This doesn't work correctly when the display is rotated, since the
width/height in pixel will follow the orientation,
but the physical sizes won't. You should probably take that into
account, and possibly show the output orientation (e.g. in the
dimensions line, or in the name line if you do add the "RANDR
outputs" header).
Also (please don't hate me), for RANDR versions 1.5 or higher we
should include RANDR monitors too (possibly in place of individual
outputs, I'm not sure about this actually, it depends on how detailed
we want to be; I would go with both, but then again I'm an information
junkie).
Cheers,
--
Giuseppe "Oblomov" Bilotta
___
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: [PATCH v3 app/xrandr] Document that --dpi and --fbmm options set DPI of whole X screen
Hello, On Fri, Mar 23, 2018 at 4:53 PM, Pali Rohár wrote: > On Monday 12 March 2018 09:19:57 Giuseppe Bilotta wrote: >> On Sat, Mar 10, 2018 at 4:23 PM, Pali Rohár wrote: >> > Explicitly document and make it clear that those options do not change >> > DPI of some monitor output. Also state that these options have no useful >> > meaning for multi-monitor configuration. >> > >> > Signed-off-by: Pali Rohár >> >> FWIW, >> >> Reviewed-by: Giuseppe Bilotta > > Ok, can you merge this patch? Pushed. I'm still new at this, hopefully I didn't mess anything up ;-) Cheers, -- Giuseppe "Oblomov" Bilotta ___ 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: [PATCH v3 app/xrandr] Document that --dpi and --fbmm options set DPI of whole X screen
On Sat, Mar 10, 2018 at 4:23 PM, Pali Rohár wrote: > Explicitly document and make it clear that those options do not change > DPI of some monitor output. Also state that these options have no useful > meaning for multi-monitor configuration. > > Signed-off-by: Pali Rohár FWIW, Reviewed-by: Giuseppe Bilotta > --- > man/xrandr.man | 19 +++ > 1 file changed, 15 insertions(+), 4 deletions(-) > > diff --git a/man/xrandr.man b/man/xrandr.man > index aa82724..1291bad 100644 > --- a/man/xrandr.man > +++ b/man/xrandr.man > @@ -257,14 +257,25 @@ fit within this size. When this option is not provided, > xrandr computes the > smallest screen size that will hold the set of configured outputs; this > option provides a way to override that behaviour. > .IP "\-\-fbmm \fIwidth\fPx\fIheight\fP" > -Sets the reported values for the physical size of the screen. Normally, > +Sets the value reported as physical size of the X screen as a whole > +(union of all configured monitors). In configurations with multiple > +monitors with different DPIs, the value has no physical meaning, but > +it may be used by some legacy clients which do not support RandR > +version 1.2 to compute a reference font scaling. Normally, > xrandr resets the reported physical size values to keep the DPI constant. > -This overrides that computation. > +This overrides that computation. Default DPI value is 96. > .IP "\-\-dpi \fIdpi\fP" > .IP "\-\-dpi \fIfrom-output\fP" > -This also sets the reported physical size values of the screen, it uses > either > +This also sets the value reported as physical size of the X screen as a whole > +(union of all configured monitors). In configurations with multiple > +monitors with different DPIs, the value has no physical meaning, but > +it may be used by some legacy clients which do not support RandR > +version 1.2 to compute a reference font scaling. This option uses either > the specified DPI value, or the DPI of the given output, to compute an > appropriate > -physical size using whatever pixel size will be set. > +physical size using whatever pixel size will be set. Typical values are > +the default (96 DPI), the DPI of the only monitor in single-monitor > +configurations, or the DPI of the primary monitor in multi-monitor > +configurations. > .IP "\-\-newmode \fIname\fP \fImode\fP" > New modelines can be added to the server and then associated with outputs. > This option does the former. The \fImode\fP is specified using the ModeLine > -- > 2.11.0 > -- Giuseppe "Oblomov" Bilotta ___ 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: [PATCH xrandr v5 0/6] xrandr: improve option parsing and documentation
On Fri, Mar 2, 2018 at 1:58 AM, Keith Packard wrote: > Giuseppe Bilotta writes: > >> Giuseppe Bilotta (6): >> xrandr: allow a single value for --scale >> xrandr: stricter --scale argument parsing >> xrandr.man: grammar tuning >> xrandr: allow single value for --gamma >> xrandr.man: document the monitor manipulation options >> xrandr: gamma and scaling factors must be positive >> > > For the series: > > Reviewed-by: Keith Packard > > If you have a freedesktop account, please go ahead and amend your > patches with both of the reviewed annotations and push the result. If > not, either Alex or I can do that. Thanks both for the review. I do have an account (reactivated it recently). I'll give the amend and push a try. -- Giuseppe "Oblomov" Bilotta ___ 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
[PATCH xorgproto] Spelling and grammar fixes
Signed-off-by: Giuseppe Bilotta --- compositeproto.txt | 6 +++--- dri2proto.txt | 10 +- presentproto.txt | 2 +- randrproto.txt | 8 renderproto.txt| 2 +- xv-protocol-v2.txt | 2 +- 6 files changed, 15 insertions(+), 15 deletions(-) diff --git a/compositeproto.txt b/compositeproto.txt index c1d099c..010e6aa 100644 --- a/compositeproto.txt +++ b/compositeproto.txt @@ -35,7 +35,7 @@ both early prototypes and the final design include: a prototype of the coordinate transformation mechanism. + Ryan Lortie for helping figure out reasonable parent clipping - semantics in the presense of manual redirected children. + semantics in the presence of manual redirected children. 3. Architecture @@ -86,7 +86,7 @@ the contents and to create a new name for the newly allocated pixmap. In automatic update mode, the X server is itself responsible for presenting the child window contents within the parent. It seems reasonable, then, for rendering to the parent window to be clipped so as not to interfere with any -child window content. In an environment with a mixure of manual and +child window content. In an environment with a mixture of manual and automatic updating windows, rendering to the parent in the area nominally occupied by a manual update window should be able to affect parent pixel values in those areas, but such rendering should be clipped to automatic @@ -135,7 +135,7 @@ should be defined by the clients themselves. 3.3 Clipping semantics redefined Version 0.4 of the protocol changes the semantics of clipping in the -presense of manual redirect children. In version 0.3, a parent was always +presence of manual redirect children. In version 0.3, a parent was always clipped to child windows, independent of the kind of redirection going on. With version 0.4, the parent is no longer clipped to child windows which are manually redirected. This means the parent can draw in the child region without using diff --git a/dri2proto.txt b/dri2proto.txt index d81b55c..f896777 100644 --- a/dri2proto.txt +++ b/dri2proto.txt @@ -9,7 +9,7 @@ 1. Introduction -The DRI2 extension is designed to associate and access auxillary +The DRI2 extension is designed to associate and access auxiliary rendering buffers with an X drawable. DRI2 is a essentially a helper extension to support implementation of @@ -49,7 +49,7 @@ Stolen from OpenGL FBOs, I guess. 2.2. Kernel rendering manager -This specification assumes a rendering architechture, where an +This specification assumes a rendering architecture, where an underlying kernel rendering manager that can provide 32 bit integer handles to video memory buffers. These handles can be passed between processes, which, through a direct rendering driver, submit rendering @@ -57,7 +57,7 @@ to the kernel rendering manager, targeting and/or sourcing from these buffers. This extension provides a means to communicate about such buffers as associated with an X drawable. -The details of how the a direct rendering driver use the buffer names +The details of how the direct rendering driver use the buffer names and submit the rendering requests is outside the scope of this specification. However, Appendix B does discuss implementation of this specification on the Graphics Execution Manager (GEM). @@ -102,7 +102,7 @@ use DRI2CopyRegion to copy contents back and forth between the fake front buffer and the real front buffer. When X and direct rendering to a front buffer is interleaved, it is the responsibility of the application to synchronize access using glXWaitGL and glXWaitX. A -DRI2 implementation of direct rendering GLX, should use these enty +DRI2 implementation of direct rendering GLX, should use these entry points to copy contents back and forth to as necessary to ensure consistent rendering. @@ -419,7 +419,7 @@ The name of this extension is "DRI2". Blocks the client until the swap buffer count reaches target_sbc. If the swap buffer count is already greater than or equal to target_sbc - when the request is recieved, this request will return immediately. + when the request is received, this request will return immediately. If target_sbc is 0, this request will block the client until all previous DRI2SwapBuffers requests have completed. diff --git a/presentproto.txt b/presentproto.txt index fdaf658..a29db84 100644 --- a/presentproto.txt +++ b/presentproto.txt @@ -318,7 +318,7 @@ The name of this extension is "Present" PresentCapabilityFence means that the target device can take advantage of SyncFences in the Present operations to improve GPU throughput. The driver must operate correctly in the - absense of fences, but may have reduced performance. Using + absence of fences, but may have reduced performance. Using fences for drivers not advertising this capability sh
[PATCH xrandr v5 2/6] xrandr: stricter --scale argument parsing
We used to accept something like --scale 2x3junk as a valid input
(scaling x by 2 and y by 3), even though this isn't really a valid
scaling factor.
Fix by making sure there is nothing after the parsed number(s).
Signed-off-by: Giuseppe Bilotta
---
xrandr.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/xrandr.c b/xrandr.c
index 1085a95..6a38cf2 100644
--- a/xrandr.c
+++ b/xrandr.c
@@ -3014,11 +3014,12 @@ main (int argc, char **argv)
if (!strcmp ("--scale", argv[i]))
{
double sx, sy;
+ char junk;
if (!config_output) argerr ("%s must be used after --output\n",
argv[i]);
if (++i >= argc) argerr ("%s requires an argument\n", argv[i-1]);
- if (sscanf (argv[i], "%lfx%lf", &sx, &sy) != 2)
+ if (sscanf (argv[i], "%lfx%lf%c", &sx, &sy, &junk) != 2)
{
- if (sscanf (argv[i], "%lf", &sx) != 1)
+ if (sscanf (argv[i], "%lf%c", &sx, &junk) != 1)
argerr ("failed to parse '%s' as a scaling factor\n",
argv[i]);
sy = sx;
}
--
2.14.1.439.g647b9b4702
___
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
[PATCH xrandr v5 3/6] xrandr.man: grammar tuning
Rephrase the --scale option paragraph to improve English and be more consistent in choice of plurals and tense. Also ensure that each sentence starts on a new line in the roff source. Signed-off-by: Giuseppe Bilotta --- man/xrandr.man | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/man/xrandr.man b/man/xrandr.man index e59abbe..cfbfb8f 100644 --- a/man/xrandr.man +++ b/man/xrandr.man @@ -208,11 +208,12 @@ Chooses the scaling filter method to be applied when the screen is scaled or transformed. Can be either 'bilinear' or 'nearest'. .IP "\-\-scale \fIx\fP[x\fIy\fP]" -Changes the dimensions of the output picture. If the \fIy\fP value is omitted, -the \fIx\fP value will be used for both dimensions. Values superior to 1 will lead to -a compressed screen (screen dimension bigger than the dimension of the output -mode), and values below 1 leads to a zoom in on the output. This option is -actually a shortcut version of the \fI\-\-transform\fP option. +Changes the dimensions of the output picture. +If the \fIy\fP value is omitted, the \fIx\fP value will be used for both dimensions. +Values larger than 1 lead to a compressed screen (screen dimension bigger +than the dimension of the output mode), and values less than 1 lead to +a zoom in on the output. +This option is actually a shortcut version of the \fI\-\-transform\fP option. .IP "\-\-scale-from \fIw\fPx\fIh\fP" Specifies the size in pixels of the area of the framebuffer to be displayed on this output. -- 2.14.1.439.g647b9b4702 ___ 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
[PATCH xrandr v5 6/6] xrandr: gamma and scaling factors must be positive
Signed-off-by: Giuseppe Bilotta
---
xrandr.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/xrandr.c b/xrandr.c
index f6c425f..7f1e867 100644
--- a/xrandr.c
+++ b/xrandr.c
@@ -2979,6 +2979,9 @@ main (int argc, char **argv)
argerr ("%s: invalid argument '%s'\n", argv[i-1], argv[i]);
config_output->gamma.green = config_output->gamma.blue =
config_output->gamma.red;
}
+ if (config_output->gamma.red <= 0.0 || config_output->gamma.green
<= 0.0 ||
+ config_output->gamma.blue <= 0.0)
+ argerr ("gamma correction factors must be positive\n");
config_output->changes |= changes_gamma;
setit_1_2 = True;
continue;
@@ -3030,6 +3033,8 @@ main (int argc, char **argv)
argerr ("failed to parse '%s' as a scaling factor\n",
argv[i]);
sy = sx;
}
+ if (sx <= 0.0 || sy <= 0.0)
+ argerr ("scaling factors must be positive\n");
init_transform (&config_output->transform);
config_output->transform.transform.matrix[0][0] = XDoubleToFixed
(sx);
config_output->transform.transform.matrix[1][1] = XDoubleToFixed
(sy);
--
2.14.1.439.g647b9b4702
___
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
[PATCH xrandr v5 4/6] xrandr: allow single value for --gamma
Similarly to --scale, accept a single value to be used for all three
components, and refuse values with extra junk after the acceptable
values.
Signed-off-by: Giuseppe Bilotta
---
man/xrandr.man | 9 ++---
xrandr.c | 15 +++
2 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/man/xrandr.man b/man/xrandr.man
index cfbfb8f..9f976ad 100644
--- a/man/xrandr.man
+++ b/man/xrandr.man
@@ -63,7 +63,7 @@ xrandr \- primitive command line interface to RandR extension
[\-\-set \fIproperty\fP \fIvalue\fP]
[\-\-off]
[\-\-crtc \fIcrtc\fP]
-[\-\-gamma \fIred\fP:\fIgreen\fP:\fIblue\fP]
+[\-\-gamma \fIred\fP[:\fIgreen\fP:\fIblue\fP]]
[\-\-brightness \fIbrightness\fP]
[\-o \fIorientation\fP]
[\-s \fIsize\fP]
@@ -303,9 +303,12 @@ Uses the specified crtc (either as an index in the list of
CRTCs or XID).
In normal usage, this option is not required as xrandr tries to make
sensible choices about which crtc to use with each output. When that fails
for some reason, this option can override the normal selection.
-.IP "\-\-gamma \fIred\fP:\fIgreen\fP:\fIblue\fP"
+.IP "\-\-gamma \fIred\fP[:\fIgreen\fP:\fIblue\fP]"
Set the specified floating point values as gamma correction on the crtc
-currently attached to this output. Note that you cannot get two different
values
+currently attached to this output.
+If green and blue are not specified, the red value will be used
+for all three components.
+Note that you cannot get two different values
for cloned outputs (i.e.: which share the same crtc) and that switching an
output to another crtc doesn't change
the crtc gamma corrections at all.
.IP "\-\-brightness \fIbrightness\fP"
diff --git a/xrandr.c b/xrandr.c
index 6a38cf2..f6c425f 100644
--- a/xrandr.c
+++ b/xrandr.c
@@ -144,7 +144,7 @@ usage(void)
" --off\n"
" --crtc \n"
" --panning
x[++[/x++[]]]\n"
- " --gamma ::\n"
+ " --gamma [::]\n"
" --brightness \n"
" --primary\n"
" --noprimary\n"
@@ -2967,11 +2967,18 @@ main (int argc, char **argv)
continue;
}
if (!strcmp ("--gamma", argv[i])) {
+ char junk;
if (!config_output) argerr ("%s must be used after --output\n",
argv[i]);
if (++i >= argc) argerr ("%s requires an argument\n", argv[i-1]);
- if (sscanf(argv[i], "%f:%f:%f", &config_output->gamma.red,
- &config_output->gamma.green, &config_output->gamma.blue) !=
3)
- argerr ("%s: invalid argument '%s'\n", argv[i-1], argv[i]);
+ if (sscanf(argv[i], "%f:%f:%f%c", &config_output->gamma.red,
+ &config_output->gamma.green, &config_output->gamma.blue,
&junk) != 3)
+ {
+ /* check if it's a single floating-point value,
+* to be applied to all components */
+ if (sscanf(argv[i], "%f%c", &config_output->gamma.red, &junk)
!= 1)
+ argerr ("%s: invalid argument '%s'\n", argv[i-1], argv[i]);
+ config_output->gamma.green = config_output->gamma.blue =
config_output->gamma.red;
+ }
config_output->changes |= changes_gamma;
setit_1_2 = True;
continue;
--
2.14.1.439.g647b9b4702
___
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
[PATCH xrandr v5 0/6] xrandr: improve option parsing and documentation
Miscellaneous patches to improve option parsing and documentation for xrandr. Allow single values to be given to --scale and --gamma, rejecting the option if valid values are followed by extra junk (e.g. 2x3a isn't accepted as a valid value for --scale), or if they are not positive. Minor improvements to the documentation are also introduced, the largest of which is the documentation of the xrandr monitor options. v2: rebased on current head. v3: fix code indentation, add grammar fix patch v4: single value accepted for --gamma too, monitor options documented v5: additional patch to check for positive values The patchset is also available from: git://git.oblomov.eu/xorg/xrandr parse-doc-fixes up to c9755465412cbcf533d3c512397773949a26e55f. Giuseppe Bilotta (6): xrandr: allow a single value for --scale xrandr: stricter --scale argument parsing xrandr.man: grammar tuning xrandr: allow single value for --gamma xrandr.man: document the monitor manipulation options xrandr: gamma and scaling factors must be positive man/xrandr.man | 46 +- xrandr.c | 31 --- 2 files changed, 61 insertions(+), 16 deletions(-) -- 2.14.1.439.g647b9b4702 ___ 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
[PATCH xrandr v5 5/6] xrandr.man: document the monitor manipulation options
Signed-off-by: Giuseppe Bilotta
---
man/xrandr.man | 23 +++
1 file changed, 23 insertions(+)
diff --git a/man/xrandr.man b/man/xrandr.man
index 9f976ad..aa82724 100644
--- a/man/xrandr.man
+++ b/man/xrandr.man
@@ -72,6 +72,10 @@ xrandr \- primitive command line interface to RandR extension
[\-\-listproviders]
[\-\-setprovideroutputsource \fIprovider\fP \fIsource\fP]
[\-\-setprovideroffloadsink \fIprovider\fP \fIsink\fP]
+[\-\-listmonitors]
+[\-\-listactivemonitors]
+[\-\-setmonitor \fIname\fP \fIgeometry\fP \fIoutputs\fP]
+[\-\-delmonitor \fIname\fP]
.SH DESCRIPTION
.I Xrandr
is used to set the size, orientation and/or reflection of the outputs for a
@@ -118,6 +122,25 @@ is available.
Forces the usage of the RandR version 1.2 protocol, even if the display does
not report it as supported or a higher version is available.
.PP
+.SH "RandR version 1.5 options"
+.PP
+Options for RandR 1.5 are used as a superset of the options for RandR 1.4.
+.PP
+.IP \-\-listmonitors
+Report information about all defined monitors.
+.IP \-\-listactivemonitors
+Report information about currently active monitors.
+.IP "\-\-setmonitor \fIname\fP \fIgeometry\fP \fIoutputs\fP"}
{none|\fIoutput\fP,\fIoutput\fP,...}\n"
+Define a new monitor with the given geometry and associated to the given
outputs.
+The output list is either the keyword \fBnone\fP or a comma-separated list of
outputs.
+The geometry is either the keyword \fBauto\fP, in which case the monitor
+will automatically track the geometry of the associated outputs, or a manual
specification
+in the form
+\fIw\fP/\fImmw\fPx\fIh\fP/\fImmh\fP+\fIx\fP+\fIy\fP
+where w, h, x, y are in pixels and mmw, mmh are the physical dimensions of the
monitor.
+.IP "\-\-delmonitor \fIname\fP"
+Delete the given user-defined monitor.
+.PP
.SH "RandR version 1.4 options"
.PP
Options for RandR 1.4 are used as a superset of the options for RandR 1.3.
--
2.14.1.439.g647b9b4702
___
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
[PATCH xrandr v5 1/6] xrandr: allow a single value for --scale
This allows using e.g. --scale 0.5 as a shorthand for --scale 0.5x0.5
Signed-off-by: Giuseppe Bilotta
---
man/xrandr.man | 7 ---
xrandr.c | 8 ++--
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/man/xrandr.man b/man/xrandr.man
index 65ccc2a..e59abbe 100644
--- a/man/xrandr.man
+++ b/man/xrandr.man
@@ -34,7 +34,7 @@ xrandr \- primitive command line interface to RandR extension
[\-\-current]
[\-\-noprimary]
[\-\-panning
\fIwidth\fPx\fIheight\fP[+\fIx\fP+\fIy\fP[/\fItrack_width\fPx\fItrack_height\fP+\fItrack_x\fP+\fItrack_y\fP[/\fIborder_left\fP/\fIborder_top\fP/\fIborder_right\fP/\fIborder_bottom\fP
-[\-\-scale \fIx\fPx\fIy\fP]
+[\-\-scale \fIx\fP[x\fIy\fP]]
[\-\-scale-from \fIw\fPx\fIh\fP]
[\-\-transform
\fIa\fP,\fIb\fP,\fIc\fP,\fId\fP,\fIe\fP,\fIf\fP,\fIg\fP,\fIh\fP,\fIi\fP]
[\-\-primary]
@@ -207,8 +207,9 @@ values are used (a unit matrix without filter).
Chooses the scaling filter method to be applied when the screen is scaled or
transformed.
Can be either 'bilinear' or 'nearest'.
-.IP "\-\-scale \fIx\fPx\fIy\fP"
-Changes the dimensions of the output picture. Values superior to 1 will lead to
+.IP "\-\-scale \fIx\fP[x\fIy\fP]"
+Changes the dimensions of the output picture. If the \fIy\fP value is omitted,
+the \fIx\fP value will be used for both dimensions. Values superior to 1 will
lead to
a compressed screen (screen dimension bigger than the dimension of the output
mode), and values below 1 leads to a zoom in on the output. This option is
actually a shortcut version of the \fI\-\-transform\fP option.
diff --git a/xrandr.c b/xrandr.c
index 2d4cb72..1085a95 100644
--- a/xrandr.c
+++ b/xrandr.c
@@ -137,7 +137,7 @@ usage(void)
" --below \n"
" --same-as \n"
" --set \n"
- " --scale x\n"
+ " --scale [x]\n"
" --scale-from x\n"
" --transform \n"
" --filter nearest,bilinear\n"
@@ -3017,7 +3017,11 @@ main (int argc, char **argv)
if (!config_output) argerr ("%s must be used after --output\n",
argv[i]);
if (++i >= argc) argerr ("%s requires an argument\n", argv[i-1]);
if (sscanf (argv[i], "%lfx%lf", &sx, &sy) != 2)
- argerr ("failed to parse '%s' as a scaling factor\n", argv[i]);
+ {
+ if (sscanf (argv[i], "%lf", &sx) != 1)
+ argerr ("failed to parse '%s' as a scaling factor\n",
argv[i]);
+ sy = sx;
+ }
init_transform (&config_output->transform);
config_output->transform.transform.matrix[0][0] = XDoubleToFixed
(sx);
config_output->transform.transform.matrix[1][1] = XDoubleToFixed
(sy);
--
2.14.1.439.g647b9b4702
___
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: Making Composite better for interactive apps
On Tue, Feb 6, 2018 at 11:03 PM, Keith Packard wrote: >> Why would there be a need for the server to send an event to the CM? > > My thinking is that the X server would lock the window system from > changes and then deliver an event to the Compositing Manager. Otherwise, > the CM would have to wake up and do a round trip to grab the server and > flush any pending events. [snip] >> Sorry, I meant for the Compositing Manager to send a specific message. >> As in, instead of doing an actual grab/ungrab, have something like a >> PreparePresentNotify that the Compositing Manager sends to the server, >> with the information about the AutoList for the (upcoming) >> PresentPixmap and the CRTC to lock down. > > Yeah, the problem is that the Compositing Manager can't send the Auto > List until after it has locked the server down and fetched all of the > pending updates, in case one of those changes invalidates the > assumptions built into the Auto List. Still it would make more sense to have the CM tell the server “I'm going to prepare the next frame, so stop the world” than having the server tel the CM “I stopped the world to give you some time to prepare the next frame”. Maybe it can be achieved with both? As in the CM sending a PreparingNextFrameNotify to the server, the server replying with an OKIStoppedTheWorldNotify, and then the CM can fetch all pending updates and actually prepare the frame? > It still looks like the problem of making Composite reliably generate > correct and complete frames is separate from the goal of automatically > compositing some portion of the frame inside the X server. I agree. > I think I'm pretty much ready to go prototype the Auto List bits and see > how that goes. Looking forward to that. -- Giuseppe "Oblomov" Bilotta ___ 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: [PATCH xrandr v4 2/5] xrandr: stricter --scale argument parsing
On Tue, Feb 6, 2018 at 8:03 PM, Keith Packard wrote: > Giuseppe Bilotta writes: >> I'll add the positive check for both scale and gamma and respin the patch. > > Thanks. Actually, it just occurred to me that a negative scaling factor could be interpreted as a reflection in that direction (i.e. --scale -2x1 could be aliased to --scale 2x1 --reflect x). Or is it not worth it? -- Giuseppe "Oblomov" Bilotta ___ 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: Making Composite better for interactive apps
On Tue, Feb 6, 2018 at 3:39 AM, Keith Packard wrote: > Giuseppe Bilotta writes: >> I'm coming at this from the assumption that a Compositing Manager >> would try to pump out frames as frequently as possible, in order to >> minimize latency, which would lead to changes being disabled more >> often than not. > > I think that's the wrong assumption. Given that you have monitors at a > fixed refresh rate, you want each frame on the monitor to contain the > most recent changes for all windows. That means painting the screen > after all applications have updated for the current frame. Because we > can't really tell when applications are done updating, as some may skip > a frame now and then, what we can do is to delay painting until there's > just barely enough time left before vblank to paint the frame. We've got > lots of information that can be used to help predict when that time > should be. So it's generally true that, as far as compositing is concerned, the time to prepare a frame is low enough that even on higher frequency monitor there should be “plenty” of time between frames? Actually duh it obviously is, since even assuming everything had to be copied over, 1080p at 144Hz is in the order of 1GB/sec, unless I completely jumbled my math, and of course knowing the worst-case bandwidth requirements and latency one can predict the time. Ok, I'm convinced. Just as a curiosity though, are there any plans (or anything special that needs planning) to support things such as adaptive sync? > One option would be to bury heuristics like this into the X server and > have it send an event when it thinks the Compositing Manager should > start painting; probably not ideal, but workable. Or even have the > Compositing Manager tell the X server how much lead time it needs. In > either case, the X server could suspend the other clients and send an > event to the Compositing Manager at that time, unblocking when the > Compositing Manager was finished. I'd say that the idea of the Compositing Manager doing it sounds more in line with the general principles of X. Also arguably nobody knows better what's needed for the generation of a frame than the CM itself, so they may have different heuristics better tuned for their specific modus operandi. Why would there be a need for the server to send an event to the CM? > Sure, it would be great to suspend applications only when they try to > manipulate resources on the target CRTC. We can do that in X, it's just > more work to go through the window system code and stick in checks to > suspend clients in relevant requests. Completely enforceable, in terms > of geometry and rendering requests. I was actually more worried about potential dangers of deadlocks, actually, or something like that. Like, a client sending multiple events, some affecting windows on a blocked CRTC, others affecting windows on a non-blocked CRTC, and there being some kind of implicit assumption somewhere that the events would be processed in order, whereas during lockdown the server might end up serving them in a different order. >> The question of the century is then: how much time will the server >> spend in grabbed state? How much does this affect the server behavior? > > From the users' perspective, there is no effect at all -- you can't see > anything that clients do until the Compositing Manager draws the > screen. And, the server should spend very little time in the grabbed > state; only long enough for the Compositing Manager to draw the > frame. A Direct Rendered application would probably see no impact at > all; if triple buffered, it will have all of the necessary resources to > continue drawing without waiting for the PresentPixmap to finish. While you can't _see_ anything until a screen update, applications may behave differently, since the timings may be different. >> Would it be more lightweight to have a specific message instead? This >> could be used to carry extra information. For example, the AutoList >> for this present may be sent with this message. > > For this to work without changing existing applications, I think the > only thing we can do is stop executing requests from them. Sorry, I meant for the Compositing Manager to send a specific message. As in, instead of doing an actual grab/ungrab, have something like a PreparePresentNotify that the Compositing Manager sends to the server, with the information about the AutoList for the (upcoming) PresentPixmap and the CRTC to lock down. -- Giuseppe "Oblomov" Bilotta ___ 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: [PATCH xorgproto] randr: MONITORINFO has outputs, not crtcs
On Tue, Feb 6, 2018 at 10:03 AM, walter harms wrote: > It would be nice to have an explanation why this change. The change is to align the description of the protocol with what the protocol actually sends (see e.g. line 417 in the same file, or the header and the server source). I would have actually been more verbose in the commit message if I had known why it was wrong in the first place (I assume it's some leftover from during the development of the protocol itself). Shall I respin mentioning this in the commit message? > Am 06.02.2018 02:03, schrieb Giuseppe Bilotta: >> --- >> randrproto.txt | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/randrproto.txt b/randrproto.txt >> index c06bc90..f57301d 100644 >> --- a/randrproto.txt >> +++ b/randrproto.txt >> @@ -2363,14 +2363,14 @@ A.1.1 Common Types added in version 1.5 of the >> protocol >> 4 ATOMname >> 1 BOOLprimary >> 1 BOOLautomatic >> - 2 CARD16 ncrtcs >> + 2 CARD16 noutputs >> 2 INT16 x >> 2 INT16 y >> 2 CARD16 width in pixels >> 2 CARD16 height in pixels >> 4 CARD32 width in millimeters >> 4 CARD32 height in millimeters >> - 4*n CRTCcrtcs >> + 4*n OUTPUT outputs >> └─── >> >> A.2 Protocol Requests > ___ > 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 -- Giuseppe "Oblomov" Bilotta ___ 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: [PATCH xrandr v4 2/5] xrandr: stricter --scale argument parsing
On Tue, Feb 6, 2018 at 3:43 AM, Keith Packard wrote: > No, strtod requires a non-empty sequence of digits. Woah. My whole life is a lie … (I guess it's my fault for never bothering to actually verify this.) > strtod is actually not a terrible function (surprising for libc, I know) You know there's something wrong with a library when an X.org developer questions its general sanity ;-) Joking aside, this does mean that strtod could be a good option when parsing the single value. The check would be more verbose though, so I think I'll stick with sscanf. I'll add the positive check for both scale and gamma and respin the patch. -- Giuseppe "Oblomov" Bilotta ___ 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
[PATCH xorgproto] randr: MONITORINFO has outputs, not crtcs
--- randrproto.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/randrproto.txt b/randrproto.txt index c06bc90..f57301d 100644 --- a/randrproto.txt +++ b/randrproto.txt @@ -2363,14 +2363,14 @@ A.1.1 Common Types added in version 1.5 of the protocol 4 ATOMname 1 BOOLprimary 1 BOOLautomatic - 2 CARD16 ncrtcs + 2 CARD16 noutputs 2 INT16 x 2 INT16 y 2 CARD16 width in pixels 2 CARD16 height in pixels 4 CARD32 width in millimeters 4 CARD32 height in millimeters - 4*n CRTCcrtcs + 4*n OUTPUT outputs └─── A.2 Protocol Requests -- 2.14.1.439.g647b9b4702 ___ 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: [PATCH xrandr v4 2/5] xrandr: stricter --scale argument parsing
On Tue, Feb 6, 2018 at 1:01 AM, Keith Packard wrote:
> Giuseppe Bilotta writes:
>
>> I'm not a big fan of strtod because with it it's impossible to know if
>> a conversion actually happened. xrandr --scale ' ' would actually be
>> accepted (resulting in a scale value of 0), while the scanf catches
>> it.
>
> strtod takes an 'endptr' argument which can be used for precisely this
> purpose,
Not in the sense I mean above. If the string is a sequences of
whitespace characters, strtod would return 0 as value (no conversion),
and set endptr to the end of the string, because it would gobble the
whitespace. This would be indistinguishable from it successfully
parsing a string argument of, say, '0.0'.
> but I think your use of sscanf is easier to read as it does
> both conversions in one call, and lets you pick the two different
> versions easily (--scale 2 and --scale 2x1.5). One could imagine doing
>
> xscale = strtod(string, &endptr);
> if (*endptr) {
> if (endptr == string || *endptr != 'x')
> syntax error;
> string = endptr + 1;
> yscale = strtod(string, &endptr);
> if (endptr == string || *endptr)
> syntax error;
> } else {
> yscale = xscale;
>
> That's a lot more code than two calls to sscanf...
I interpreted Walter's suggestion as using strtod only in if the
sscanf failed to find 2 values, since then we expect a single value.
>> Of course there's also to be said that we could reject a scale factor
>> of 0, regardless of whether it comes from a correct parsing of the
>> string '0.0' or from the parse of an empty string (but of course then
>> we couldn't customize the error message to differentiate between
>> “incorrect parse” and “value out of range”).
>
> Probably a good thing to catch.
True, we should do this regardless of how the values are parsed. Also
ensure that it's not negative.
Hm. Since we have to do it both for scale and gamma, I wonder if it's
overengineering if I try to refactor this parsing of "N or 1 positive
values with separator S" into its own function.
--
Giuseppe "Oblomov" Bilotta
___
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: Making Composite better for interactive apps
On Mon, Feb 5, 2018 at 9:24 PM, Keith Packard wrote: > What we want is for the compositing manager to get a clean snapshot of > the system and to then be able to present that on the screen each > frame. That means disallowing *all* changes for the duration of the > construction of the presented image. This is independent of whether some > windows are composited within the X server or composited by the > Compositing Manager. While I find this conceptually acceptable, I have an uneasy feeling about its practicality. I'm coming at this from the assumption that a Compositing Manager would try to pump out frames as frequently as possible, in order to minimize latency, which would lead to changes being disabled more often than not. This is particularly damning if you consider the case of multiple monitors with different refresh rates (think 144Hz “gaming” monitor and 60Hz “secondary” monitor), which is something I would recommend be considered in the design of this proposal, because this is already a current reality that even Windows 10 has (or at least has had) issues with (interestingly, apparently not WIndows 7). > Here's a proposal for this issue: > > 1) Create a synchronization point within the X server which defines the > start of presentation (for a single screen? globally?). If we want to take the separate refresh rates into account, I think this should be per-window/virtual root. The rationale for this is that a Compositing Manager which supports mixed refresh rates would create one overlay per monitor, and update each at a separate frequency. > 2) Between this point and the receipt of the PresentPixmap for this > frame, freeze all window drawing and geometry changes. A client > which sends a PresentPixmap or any window configuration request > which would affect the ongoing presentation will be blocked. > > 3) Once the presentation is complete, unblock all clients and process > their queued requests. Ideally, the blockade should only involve the windows within the affected area, but I'm not entirely sure this would be enforceable. > One trivial way of implementing this is to have the Compositing Manager > grab the X server at the start of the synchronization point, perform a > round-trip operation to ensure that all pending updates are local and > then run the presentation operation. After sending the PresentPixmap > request, it would ungrab the server. The question of the century is then: how much time will the server spend in grabbed state? How much does this affect the server behavior? Would it be more lightweight to have a specific message instead? This could be used to carry extra information. For example, the AutoList for this present may be sent with this message. > This works for the current Manual compositing mechanism where the > Compositing Manager is the one doing the drawing. So, I think the trick > is simply to figure out how to make sure that the Compositing Manager is > doing the drawing whenever a geometry change occurs. > > To fix windows in the Auto List, is it not sufficient to simply remove > those windows from the Auto List and tell the Compositing manager? The > Compositing Manager would then be responsible for constructing that > region of the screen again Maybe we don't even need to change the AutoList. What we want is to ensure that the Compositing Manager has _processed_ the notification of the geometry change for the windows in the AutoList. This could be achieved for exampe by having the CM send also the geometry of the AutoList windows when asking for the lock, and the server refusing the lock if the geometry is not up to date, or something like that. -- Giuseppe "Oblomov" Bilotta ___ 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: [PATCH xrandr v4 2/5] xrandr: stricter --scale argument parsing
On Mon, Feb 5, 2018 at 10:44 AM, walter harms wrote:
>
> Am 05.02.2018 02:47, schrieb Giuseppe Bilotta:
>> {
>> double sx, sy;
>> + char junk;
>> if (!config_output) argerr ("%s must be used after --output\n",
>> argv[i]);
>> if (++i >= argc) argerr ("%s requires an argument\n", argv[i-1]);
>> - if (sscanf (argv[i], "%lfx%lf", &sx, &sy) != 2)
>> + if (sscanf (argv[i], "%lfx%lf%c", &sx, &sy, &junk) != 2)
>> {
>> - if (sscanf (argv[i], "%lf", &sx) != 1)
>> + if (sscanf (argv[i], "%lf%c", &sx, &junk) != 1)
>> argerr ("failed to parse '%s' as a scaling factor\n",
>> argv[i]);
>> sy = sx;
>> }
>
> can the scanf be converted to strtod ? there you get an endpointer by default.
I'm not a big fan of strtod because with it it's impossible to know if
a conversion actually happened. xrandr --scale ' ' would actually be
accepted (resulting in a scale value of 0), while the scanf catches
it. For the same reason I use two sscanf instead of a single one
(because that wouldn't be able to catch something like xrandr --scale
1j).
Of course there's also to be said that we could reject a scale factor
of 0, regardless of whether it comes from a correct parsing of the
string '0.0' or from the parse of an empty string (but of course then
we couldn't customize the error message to differentiate between
“incorrect parse” and “value out of range”).
--
Giuseppe "Oblomov" Bilotta
___
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: Making Composite better for interactive apps
On Mon, Feb 5, 2018 at 4:27 AM, Keith Packard wrote: > Giuseppe Bilotta writes: > >> I'm not sure if this could be implemented without making the server >> more susceptible to DOS attacks, though (basically the same issue I >> see in the blocking AutoList geometry change notification). > > In that case, the Window Manager can already perform DoS attacks by > simply never mapping the window. Similarly, the Compositing Manager can > DoS the system by never painting anything. Given that one generally > starts a Window Manager/Compositing Manager at the start of the session, > and that only one of either can be running at a time, there shouldn't be > any way for such a DoS to occur. Eh, sometimes I miss the obvious 8-D. So the only difference between the two approaches is that in the current async way the server can cover the latency that would come from waiting for the WM to complete the mapping (or in general other such requests) by processing other events, but this comes at the cost of the complexity inevitably deriving from the asynchronicity itself, both in terms of protocol and in things like trying to guarantee consistency between disparate events affecting the same windows (such as the geometry changes' interaction with the presentation that we discussed so far). I must say I'm a bit conflicted about this. I actually like the mostly asynchronous nature of the X11 protocol (but that might just be a perversion of mine developed over years of HPC). In fact, the thing I like the least about it is that the C language doesn't have something that maps naturally to it (while the C++11 std::future actually do). I do agree however that having some better ways to enforce sequencing in some circumstances would be preferrable. > In any case, we're not likely to change how window management works at > this point; toolkits have dealt with re-directed configuration for over > thirty years at this point. Well, obviously, these would be more along general thoughts about how things could be different for X12 ;-) Or at least design principles that may be kept in mind for future extensions. -- Giuseppe "Oblomov" Bilotta ___ 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
[PATCH xrandr v4 5/5] xrandr.man: document the monitor manipulation options
---
man/xrandr.man | 23 +++
1 file changed, 23 insertions(+)
diff --git a/man/xrandr.man b/man/xrandr.man
index 9f976ad..aa82724 100644
--- a/man/xrandr.man
+++ b/man/xrandr.man
@@ -72,6 +72,10 @@ xrandr \- primitive command line interface to RandR extension
[\-\-listproviders]
[\-\-setprovideroutputsource \fIprovider\fP \fIsource\fP]
[\-\-setprovideroffloadsink \fIprovider\fP \fIsink\fP]
+[\-\-listmonitors]
+[\-\-listactivemonitors]
+[\-\-setmonitor \fIname\fP \fIgeometry\fP \fIoutputs\fP]
+[\-\-delmonitor \fIname\fP]
.SH DESCRIPTION
.I Xrandr
is used to set the size, orientation and/or reflection of the outputs for a
@@ -118,6 +122,25 @@ is available.
Forces the usage of the RandR version 1.2 protocol, even if the display does
not report it as supported or a higher version is available.
.PP
+.SH "RandR version 1.5 options"
+.PP
+Options for RandR 1.5 are used as a superset of the options for RandR 1.4.
+.PP
+.IP \-\-listmonitors
+Report information about all defined monitors.
+.IP \-\-listactivemonitors
+Report information about currently active monitors.
+.IP "\-\-setmonitor \fIname\fP \fIgeometry\fP \fIoutputs\fP"}
{none|\fIoutput\fP,\fIoutput\fP,...}\n"
+Define a new monitor with the given geometry and associated to the given
outputs.
+The output list is either the keyword \fBnone\fP or a comma-separated list of
outputs.
+The geometry is either the keyword \fBauto\fP, in which case the monitor
+will automatically track the geometry of the associated outputs, or a manual
specification
+in the form
+\fIw\fP/\fImmw\fPx\fIh\fP/\fImmh\fP+\fIx\fP+\fIy\fP
+where w, h, x, y are in pixels and mmw, mmh are the physical dimensions of the
monitor.
+.IP "\-\-delmonitor \fIname\fP"
+Delete the given user-defined monitor.
+.PP
.SH "RandR version 1.4 options"
.PP
Options for RandR 1.4 are used as a superset of the options for RandR 1.3.
--
2.14.1.439.g647b9b4702
___
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
[PATCH xrandr v4 4/5] xrandr: allow single value for --gamma
Similarly to --scale, accept a single value to be used for all three
components, and refuse values with extra junk after the acceptable
values.
---
man/xrandr.man | 9 ++---
xrandr.c | 15 +++
2 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/man/xrandr.man b/man/xrandr.man
index cfbfb8f..9f976ad 100644
--- a/man/xrandr.man
+++ b/man/xrandr.man
@@ -63,7 +63,7 @@ xrandr \- primitive command line interface to RandR extension
[\-\-set \fIproperty\fP \fIvalue\fP]
[\-\-off]
[\-\-crtc \fIcrtc\fP]
-[\-\-gamma \fIred\fP:\fIgreen\fP:\fIblue\fP]
+[\-\-gamma \fIred\fP[:\fIgreen\fP:\fIblue\fP]]
[\-\-brightness \fIbrightness\fP]
[\-o \fIorientation\fP]
[\-s \fIsize\fP]
@@ -303,9 +303,12 @@ Uses the specified crtc (either as an index in the list of
CRTCs or XID).
In normal usage, this option is not required as xrandr tries to make
sensible choices about which crtc to use with each output. When that fails
for some reason, this option can override the normal selection.
-.IP "\-\-gamma \fIred\fP:\fIgreen\fP:\fIblue\fP"
+.IP "\-\-gamma \fIred\fP[:\fIgreen\fP:\fIblue\fP]"
Set the specified floating point values as gamma correction on the crtc
-currently attached to this output. Note that you cannot get two different
values
+currently attached to this output.
+If green and blue are not specified, the red value will be used
+for all three components.
+Note that you cannot get two different values
for cloned outputs (i.e.: which share the same crtc) and that switching an
output to another crtc doesn't change
the crtc gamma corrections at all.
.IP "\-\-brightness \fIbrightness\fP"
diff --git a/xrandr.c b/xrandr.c
index 6a38cf2..f6c425f 100644
--- a/xrandr.c
+++ b/xrandr.c
@@ -144,7 +144,7 @@ usage(void)
" --off\n"
" --crtc \n"
" --panning
x[++[/x++[]]]\n"
- " --gamma ::\n"
+ " --gamma [::]\n"
" --brightness \n"
" --primary\n"
" --noprimary\n"
@@ -2967,11 +2967,18 @@ main (int argc, char **argv)
continue;
}
if (!strcmp ("--gamma", argv[i])) {
+ char junk;
if (!config_output) argerr ("%s must be used after --output\n",
argv[i]);
if (++i >= argc) argerr ("%s requires an argument\n", argv[i-1]);
- if (sscanf(argv[i], "%f:%f:%f", &config_output->gamma.red,
- &config_output->gamma.green, &config_output->gamma.blue) !=
3)
- argerr ("%s: invalid argument '%s'\n", argv[i-1], argv[i]);
+ if (sscanf(argv[i], "%f:%f:%f%c", &config_output->gamma.red,
+ &config_output->gamma.green, &config_output->gamma.blue,
&junk) != 3)
+ {
+ /* check if it's a single floating-point value,
+* to be applied to all components */
+ if (sscanf(argv[i], "%f%c", &config_output->gamma.red, &junk)
!= 1)
+ argerr ("%s: invalid argument '%s'\n", argv[i-1], argv[i]);
+ config_output->gamma.green = config_output->gamma.blue =
config_output->gamma.red;
+ }
config_output->changes |= changes_gamma;
setit_1_2 = True;
continue;
--
2.14.1.439.g647b9b4702
___
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
[PATCH xrandr v4 3/5] xrandr.man: grammar tuning
Rephrase the --scale option paragraph to improve English and be more consistent in choice of plurals and tense. Also ensure that each sentence starts on a new line in the roff source. Signed-off-by: Giuseppe Bilotta --- man/xrandr.man | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/man/xrandr.man b/man/xrandr.man index e59abbe..cfbfb8f 100644 --- a/man/xrandr.man +++ b/man/xrandr.man @@ -208,11 +208,12 @@ Chooses the scaling filter method to be applied when the screen is scaled or transformed. Can be either 'bilinear' or 'nearest'. .IP "\-\-scale \fIx\fP[x\fIy\fP]" -Changes the dimensions of the output picture. If the \fIy\fP value is omitted, -the \fIx\fP value will be used for both dimensions. Values superior to 1 will lead to -a compressed screen (screen dimension bigger than the dimension of the output -mode), and values below 1 leads to a zoom in on the output. This option is -actually a shortcut version of the \fI\-\-transform\fP option. +Changes the dimensions of the output picture. +If the \fIy\fP value is omitted, the \fIx\fP value will be used for both dimensions. +Values larger than 1 lead to a compressed screen (screen dimension bigger +than the dimension of the output mode), and values less than 1 lead to +a zoom in on the output. +This option is actually a shortcut version of the \fI\-\-transform\fP option. .IP "\-\-scale-from \fIw\fPx\fIh\fP" Specifies the size in pixels of the area of the framebuffer to be displayed on this output. -- 2.14.1.439.g647b9b4702 ___ 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
[PATCH xrandr v4 0/5] xrandr: improve option parsing and documentation
Misc. patches to improve option parsing and documentation for xrandr. Allow single values to be given to --scale and --gamma, rejecting the option if valid values are followed by extra junk (e.g. 2x3a isn't accepted as a valid value for --scale). Minor improvements to the documentation are also introduced, the largest of which is the documentation of the xrandr monitor options. v2: rebased on current head. v3: fix code indentation, add grammar fix patch v4: single value accepted for --gamma too, monitor options documented. Giuseppe Bilotta (5): xrandr: allow a single value for --scale xrandr: stricter --scale argument parsing xrandr.man: grammar tuning xrandr: allow single value for --gamma xrandr.man: document the monitor manipulation options man/xrandr.man | 46 +- xrandr.c | 26 +++--- 2 files changed, 56 insertions(+), 16 deletions(-) -- 2.14.1.439.g647b9b4702 ___ 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
[PATCH xrandr v4 1/5] xrandr: allow a single value for --scale
This allows using e.g. --scale 0.5 as a shorthand for --scale 0.5x0.5
Signed-off-by: Giuseppe Bilotta
---
man/xrandr.man | 7 ---
xrandr.c | 8 ++--
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/man/xrandr.man b/man/xrandr.man
index 65ccc2a..e59abbe 100644
--- a/man/xrandr.man
+++ b/man/xrandr.man
@@ -34,7 +34,7 @@ xrandr \- primitive command line interface to RandR extension
[\-\-current]
[\-\-noprimary]
[\-\-panning
\fIwidth\fPx\fIheight\fP[+\fIx\fP+\fIy\fP[/\fItrack_width\fPx\fItrack_height\fP+\fItrack_x\fP+\fItrack_y\fP[/\fIborder_left\fP/\fIborder_top\fP/\fIborder_right\fP/\fIborder_bottom\fP
-[\-\-scale \fIx\fPx\fIy\fP]
+[\-\-scale \fIx\fP[x\fIy\fP]]
[\-\-scale-from \fIw\fPx\fIh\fP]
[\-\-transform
\fIa\fP,\fIb\fP,\fIc\fP,\fId\fP,\fIe\fP,\fIf\fP,\fIg\fP,\fIh\fP,\fIi\fP]
[\-\-primary]
@@ -207,8 +207,9 @@ values are used (a unit matrix without filter).
Chooses the scaling filter method to be applied when the screen is scaled or
transformed.
Can be either 'bilinear' or 'nearest'.
-.IP "\-\-scale \fIx\fPx\fIy\fP"
-Changes the dimensions of the output picture. Values superior to 1 will lead to
+.IP "\-\-scale \fIx\fP[x\fIy\fP]"
+Changes the dimensions of the output picture. If the \fIy\fP value is omitted,
+the \fIx\fP value will be used for both dimensions. Values superior to 1 will
lead to
a compressed screen (screen dimension bigger than the dimension of the output
mode), and values below 1 leads to a zoom in on the output. This option is
actually a shortcut version of the \fI\-\-transform\fP option.
diff --git a/xrandr.c b/xrandr.c
index 2d4cb72..1085a95 100644
--- a/xrandr.c
+++ b/xrandr.c
@@ -137,7 +137,7 @@ usage(void)
" --below \n"
" --same-as \n"
" --set \n"
- " --scale x\n"
+ " --scale [x]\n"
" --scale-from x\n"
" --transform \n"
" --filter nearest,bilinear\n"
@@ -3017,7 +3017,11 @@ main (int argc, char **argv)
if (!config_output) argerr ("%s must be used after --output\n",
argv[i]);
if (++i >= argc) argerr ("%s requires an argument\n", argv[i-1]);
if (sscanf (argv[i], "%lfx%lf", &sx, &sy) != 2)
- argerr ("failed to parse '%s' as a scaling factor\n", argv[i]);
+ {
+ if (sscanf (argv[i], "%lf", &sx) != 1)
+ argerr ("failed to parse '%s' as a scaling factor\n",
argv[i]);
+ sy = sx;
+ }
init_transform (&config_output->transform);
config_output->transform.transform.matrix[0][0] = XDoubleToFixed
(sx);
config_output->transform.transform.matrix[1][1] = XDoubleToFixed
(sy);
--
2.14.1.439.g647b9b4702
___
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
[PATCH xrandr v4 2/5] xrandr: stricter --scale argument parsing
We used to accept something like --scale 2x3junk as a valid input
(scaling x by 2 and y by 3), even though this isn't really a valid
scaling factor.
Fix by making sure there is nothing after the parsed number(s).
Signed-off-by: Giuseppe Bilotta
---
xrandr.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/xrandr.c b/xrandr.c
index 1085a95..6a38cf2 100644
--- a/xrandr.c
+++ b/xrandr.c
@@ -3014,11 +3014,12 @@ main (int argc, char **argv)
if (!strcmp ("--scale", argv[i]))
{
double sx, sy;
+ char junk;
if (!config_output) argerr ("%s must be used after --output\n",
argv[i]);
if (++i >= argc) argerr ("%s requires an argument\n", argv[i-1]);
- if (sscanf (argv[i], "%lfx%lf", &sx, &sy) != 2)
+ if (sscanf (argv[i], "%lfx%lf%c", &sx, &sy, &junk) != 2)
{
- if (sscanf (argv[i], "%lf", &sx) != 1)
+ if (sscanf (argv[i], "%lf%c", &sx, &junk) != 1)
argerr ("failed to parse '%s' as a scaling factor\n",
argv[i]);
sy = sx;
}
--
2.14.1.439.g647b9b4702
___
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: Making Composite better for interactive apps
On Mon, Feb 5, 2018 at 2:17 AM, Keith Packard wrote: > Giuseppe Bilotta writes: > >> I'm not sure I follow. > > Imagine if MapWindow blocked until the window was actually mapped by the > Window Manager. I'm not sure if this could be implemented without making the server more susceptible to DOS attacks, though (basically the same issue I see in the blocking AutoList geometry change notification). -- Giuseppe "Oblomov" Bilotta ___ 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: Making Composite better for interactive apps
On Mon, Feb 5, 2018 at 12:47 AM, Keith Packard wrote: > It's interesting to note > that we could have done the same thing for all of the redirected window > management requests in the core protocol, simplifying applications > tremendously... I'm not sure I follow. >> The biggest downside I see of this approach is that a CM can stall >> config changes by keeping a window in the AutoList potentially forever >> (either because of bugs or maliciously). This is particularly >> important if any client can do Present requests with an AutoList. > > Well, only one client can be the Compositing Manager with the > appropriate redirection of all window rendering, so we can probably > restrict the Auto List to only affect windows that the Compositing > Manager has redirected. (Or their descendants). But aside from the restriction on which window can be in the AutoList, my question was more along the lines of which clients should be allowed to specify an AutoList at all, and if the AutoList make senses at all outside of the Present requests from the Compositing Manager. > I've a whole separate set of plans for making X more secure; I hope to > start writing those up in a few months. Looking forward to give it a read. -- Giuseppe "Oblomov" Bilotta ___ 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: Making Composite better for interactive apps
On Sun, Feb 4, 2018 at 11:19 PM, Keith Packard wrote: > Giuseppe Bilotta writes: > >> Ah, good point. So Compton wouldn't break anyway, at worst it couldn't >> use the feature reliably. > > Having any reasonable Compositing Manager not work is a sign that the > design isn't quite right. Well, apparently Compton already has some issues with DRI3/Present already, e.g. https://bugs.freedesktop.org/show_bug.cgi?id=97916 but maybe that's Compton not being reasonable (using the root window instead of the typical overlay). > A key part of the design is that the Auto List be tied to a specific > presentation on the screen; geometry for the Auto List windows is > reserved in that image. So, we need to synchronously update the Auto > List and the presented image, hence tying them together. Given that the > Auto List is a (probably small) subset of the top-level windows, sending > it each time is probably simpler than creating a new resource to hold > it. Even sending a few hundred window IDs per frame wouldn't be > terrible. [...] >> Then if I understand correctly Mode 1 could be implemented by delaying >> the geometry change requests that happen after a Present request to >> after the actual page flip (or whichever other time is deemed “safe”), > > You raise a good point here -- we want the client geometry change to be > presented without any intermediate partial frames. I think the easiest > way to manage that is to have the Compositing Manager take control of > the display before the resize happens. It could be something as simple > as blocking any resize request for a window in the Auto List and sending > an event to the Compositing Manager to deal with the situation. > > How about this -- any configuration change (by a client other than the > Compositing Manager) affecting a member of the Auto List would be > blocked until a PresentPixmap request removes that element of the > AutoList. Adding a member to the AutoList is sufficient to register an > interest in the event. That would let us continue to allow arbitrary > windows in the AutoList and ensure that no configuration changes occur > while windows are on the Auto List. Wait, I'm confused: if the Auto List is associated with a specific presentation on the screen, and are thus in some sense ephemeral, how can windows be added/removed from it? Is this to be read in the sense that the configuration change is blocked until the CM does a Present whose Auto List does not contain the window? So if I read it correctly, it would work this way: 1. CM does a Present with an AutoList; 2. the server keeps the AutoList until the CM does a Present with a different AutoList (or the CM connection is closed); 3. if anything other than the CM requests a config change for a Window w in the AutoList, the request is stalled, but the CM is notified; 4. the CM gets notified of the pending config request, and on the next Present it removes w from the AutoList; 5. the pending config change gets processed using the normal mechanism; 6. the CM is notified of the actual change, so it can put the window back on the AutoList of the next Present; Is this the general idea? The biggest downside I see of this approach is that a CM can stall config changes by keeping a window in the AutoList potentially forever (either because of bugs or maliciously). This is particularly important if any client can do Present requests with an AutoList. -- Giuseppe "Oblomov" Bilotta ___ 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: Making Composite better for interactive apps
On Sat, Feb 3, 2018 at 9:23 PM, Keith Packard wrote: > (To be clear, what I'm proposing won't break anything that already > works -- the Auto List is entirely driven by the compositor, so if you > don't use it, you don't get this functionality.) > > But, yes, Compton wouldn't be able to use this if we relied on tying the > window manager and compositor together. Ah, good point. So Compton wouldn't break anyway, at worst it couldn't use the feature reliably. > So, to recap, I see three options > > 1) If the geometry change comes from a client other than the > Compositing Manager, block that geometry change and send an event > to the Compositing Manager to deal with it. > > 2) If the Window Manager and Compositing Manager are the same client, > have the Compositing Manager only add non override-redirect windows > to the Auto List, as it will naturally receive geometry change > requests by the client. If the Compositing Manager is separate, > then using the Auto List might result in mis-rendered frames. > > 3) Have the Compositing Manager specify the geometry with the root for > each element in the Auto List. Presentation of the auto list member > would use the specified geometry and not the actual window > geometry. > > Mode 3) leaves input running asynchronously with output, which is a bit > disconcerting, but I think we're only talking about a single frame of > lag assuming that the compositing manager is keeping up with the frame > rate. Mode 1) actually looks more plausible in this light; in either of > these two cases, you'd have some lag when reconfiguring windows. Actually I'm not sure 2) would work reliably even in the WM == CM case, if _any_ descendant can be put in the Auto list, since the WM wouldn't be aware of geometry changes in nested windows, right? Say that I have a client which is a video player, and it has multiple possible configurations (e.g. togglable controls at the bottom, togglable playlist on the right, etc). By some means, the video player asks the compositor to put the subwindow displaying the video (and nothing else) in the Auto list. Now, if the user toggles one of the extra panes, this would cause the subwindow which was added to the Auto list to be resized, and this can happen without knowledge of the the WM/CM, IIRC, so there would be a misrender even when the CM is the WM. So I think we need the CM to be _at least_ notified about geometry changes in the Auto windows regardless of whether CM=WM or not. However, if I understand the proposal correctly, the server knows about the Auto list only at Present time, which would be too late. Since the Auto list isn't likely to change frequently, would it be possible to build it _separately_ from the Present call? The list would then be stored on the server, which could use it to notify the CM about any geometry changes in the windows within (unless notified already by other means, of course). For multi-buffering, the CM could request the creation of multiple Auto lists, be notified about geometry changes from the union thereof, and specify which Auto list to use for each specific Present invocation. Or maybe just require that the CM manually elect to get notified of geometry changes for the windows they plan on putting in the Auto list? Then if I understand correctly Mode 1 could be implemented by delaying the geometry change requests that happen after a Present request to after the actual page flip (or whichever other time is deemed “safe”), for all windows in the Auto list. Then the lag in the window reconfiguration should be typically less than 1 frame (and probably preferrable to the guaranteed fulle frame desync between input and output that would come with Mode 3?). -- Giuseppe "Oblomov" Bilotta ___ 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: Making Composite better for interactive apps
Hello, On Sat, Feb 3, 2018 at 5:48 AM, Keith Packard wrote: > Hrm. This makes me wonder what to do if the auto-listed window is a > direct child of the root and its geometry changes. In that case, the > Compositing Manager wouldn't have enough control over the display as the > window might well fall under some other decorations painted by the > Compositing Manager. I can think of two options: > > 1) Block the geometry change and send an event to the compositing > manager to deal with it. > > 2) Only add non override-redirect windows to the Auto List, and then > assert that the Compositing Manager and Window Manager are the same > X client so that it would naturally receive geometry change requests > by the client. > > 2) seems sufficient to me; it covers the cases we care about most with > no complicated klugery in the X server for now. Wouldn't this break Compton? AFAIK it only operates as compositor, which is why it's a popular choice among users of tiling WMs such as i3 and awesome. -- Giuseppe "Oblomov" Bilotta ___ 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
[PATCH xserver] rrmonitor: allocate using the correct type
Monitor outputs are of type RROutput, not RRCrtc. (Which are both XID, so this makes no difference in practice, other than being technically correct.) Signed-off-by: Giuseppe Bilotta --- randr/rrmonitor.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/randr/rrmonitor.c b/randr/rrmonitor.c index 3f6e03e7d..1bb5018fe 100644 --- a/randr/rrmonitor.c +++ b/randr/rrmonitor.c @@ -92,7 +92,7 @@ RRMonitorSetFromServer(RRCrtcPtr crtc, RRMonitorPtr monitor) monitor->name = RRMonitorCrtcName(crtc); monitor->pScreen = crtc->pScreen; monitor->numOutputs = crtc->numOutputs; -monitor->outputs = calloc(crtc->numOutputs, sizeof(RRCrtc)); +monitor->outputs = calloc(crtc->numOutputs, sizeof(RROutput)); if (!monitor->outputs) return FALSE; for (o = 0; o < crtc->numOutputs; o++) -- 2.14.1.439.g647b9b4702 ___ 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
Some considerations about RANDR Monitors
Hello, I noticed is that for 'tracking' Monitors, the pixel information follows the rotation, but the physical size does not. I'm assuming this is intentional, as it fits what is mentioned in randrproto (which was however written before the Monitor type was introduced). > To avoid multiplicative explosion between orientation, reflection and sizes, > the sizes are only those sizes in the normal (0) rotation. When constructing the geometry automatically, the randr/rrmonitor.c code is also very explicit about this: it iterates over all CRTCs, gets the mm size of the first output without considering rotation, expands the pixel bounding box with all other outputs, and finally sets the physical size of the monitor in order to preserve the DPI of the first output. While this works reasonably well for what was the intended “normal” use of Monitors (joining up the multiple outputs of high-resolution monitors that use MST), it has two issues. The first issue is that, since the Monitor has no rotation information, the user needs to do two extra roundtrips to fetch the relevant information (one to fetch the output info for one of the outputs of the monitor info, and a second one to fetch the CRTC info for the output). The second issue is that this approach doesn't work, neither client nor server side, when the user joins outputs whose CRTCs have different rotation values. One may consider such a configuration unsupported, but it's actually rather reasonable. Consider for example a user that has two displays with the same (or similar) DPI, one rotated and one in normal orientation. If they are joined in a single Monitor with automatic sizing, the final reported size will actually depend on the enumeration order, and if the rotated one is enumerated first, the results will be completely bogus, even though in the other case they would actually be “correct” (or at the very least much more reasonable). A possible approach in this case would be to consider the rotation for the first CRTC when getting the initial physical size. One could then swap mmwidth and mmheight at the end if this swap was done initially. This would actually be consistent with the current behavior. I would actually prefer keeping the sizes swapped, to avoid the two extra roundtrips needed client-side, but of course, this would mean that different values would be reported, and this would break current clients (are there any actually using the information?) Any remarks? (I can implement the double-swap approach if deemed appropriate). By the way, I noticed here a bit of a discrepancy in randrproto. The MONITORINFO type is defined as having an outputs field which maps to a LISTofOUTPUTS (section 5.6). However, the wire protocol documentation (section A.1.1) actually mentions CRTCs. I found this rather confusing. I looked through the xserver source code, and it seems it's RROutputs that get sent, but in at least one place, randr/rrmonitor.c:95 in RRMonitorSetFromServer, the code reads monitor->outputs = calloc(crtc->numOutputs, sizeof(RRCrtc)); I'm assuming that the mention (and use) of CRTCs is in error, so I'll try to provide patches for this. Also, xrandr has monitors support, but it's not in the man page that I can see, I'll see if I can do something about this too. Also related, would a patch adding to xrandr the possibility to apply output changes to all outputs of a monitor make sense? Either with a specific --monitor flag, or by accepting a monitor name wherever an output name is accepted? -- Giuseppe "Oblomov" Bilotta ___ 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
[PATCH xserver 3/3] randr: free crtc->outputs on destroy
Signed-off-by: Giuseppe Bilotta --- randr/rrcrtc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/randr/rrcrtc.c b/randr/rrcrtc.c index c904fa035..39af679b2 100644 --- a/randr/rrcrtc.c +++ b/randr/rrcrtc.c @@ -878,6 +878,7 @@ RRCrtcDestroyResource(void *value, XID pid) free(crtc->gammaRed); if (crtc->mode) RRModeDestroy(crtc->mode); +free(crtc->outputs); free(crtc); return 1; } -- 2.14.1.439.g647b9b4702 ___ 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
[PATCH xserver 2/3] randr: always realloc crtcs and outputs
When the last crtc (resp. output) is destroyed, the rrScrPriv crtcs (resp. outputs) fields do not get cleared, which can lead to a situation where the private's numCrtcs (resp. numOutputs) field is zero, but the associated memory is still allocated. Just checking if numCrtcs (resp. numOutputs) is zero is thus not a good criteria to determine whetehr to use a realloc or a malloc. Since crtcs (resp. outputs) are NULL-initialized anyway, relying on numCrtcs (resp. numOutputs) is actually unnecessary, because reallocation of a NULL ptr is equivalent to a malloc anyway. Therefore, just use realloc() unconditionally, and ensure that the fields are properly initialized. Signed-off-by: Giuseppe Bilotta --- randr/rrcrtc.c | 9 +++-- randr/rroutput.c | 9 +++-- 2 files changed, 6 insertions(+), 12 deletions(-) diff --git a/randr/rrcrtc.c b/randr/rrcrtc.c index 2eb9fbdc8..c904fa035 100644 --- a/randr/rrcrtc.c +++ b/randr/rrcrtc.c @@ -66,13 +66,10 @@ RRCrtcCreate(ScreenPtr pScreen, void *devPrivate) pScrPriv = rrGetScrPriv(pScreen); /* make space for the crtc pointer */ -if (pScrPriv->numCrtcs) -crtcs = reallocarray(pScrPriv->crtcs, - pScrPriv->numCrtcs + 1, sizeof(RRCrtcPtr)); -else -crtcs = malloc(sizeof(RRCrtcPtr)); +crtcs = reallocarray(pScrPriv->crtcs, +pScrPriv->numCrtcs + 1, sizeof(RRCrtcPtr)); if (!crtcs) -return FALSE; +return NULL; pScrPriv->crtcs = crtcs; crtc = calloc(1, sizeof(RRCrtcRec)); diff --git a/randr/rroutput.c b/randr/rroutput.c index 647f19a52..90fe4e6c1 100644 --- a/randr/rroutput.c +++ b/randr/rroutput.c @@ -71,13 +71,10 @@ RROutputCreate(ScreenPtr pScreen, pScrPriv = rrGetScrPriv(pScreen); -if (pScrPriv->numOutputs) -outputs = reallocarray(pScrPriv->outputs, - pScrPriv->numOutputs + 1, sizeof(RROutputPtr)); -else -outputs = malloc(sizeof(RROutputPtr)); +outputs = reallocarray(pScrPriv->outputs, + pScrPriv->numOutputs + 1, sizeof(RROutputPtr)); if (!outputs) -return FALSE; +return NULL; pScrPriv->outputs = outputs; -- 2.14.1.439.g647b9b4702 ___ 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
[PATCH xserver 1/3] randr: rrGetScreenResources: initialize memory
Similarly to bb766ef11227bd8c71ac65845d1930edd0eda40d, ensure that the
extra padding is set to 0.
Signed-off-by: Giuseppe Bilotta
---
randr/rrscreen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/randr/rrscreen.c b/randr/rrscreen.c
index d6c499580..0c70b28dd 100644
--- a/randr/rrscreen.c
+++ b/randr/rrscreen.c
@@ -558,7 +558,7 @@ rrGetScreenResources(ClientPtr client, Bool query)
extraLen = rep.length << 2;
if (extraLen) {
-extra = malloc(extraLen);
+extra = calloc(1, extraLen);
if (!extra) {
free(modes);
return BadAlloc;
--
2.14.1.439.g647b9b4702
___
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
[PATCH xserver 0/3] randr valgrind cleanups
These three small patches replace and complement my previous “randr: properly cleanup on crtc and output destroy”. The first one cleans up another bit of unitialized memory being sent over the wire (similar to the previous ProcRRGtOutputInfo patch) which I didn't spot earlier, and the other two fix the leaks related to dynamic creation and destruction of crtcs and outputs (hopefull correctly, this time ;-)) Giuseppe Bilotta (3): randr: rrGetScreenResources: initialize memory randr: always realloc crtcs and outputs randr: free crtc->outputs on destroy randr/rrcrtc.c | 10 -- randr/rroutput.c | 9 +++-- randr/rrscreen.c | 2 +- 3 files changed, 8 insertions(+), 13 deletions(-) -- 2.14.1.439.g647b9b4702 ___ 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
[PATCH xserver] xkb: small clarification
---
xkb/xkbUtils.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
On Tue, Nov 7, 2017 at 10:55 AM, Eric Engestrom wrote:
> I think this patch is good, because it explicitly shows the NoSymbol
> value that is tested later on. The implicit 0s are fine, but I think adding
> a one-sentence explanation to the commit message would be good.
Oops, looks like it was pushed already.
Not sure if it's worth it anymore, but here's a one-line clarification comment
in-code, just in case.
--
Giuseppe "Oblomov" Bilotta
diff --git a/xkb/xkbUtils.c b/xkb/xkbUtils.c
index 8975ade8d..023902be5 100644
--- a/xkb/xkbUtils.c
+++ b/xkb/xkbUtils.c
@@ -222,7 +222,9 @@ XkbUpdateKeyTypesFromCore(DeviceIntPtr pXDev,
XkbDescPtr xkb;
unsigned key, nG, explicit;
int types[XkbNumKbdGroups];
-KeySym tsyms[XkbMaxSymsPerKey] = {NoSymbol}, *syms;
+/* Initialize tsym with NoSymbol, which conveniently has value 0 */
+KeySym tsyms[XkbMaxSymsPerKey] = { NoSymbol };
+KeySym *syms;
XkbMapChangesPtr mc;
xkb = pXDev->key->xkbInfo->desc;
--
2.14.1.439.g647b9b4702
___
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: [PATCH xserver 4/5] randr: properly cleanup on crtc and output destroy
On Mon, Nov 6, 2017 at 10:54 PM, Adam Jackson wrote:
> On Sat, 2017-11-04 at 23:06 +0100, Giuseppe Bilotta wrote:
>> Signed-off-by: Giuseppe Bilotta
>> ---
>> randr/rrcrtc.c | 6 ++
>> randr/rroutput.c | 5 +
>> 2 files changed, 11 insertions(+)
>>
>> diff --git a/randr/rrcrtc.c b/randr/rrcrtc.c
>> index 2eb9fbdc8..90922484f 100644
>> --- a/randr/rrcrtc.c
>> +++ b/randr/rrcrtc.c
>> @@ -873,6 +873,11 @@ RRCrtcDestroyResource(void *value, XID pid)
>> }
>> }
>>
>> +if (pScrPriv->numCrtcs == 0) {
>> +free(pScrPriv->crtcs);
>> +pScrPriv->crtcs = NULL;
>> +}
>> +
>> RRResourcesChanged(pScreen);
>> }
>>
>
> Nack. Cleaning up the screen private belongs in CloseScreen or similar,
> it shouldn't be triggered from a resource destructor.
While I don't disagree with the principle of the objection, I'd like
to point out that not cleaning up in the resource destructor is a leak
source. All allocation points rely on num* (e.g. numCrtcs) to
determine whether to do a malloc or realloc, assumingly not trusting
the pointer to be properly NULL-initialized. This means that a
numCrtcs = 0 with a non-freed crtcs will lead to leaks, always.
For example, RRCrtcCreate does a check for numCrtcs and uses a realloc
if it's non-zero, and a malloc if it's zero. In a situation where we
do RRCrtcCreate followed by RRCrtcDestroy followed by another
RRCrtcCreate, we have a leak. While for the CRTCs the example may be
ficticious, this kind of behavior is actually seen for things such as
outputs (whose dynamic creation and destruction is an actual feature
of some drivers).
Considering we already do a lot of memory management for the screen
private “outside” of screen functions (including allocations and
moves), I thought the resource would be the simplest and safest (as
in: guarantees no leaks) thing to do.
I'm guessing the better approach would be to rework the allocation
points, replacing the num* checks, going straight for reallocs
everywhere, and ensuring that the pointer field is correctly
NULL-initialized?
--
Giuseppe "Oblomov" Bilotta
___
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: [PATCH xserver] xkb: initialize tsyms
On Mon, Nov 6, 2017 at 4:41 PM, Eric Engestrom
wrote:
> On Friday, 2017-11-03 21:38:51 +0100, Giuseppe Bilotta wrote:
>> This fixes some “Conditional jump depends on uninitialized value(s)”
>> errors spotted by valgrind.
>>
>> Signed-off-by: Giuseppe Bilotta
>
> Reviewed-by: Eric Engestrom
>
> Although the rest of the array is 0-initialised, so this only works
> because NoSymbol is also 0.
Indeed. I considered clarifying this in a comment, and even just
making it all 0-initialized with {}. Would that be better?
--
Giuseppe "Oblomov" Bilotta
___
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
[PATCH xserver 2/5] Xephyr: free driverPrivates on Fini
---
hw/kdrive/ephyr/ephyr.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/hw/kdrive/ephyr/ephyr.c b/hw/kdrive/ephyr/ephyr.c
index d064f5154..acf389c1d 100644
--- a/hw/kdrive/ephyr/ephyr.c
+++ b/hw/kdrive/ephyr/ephyr.c
@@ -1303,6 +1303,7 @@ MouseDisable(KdPointerInfo * pi)
static void
MouseFini(KdPointerInfo * pi)
{
+free(pi->driverPrivate);
ephyrMouse = NULL;
return;
}
@@ -1366,6 +1367,7 @@ EphyrKeyboardDisable(KdKeyboardInfo * ki)
static void
EphyrKeyboardFini(KdKeyboardInfo * ki)
{
+free(ki->driverPrivate);
ephyrKbd = NULL;
return;
}
--
2.14.1.439.g647b9b4702
___
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
[PATCH xserver 1/5] xkb: initialize tsyms
This fixes some “Conditional jump depends on uninitialized value(s)”
errors spotted by valgrind.
Signed-off-by: Giuseppe Bilotta
---
xkb/xkbUtils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xkb/xkbUtils.c b/xkb/xkbUtils.c
index 25b5a364e..8975ade8d 100644
--- a/xkb/xkbUtils.c
+++ b/xkb/xkbUtils.c
@@ -222,7 +222,7 @@ XkbUpdateKeyTypesFromCore(DeviceIntPtr pXDev,
XkbDescPtr xkb;
unsigned key, nG, explicit;
int types[XkbNumKbdGroups];
-KeySym tsyms[XkbMaxSymsPerKey], *syms;
+KeySym tsyms[XkbMaxSymsPerKey] = {NoSymbol}, *syms;
XkbMapChangesPtr mc;
xkb = pXDev->key->xkbInfo->desc;
--
2.14.1.439.g647b9b4702
___
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
[PATCH xserver 5/5] glx: free fbconfigs on destroy
Signed-off-by: Giuseppe Bilotta
---
glx/glxscreens.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/glx/glxscreens.c b/glx/glxscreens.c
index 99bf6dd27..73444152a 100644
--- a/glx/glxscreens.c
+++ b/glx/glxscreens.c
@@ -423,8 +423,15 @@ __glXScreenInit(__GLXscreen * pGlxScreen, ScreenPtr
pScreen)
void
__glXScreenDestroy(__GLXscreen * screen)
{
+__GLXconfig *config, *next;
+
free(screen->glvnd);
free(screen->GLXextensions);
free(screen->GLextensions);
free(screen->visuals);
+
+for (config = screen->fbconfigs; config != NULL; config = next) {
+next = config->next;
+free(config);
+}
}
--
2.14.1.439.g647b9b4702
___
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
[PATCH xserver 0/5] misc valgrind cleanups
While playing around with Xephyr, I found out that the bring-up/tear-down cycles it goes through when repeatedly connecting single clients to a running sessions caused its memory usage to grow constantly. Running under valgrind brought to light a number of leaks and other assorted issues (such as usage of uninitialized memory). The attached patchets fixes most of the ones that are directly ascribable to the server and its structure. The patches are mostly trivial, but for a couple of them alternative (more fine-grained) approaches would also be possible. I went with the simplest ones to avoid overcomplicating the code. (Most of the remaining leaks are Mesa's responsbility, with the glsl_types not being properly freed, and affect Xephyr only via swrast_dri, so they are not part of this series. Giuseppe Bilotta (5): xkb: initialize tsyms Xephyr: free driverPrivates on Fini randr: ProcRRGetOutputInfo: initialize memory randr: properly cleanup on crtc and output destroy glx: free fbconfigs on destroy glx/glxscreens.c| 7 +++ hw/kdrive/ephyr/ephyr.c | 2 ++ randr/rrcrtc.c | 6 ++ randr/rroutput.c| 7 ++- xkb/xkbUtils.c | 2 +- 5 files changed, 22 insertions(+), 2 deletions(-) -- 2.14.1.439.g647b9b4702 ___ 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
[PATCH xserver 3/5] randr: ProcRRGetOutputInfo: initialize memory
Running Xephyr under valgrind reveals that we're sending some
uninitialized memory over the wire (particularly, the leftover padding
that comes from rounding extraLen to the next 32-bit multiple).
Solve by calloc()ing the memory instead of malloc()ing (the alternative
would be to memset just the padding, but I'm not sure it's more
convenient.)
Signed-off-by: Giuseppe Bilotta
---
randr/rroutput.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/randr/rroutput.c b/randr/rroutput.c
index a8efec409..647f19a52 100644
--- a/randr/rroutput.c
+++ b/randr/rroutput.c
@@ -459,7 +459,7 @@ ProcRRGetOutputInfo(ClientPtr client)
if (extraLen) {
rep.length += bytes_to_int32(extraLen);
-extra = malloc(extraLen);
+extra = calloc(1, extraLen);
if (!extra)
return BadAlloc;
}
--
2.14.1.439.g647b9b4702
___
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
[PATCH xserver 4/5] randr: properly cleanup on crtc and output destroy
Signed-off-by: Giuseppe Bilotta
---
randr/rrcrtc.c | 6 ++
randr/rroutput.c | 5 +
2 files changed, 11 insertions(+)
diff --git a/randr/rrcrtc.c b/randr/rrcrtc.c
index 2eb9fbdc8..90922484f 100644
--- a/randr/rrcrtc.c
+++ b/randr/rrcrtc.c
@@ -873,6 +873,11 @@ RRCrtcDestroyResource(void *value, XID pid)
}
}
+if (pScrPriv->numCrtcs == 0) {
+free(pScrPriv->crtcs);
+pScrPriv->crtcs = NULL;
+}
+
RRResourcesChanged(pScreen);
}
@@ -881,6 +886,7 @@ RRCrtcDestroyResource(void *value, XID pid)
free(crtc->gammaRed);
if (crtc->mode)
RRModeDestroy(crtc->mode);
+free(crtc->outputs);
free(crtc);
return 1;
}
diff --git a/randr/rroutput.c b/randr/rroutput.c
index 647f19a52..12afe7e6c 100644
--- a/randr/rroutput.c
+++ b/randr/rroutput.c
@@ -371,6 +371,11 @@ RROutputDestroyResource(void *value, XID pid)
}
}
+if (pScrPriv->numOutputs == 0) {
+free(pScrPriv->outputs);
+pScrPriv->outputs = NULL;
+}
+
RRResourcesChanged(pScreen);
}
if (output->modes) {
--
2.14.1.439.g647b9b4702
___
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
[PATCH xserver] xkb: initialize tsyms
This fixes some “Conditional jump depends on uninitialized value(s)”
errors spotted by valgrind.
Signed-off-by: Giuseppe Bilotta
---
xkb/xkbUtils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xkb/xkbUtils.c b/xkb/xkbUtils.c
index 25b5a364e..8975ade8d 100644
--- a/xkb/xkbUtils.c
+++ b/xkb/xkbUtils.c
@@ -222,7 +222,7 @@ XkbUpdateKeyTypesFromCore(DeviceIntPtr pXDev,
XkbDescPtr xkb;
unsigned key, nG, explicit;
int types[XkbNumKbdGroups];
-KeySym tsyms[XkbMaxSymsPerKey], *syms;
+KeySym tsyms[XkbMaxSymsPerKey] = {NoSymbol}, *syms;
XkbMapChangesPtr mc;
xkb = pXDev->key->xkbInfo->desc;
--
2.14.1.439.g647b9b4702
___
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: [PATCH] modesetting: fail PreInit() if the device has zero connectors
On Fri, Nov 3, 2017 at 10:09 AM, Hans de Goede wrote: > Weird, on my XPS15 9550 where the nvidia GPU does not have/drives any > outputs > I do get 2 devices in xrandr --listproviders as expected. You may want to > start > with figuring out why the normal setup where you load nouveau normally is > not > working. Perhaps once that works, it will also powerdown the GPU properly. I have an XPS15 9350 with a similar situation. You get two devices if nouveau is loaded before Xorg starts. If I understand Tobias' mail, his situation is with nouveau modprobed _while X is running already_, not if it's loaded before X starts. I've tried it in the past and I got the same segfaults that he is getting. I have AutoAddGPU set to false specifically to avoid this segfault, since I use a similar setup (no driver loaded, modprobe as needed), although in my case it's more out of a need to be able to switch to nvidia's proprietary as-needed. In my case I have verified that without loading nouveau or nvidia the GPU is powered up, which is supoptimal battery-wise, and I'm not sure nvidia powers down the GPU while not in use (nouveau does, byt to me is mostly useless, because the performance it achieves on the dGPU is less than the one I get on Intel's iGP, and I still need the nvidia one for CUDA), but as Tobias mentioned, that's a separate issue from the segfault that comes from runtime nouveau modprobing. -- Giuseppe "Oblomov" Bilotta ___ 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: [PATCH v2 app/xrandr] Document that --dpi and --fbmm options set DPI of whole X screen
On Thu, Nov 2, 2017 at 6:20 PM, Pali Rohár wrote: > > But back to my documentation update patch. It is needed to rework it? > And if yes, how, In light of my opinion on the relevant of the core DPI value, here's my take on it, chunk by chunk: > -Sets the reported values for the physical size of the screen. Normally, > +Sets the reported values for the physical size of the whole X screen (not > particular > +output!) which consists of all configured monitors. Physical size of the X > screen does > +not have any meaning when monitors with different DPI are configured. > Normally, > xrandr resets the reported physical size values to keep the DPI constant. How about something like this: Sets the value reported as physical size of the X Screen as a whole (union of all configured monitors). In configurations with multiple monitors with different DPIs, the value has no physical meaning, but it may be used by some clients to compute a reference font scaling. Normally etc > -This overrides that computation. > +This overrides that computation. This option should be calculated from DPI > +value 96 as it not have any useful meaning for multi-monitor configuration. I would skip this change. > -This also sets the reported physical size values of the screen, it uses > either > +This also sets the reported physical size values of the whole X screen (not > particular > +output!) which consists of all configured monitors. Physical size of the X > screen does not > +have any meaning when monitors with different DPI are configured. This > option uses either I would rewrite this to match the alternative I proposed for the first chunk. > -physical size using whatever pixel size will be set. > +physical size using whatever pixel size will be set (default 96 DPI). It > does not > +have any useful meaning for multi-monitor configuration. I would skip this change. If we do want to give some suggested values, it could be rewritten something like: physcal size using whatever pixel size will be set. Typical values are the default (96 DPI), the DPI of the only monitor in single-monitor configurations, or the DPI of the primary monitor in multi-monitor configurations. -- Giuseppe "Oblomov" Bilotta ___ 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
[PATCH xserver] dix/window: fix typos
--- dix/window.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/dix/window.c b/dix/window.c index ead4dc27f..8789a5ece 100644 --- a/dix/window.c +++ b/dix/window.c @@ -456,9 +456,9 @@ TraverseTree(WindowPtr pWin, VisitWindowProcPtr func, void *data) /* * WalkTree - * Walk the window tree, for SCREEN, preforming FUNC(pWin, data) on + * Walk the window tree, for SCREEN, performing FUNC(pWin, data) on * each window. If FUNC returns WT_WALKCHILDREN, traverse the children, - * if it returns WT_DONTWALKCHILDREN, dont. If it returns WT_STOPWALKING + * if it returns WT_DONTWALKCHILDREN, don't. If it returns WT_STOPWALKING, * exit WalkTree. Does depth-first traverse. */ -- 2.14.1.439.g647b9b4702 ___ 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: [PATCH v2 app/xrandr] Document that --dpi and --fbmm options set DPI of whole X screen
On Wed, Nov 1, 2017 at 9:35 PM, Adam Jackson wrote: > On Wed, 2017-11-01 at 21:04 +0100, Giuseppe Bilotta wrote: > >> (Heck, I would even argue that the core DPI should be set to the >> primary monitor DPI by default, regardless of whether the system has >> one or more than one monitor.) > The primary monitor can change at runtime. The core DPI is only sent at > initial connection. What would you like to do? Don't clients get an RRScreenChangeNotify already when the root window size changes? > Also: what's stopping us from fixing libXft instead? The core DPI as fallback of Xft.dpi is something that most toolkits follow as a rule, it's not just a libXft thing. It also makes perfect sense for single-monitor setups, since it reduces the pain needed to ensure proper UI scaling when switching resolution. AFAIK GTK3 is the only toolkit that stopped doing it, and to me that actually counts as a regression, as it makes it much harder to change the scaling of GTK3 applications when I change my output resolution (e.g. when I switch to projection mode for a lesson, and then back to using only my built-in laptop for work). I would rather not have libXft broken this way as well. -- Giuseppe "Oblomov" Bilotta ___ 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: [PATCH v2 app/xrandr] Document that --dpi and --fbmm options set DPI of whole X screen
On Wed, Nov 1, 2017 at 9:14 PM, Pali Rohár wrote: > On Wednesday 01 November 2017 21:04:17 Giuseppe Bilotta wrote: >> >> Personally, I disagree with the statement that the core DPI value has >> no useful meaning in multi-monitor configuration. > > Hi! I did not write such thing. > > The whole documentation is talking about physical size of the X Screen. > > There is no "core DPI". There is just resolution of the X Screen and > physical size (in mm) of the X Screen. And IIRC X Server does not report > any value "DPI" for X Screen. > > And as I added in patch, that physical size in mm of the X Screen does > not have any coordinate meaning as it does not match any physical > reality of display. > > So... now I'm thinking if documentation update by me is really good if > there are already people who interpreted it not in way as I thought :-( Sorry, I should have clarified. By “core DPI” I mean the DPI computed from the values of Screen width/height in pixel and mm as reported by the core protocol. But as I said, this value gets used _at the very least_ as the fallback for Xft.dpi (per the Xft specification), so it is not without meaning. However, I do agree with you that it might be useful to point out that the values do not carry a _physical_ meaning in the case of multiple monitors. -- Giuseppe "Oblomov" Bilotta ___ 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: [PATCH v2 app/xrandr] Document that --dpi and --fbmm options set DPI of whole X screen
On Wed, Nov 1, 2017 at 11:25 AM, Pali Rohár wrote: > Hello, can somebody process this my patch? > > There are no objections for a long time and Walter already reviewed it. > > On Monday 07 August 2017 18:45:22 walter harms wrote: >> Sorry, i had the idea you already got my ack. >> >> Reviewed-by: Walter Harms wha...@bfs.de >> >> Am 07.08.2017 12:56, schrieb Pali Rohár: >> > walter, any other objections? I fixed problematic parts which you pointed. >> > >> > On Monday 24 July 2017 20:34:39 Pali Rohár wrote: >> >> Explicitly document and make it clear that those options do not change >> >> DPI of some monitor output. Also state that these options have no useful >> >> meaning for multi-monitor configuration. Personally, I disagree with the statement that the core DPI value has no useful meaning in multi-monitor configuration. The core DPI (which is what is controlled by these flags) is the fallback value for Xft.dpi, and I routinely use it (as it's easier to modify dynamically) when starting legacy applications to have them scale according to the monitor I'm going to launch them on. With Qt, by setting it to the DPI of your primary monitor and enabling automatic screen scale factor computation, you can even get some decent mixed DPI support from quite a few applications. In fact, I would argue that it would be useful if all toolkits and applications that care about mixed-DPI setups on X11 would use a similar strategy: compute per monitor scale factors as Xft.dpi * primary.dpi/monitor.dpi (where primary.dpi is the DPI of the RANDR primary screen and monitor.dpi), and as usual with Xft.dpi falling back to the core DPI if unspecified. (Heck, I would even argue that the core DPI should be set to the primary monitor DPI by default, regardless of whether the system has one or more than one monitor.) -- Giuseppe "Oblomov" Bilotta ___ 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: [PATCH xserver] present: Only send PresentCompleteNotify events to the presenting client
On Fri, Oct 20, 2017 at 6:30 PM, Michel Dänzer wrote: > From: Michel Dänzer > > We were sending the events to all clients listening for them on the > window. But clients can get confused by events from another client, and > I can't imagine any case where reciving events from other clients would > be required. Potentially stupid question, but any chances that some “higher level” clients (window manager, screensaver) might be interested in the other clients' notifications? ___ 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
[PATCH xserver] configure.ac: unconditionally enable kdrive
There's only one kdrive DDX now, Xephyr, which is controlled by its own --enable-xephyr. Remove the conditional enabling of kdrive, which only caused confusion (e.g. both --enable-xephyr and --enable-kdrive were needed to be able to build Xephyr). Suggested-by: Adam Jackson Signed-off-by: Giuseppe Bilotta --- configure.ac | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index ec98f52c0..caf10dc98 100644 --- a/configure.ac +++ b/configure.ac @@ -594,7 +594,6 @@ AC_ARG_ENABLE(standalone-xpbproxy, AS_HELP_STRING([--enable-standalone-xpbproxy] AC_ARG_ENABLE(xwin, AS_HELP_STRING([--enable-xwin], [Build XWin server (default: auto)]), [XWIN=$enableval], [XWIN=auto]) AC_ARG_ENABLE(glamor, AS_HELP_STRING([--enable-glamor], [Build glamor dix module (default: auto)]), [GLAMOR=$enableval], [GLAMOR=auto]) dnl kdrive and its subsystems -AC_ARG_ENABLE(kdrive, AS_HELP_STRING([--enable-kdrive], [Build kdrive servers (default: no)]), [KDRIVE=$enableval], [KDRIVE=no]) AC_ARG_ENABLE(xephyr, AS_HELP_STRING([--enable-xephyr], [Build the kdrive Xephyr server (default: auto)]), [XEPHYR=$enableval], [XEPHYR=auto]) dnl kdrive options AC_ARG_ENABLE(libunwind, AS_HELP_STRING([--enable-libunwind], [Use libunwind for backtracing (default: auto)]), [LIBUNWIND="$enableval"], [LIBUNWIND="auto"]) @@ -2293,6 +2292,10 @@ fi AM_CONDITIONAL([DMX_BUILD_USB], [test "x$DMX_BUILD_USB" = xyes]) dnl kdrive DDX +dnl we now have only one kdrive DDX, which is Xephyr, so we enable kdrive +dnl unconditionally, and Xephyr will be enabled or not depending on whether +dnl the required libs are available or not +KDRIVE=yes XEPHYR_LIBS= XEPHYR_INCS= -- 2.14.1.439.g647b9b4702 ___ 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: [PATCH] Add NonDesktop output property and behaviors.
On Fri, Oct 20, 2017 at 6:08 PM, Keith Packard wrote: > Giuseppe Bilotta writes: > >> (I actually wish I had some free time to put my coding hands where my >> mouth is 8-P). > > I'd say it's more about waiting until we find a situation that actually > requires the additional work. Right now, the goal is to make a leased > output never part of the desktop, and that's where the current design is > focused. If we find a real use for doing something more complicated > later, we'll figure it out then. I see. From Aaron's clarification I got that the idea is to either not use the output via X (and thus only use X to get the lease), or if it's to be used via X it should be done via the standard RANDR management. Basically, the usage I was thinking of (using the output from within X, but outside of the default X Screen), isn't being contemplated. > X has a long history of having systems designed in advance of their need > and having that make things harder in the future, rather than easier... I'll trust you on that 8-) (Still, I've been fancying the idea of dynamic X Screens for a while now, and the use case I mentioned seemed to fit the bill pretty nicely.) -- Giuseppe "Oblomov" Bilotta ___ 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: [PATCH] Add NonDesktop output property and behaviors.
On Fri, Oct 20, 2017 at 8:35 PM, Aaron Plattner wrote: > > From Giuseppe: >> >> For the aforementioned touchpad/display, for example, one could envision >> a “detached” mode where it acts like, say, the Apple Touch Bar, and an >> “attached” mode where it's used like a standard display, for example to >> show a zoomed area around the cursor. Achieving this would require this >> properly to be mutable though. > > Giuseppe, I'm not sure I understand your suggestion about "attached" and > "detached" modes here. I.e. what exactly would a driver do in response to a > client writing this property? If you just want to switch between being part > of the desktop and not, you can do that by attaching or detaching it from a > crtc. As I mentioned in my reply to Keith, the driver might change operating mode. For example, something like the Razer touchpad display would work in absolute mode (mapped to that specific output) in detached, and in relative mode otherwise. I'm not sure if the display can be turned off entirely, but if this is the case one effectively needs some kind of tri-state (off, external, part of the default X Screen). > From Giuseppe: >> >> It would be interesting to make this an enum allowing >> different values, so that clients could differentiate between, say, an >> HMD and a TouchBar. (Maybe instead of RR_PROPERTY_NON_DESKTOP make it a >> RR_PROPERTY_OUTPUT_USAGE and have values 0 for Desktop, 1 for HMD, 2 for >> TouchSomething (could be the Apple thing or the Razer thing)? > > I agree with Keith that this should remain a simple boolean since you can > infer the type of the device from the EDID. Trying to specify an enum here > just opens the door to being inconsistent, and the list always being out of > date and too restrictive when new types of devices show up. That's a pretty solid reason. The only downside is that getting the EDID isn't trivial in scripts (but that can be solved extending the xrandr tool, for example). > From Giuseppe: >> >> I'm having troubles wrapping my mind around how exactly this works, >> particularly in relation to the root window framebuffer, and about how >> (or rather if) this can be achieved while still granting X clients >> access to the output, even if just in an ‘as needed’ use case (i.e. not >> as part of the “normal” operating mode). > > > The motivation here is that a client would use this output through some > other non-X API. Specifically Vulkan direct-to-display for virtual reality. > So X wouldn't be configured to drive this output with a crtc. Instead, it > would lease the output and a crtc to the client for its direct use. Ah, I see. The WM/DE doesn't use the output because it's marked disconnected, then a client that wants to use it uses the X API to get the lease, but then does NOT use X to render on the leased output. Yes, I agree that for this specific use case it works perfectly fine. > You could use a similar model for a touch bar thing, where you either drive > it directly using Vulkan, or tell X to display the X screen on it using > RandR to set a mode on it. You don't need to be able to write the NonDesktop > property for that. The downside of using the touch bar or whatever by extending the X screen to it is that this would cause the desktop to extend to it. I was thinking about the case where you wouldn't want the desktop to extend to it, but still use the X API to render to the output, hence the multiple X Screen ideas. (For example, I'm not sure if this is still the case, but some older versions of GIMP for example supported multiple X Screens relatively smoothly, and you could e.g. have the toolbars on an X Screen and the main window in another: adding support for the touch bar would be much simpler than the lease way). (Alternatively, one could lease that output and then maybe start an X server just for it, but that seems a bit … overkill?) -- Giuseppe "Oblomov" Bilotta ___ 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: [PATCH] Add NonDesktop output property and behaviors.
On Fri, Oct 20, 2017 at 3:25 AM, Keith Packard wrote: > Giuseppe Bilotta writes: > >> FWIW, some Razer laptop models have a touchpad that doubles as a >> secondary display. Not sure if it's worth mentioning (it does predate >> the Apple Touch Bar, has some very patchy support under Linux, none that >> I know of under Xorg). > > Thanks for another example. Is this display driven by the same hardware > as the main display? Nope, it's completely separate. I don't have the HW, so all I know I gathered from these sources: https://github.com/FxChiP/rzswitchblade http://fxchip.net/RazerBlade/ >> Would it make sense to have a distinct connection status instead? This >> would make it possible to differentiate between actual disconnection and >> “connected, but not really a standard output to be used for desktop”. >> (Would it possible to differentiate otherwise?) > > Yes, we could, but the goal is to remain backward compatible with the > existing protocol, and adding a new value here wouldn't meet that > requirement. If the RROutputChangeNotify event wasn't already 32 bytes > long, we could have added a new field there and reported its presence > with an updated version number. Alas. I see. I don't suppose that making the new value correspond to pre-1.6 RR_UnknownConnection would help? Older clients would still recognize it, but still not know what do with it. (But I'm guessing recycling values this way wouldn't really be very client friendly.) > The obvious alternative would be to report the connected status in a new > output property. I think the presence of all of the other data on the > disconnected output (in particular, a list of modes), along with the > non-desktop property, should be sufficient to know that it is connected? That would work, although it's definitely more work on the client side, rather than just checking a single field. >> For the aforementioned touchpad/display, for example, one could envision >> a “detached” mode where it acts like, say, the Apple Touch Bar, and an >> “attached” mode where it's used like a standard display, for example to >> show a zoomed area around the cursor. Achieving this would require this >> properly to be mutable though. > > The current server architecture doesn't provide a mechanism for the user > to override driver-provided values, which pushes against this reasonable > request. It is a policy of sorts, and it's nice to be able to fix things > in user space where necessary. How would you reset it back to 'whatever > the driver thinks' though? Allow it to be set to some other value? I was thinking along the lines of letting user change the value _when possible_, e.g. when the driver itself might support multiple modes of operation. There would need to be some kind of integration with the input side of things though. Consider for example the aforementioned Razer touchpad display: in “detached” mode the touchpad would work as an absolute pointing device for its own display, in “attached” mode it would work as a standard touchpad. Client setting the value would make the driver switch both the nondesktop property _and_ the input device M.O. —assuming that makes sense at all. Another approach that might work would be for drivers that support both M.O. to present two clone outputs instead of one, where one is non-desktop and the other is desktop, and then runtime could switch between them by turning them on and off, with the condition that turning one on automatically turns the other off? >> It would be interesting to make this an enum allowing >> different values, so that clients could differentiate between, say, an >> HMD and a TouchBar. (Maybe instead of RR_PROPERTY_NON_DESKTOP make it a >> RR_PROPERTY_OUTPUT_USAGE and have values 0 for Desktop, 1 for HMD, 2 for >> TouchSomething (could be the Apple thing or the Razer thing)? > > We can certainly add more information in additional properties. You do > have access to the EDID data, of course, so you can make choices based > on that. I want to leave the non-desktop property itself a simple > boolean and consider adding more information when we find additional > uses. I'm probably a bit stuck in the C mindset that enums can work as booleans as long as you have a single false state ;-) So checking if the value is (present and) non-zero would act as a boolean, but the same value could also carry the extra info. But I get the point. > If you wanted to 'hide' it from other X applications, you would create a > Monitor that covered the geometry of another active output and assign > that to both the other output and the one to be hidden so that the > geometry of the hidden output was not included in the overall Monitor > geo
Re: [PATCH] Add NonDesktop output property and behaviors.
, because the root windows are completely separate from each other; * clients can still access the other X Screens if they really want to. This would probably work reasonable well for the TouchThings (since they probably need different drivers anyway), but I'm not sure how well it fits with HMD (last time I tried getting separate X Screens with separate outputs on the same GPU I had to give, it seemed an essentially impossible task). I'm probably overengineering this in my head, but I wonder if something like this would be possible: * during autoconfiguration, the X server generates one X Screen per available output (this is necessary because IIRC the protocol doesn't really contemplate the possibility to add X Screens dynamically; but maybe it's not actually necessary either); * all outputs are assigned to the default X Screen on startup, but the RANDR protocol is extended to allow “moving” outputs between X Screens (X Screens with no assigned output might have e.g. a DUMMY connector or something like that, to avoid silly crashes in some clients); * if a non-desktop device is attached (e.g. HMD), the corresponding output is redirected to the first available (i.e. no-output) X Screen. Is this too crazy an idea? Best regards, Giuseppe Bilotta ___ 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
[PATCH xrandr v3 1/3] xrandr: allow a single value for --scale
This allows using e.g. --scale 0.5 as a shorthand for --scale 0.5x0.5
Signed-off-by: Giuseppe Bilotta
---
man/xrandr.man | 7 ---
xrandr.c | 8 ++--
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/man/xrandr.man b/man/xrandr.man
index 65ccc2a..e59abbe 100644
--- a/man/xrandr.man
+++ b/man/xrandr.man
@@ -34,7 +34,7 @@ xrandr \- primitive command line interface to RandR extension
[\-\-current]
[\-\-noprimary]
[\-\-panning
\fIwidth\fPx\fIheight\fP[+\fIx\fP+\fIy\fP[/\fItrack_width\fPx\fItrack_height\fP+\fItrack_x\fP+\fItrack_y\fP[/\fIborder_left\fP/\fIborder_top\fP/\fIborder_right\fP/\fIborder_bottom\fP
-[\-\-scale \fIx\fPx\fIy\fP]
+[\-\-scale \fIx\fP[x\fIy\fP]]
[\-\-scale-from \fIw\fPx\fIh\fP]
[\-\-transform
\fIa\fP,\fIb\fP,\fIc\fP,\fId\fP,\fIe\fP,\fIf\fP,\fIg\fP,\fIh\fP,\fIi\fP]
[\-\-primary]
@@ -207,8 +207,9 @@ values are used (a unit matrix without filter).
Chooses the scaling filter method to be applied when the screen is scaled or
transformed.
Can be either 'bilinear' or 'nearest'.
-.IP "\-\-scale \fIx\fPx\fIy\fP"
-Changes the dimensions of the output picture. Values superior to 1 will lead to
+.IP "\-\-scale \fIx\fP[x\fIy\fP]"
+Changes the dimensions of the output picture. If the \fIy\fP value is omitted,
+the \fIx\fP value will be used for both dimensions. Values superior to 1 will
lead to
a compressed screen (screen dimension bigger than the dimension of the output
mode), and values below 1 leads to a zoom in on the output. This option is
actually a shortcut version of the \fI\-\-transform\fP option.
diff --git a/xrandr.c b/xrandr.c
index 2d4cb72..1085a95 100644
--- a/xrandr.c
+++ b/xrandr.c
@@ -137,7 +137,7 @@ usage(void)
" --below \n"
" --same-as \n"
" --set \n"
- " --scale x\n"
+ " --scale [x]\n"
" --scale-from x\n"
" --transform \n"
" --filter nearest,bilinear\n"
@@ -3017,7 +3017,11 @@ main (int argc, char **argv)
if (!config_output) argerr ("%s must be used after --output\n",
argv[i]);
if (++i >= argc) argerr ("%s requires an argument\n", argv[i-1]);
if (sscanf (argv[i], "%lfx%lf", &sx, &sy) != 2)
- argerr ("failed to parse '%s' as a scaling factor\n", argv[i]);
+ {
+ if (sscanf (argv[i], "%lf", &sx) != 1)
+ argerr ("failed to parse '%s' as a scaling factor\n",
argv[i]);
+ sy = sx;
+ }
init_transform (&config_output->transform);
config_output->transform.transform.matrix[0][0] = XDoubleToFixed
(sx);
config_output->transform.transform.matrix[1][1] = XDoubleToFixed
(sy);
--
2.13.0.rc0.207.gb442654931
___
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
[PATCH xrandr v3 3/3] xrandr.man: grammar tuning
Rephrase the --scale option paragraph to improve English and be more consistent in choice of plurals and tense. Also ensure that each sentence starts on a new line in the roff source. Signed-off-by: Giuseppe Bilotta --- man/xrandr.man | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/man/xrandr.man b/man/xrandr.man index e59abbe..cfbfb8f 100644 --- a/man/xrandr.man +++ b/man/xrandr.man @@ -208,11 +208,12 @@ Chooses the scaling filter method to be applied when the screen is scaled or transformed. Can be either 'bilinear' or 'nearest'. .IP "\-\-scale \fIx\fP[x\fIy\fP]" -Changes the dimensions of the output picture. If the \fIy\fP value is omitted, -the \fIx\fP value will be used for both dimensions. Values superior to 1 will lead to -a compressed screen (screen dimension bigger than the dimension of the output -mode), and values below 1 leads to a zoom in on the output. This option is -actually a shortcut version of the \fI\-\-transform\fP option. +Changes the dimensions of the output picture. +If the \fIy\fP value is omitted, the \fIx\fP value will be used for both dimensions. +Values larger than 1 lead to a compressed screen (screen dimension bigger +than the dimension of the output mode), and values less than 1 lead to +a zoom in on the output. +This option is actually a shortcut version of the \fI\-\-transform\fP option. .IP "\-\-scale-from \fIw\fPx\fIh\fP" Specifies the size in pixels of the area of the framebuffer to be displayed on this output. -- 2.13.0.rc0.207.gb442654931 ___ 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
[PATCH xrandr v3 2/3] xrandr: stricter --scale argument parsing
We used to accept something like --scale 2x3junk as a valid input
(scaling x by 2 and y by 3), even though this isn't really a valid
scaling factor.
Fix by making sure there is nothing after the parsed number(s).
Signed-off-by: Giuseppe Bilotta
---
xrandr.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/xrandr.c b/xrandr.c
index 1085a95..6a38cf2 100644
--- a/xrandr.c
+++ b/xrandr.c
@@ -3014,11 +3014,12 @@ main (int argc, char **argv)
if (!strcmp ("--scale", argv[i]))
{
double sx, sy;
+ char junk;
if (!config_output) argerr ("%s must be used after --output\n",
argv[i]);
if (++i >= argc) argerr ("%s requires an argument\n", argv[i-1]);
- if (sscanf (argv[i], "%lfx%lf", &sx, &sy) != 2)
+ if (sscanf (argv[i], "%lfx%lf%c", &sx, &sy, &junk) != 2)
{
- if (sscanf (argv[i], "%lf", &sx) != 1)
+ if (sscanf (argv[i], "%lf%c", &sx, &junk) != 1)
argerr ("failed to parse '%s' as a scaling factor\n",
argv[i]);
sy = sx;
}
--
2.13.0.rc0.207.gb442654931
___
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
[PATCH xrandr v3 0/3] xrandr: improve --scale option parsing
Some trivial patches. The first one allows the specification of a single scaling value (--scale 2 for --scale 2x2). The second makes parsing stricter by refusing the value if there is junk after an assumingly valid scaling factor (2x3a or 4j). The third one fixes some grammar issues in the --scale paragraph of the man page. v2: rebased on current head. v3: fix code indentation, add grammar fix patch Giuseppe Bilotta (3): xrandr: allow a single value for --scale xrandr: stricter --scale argument parsing xrandr.man: grammar tuning man/xrandr.man | 14 -- xrandr.c | 11 --- 2 files changed, 16 insertions(+), 9 deletions(-) -- 2.13.0.rc0.207.gb442654931 ___ 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: [PATCH xrandr v2 1/2] xrandr: allow a single value for --scale
Hello,
On Fri, Jul 14, 2017 at 2:46 AM, Aaron Plattner wrote:
>> -.IP "\-\-scale \fIx\fPx\fIy\fP"
>> -Changes the dimensions of the output picture. Values superior to 1 will
>> lead to
>> +.IP "\-\-scale \fIx\fP[x\fIy\fP]"
>> +Changes the dimensions of the output picture. If the \fIy\fP value is
>> omitted,
>> +the \fIx\fP value will be used for both dimensions. Values superior to 1
>> will lead to
>
>
> I think "greater than" or "larger than" are more common than "superior to"
> for numerical comparisons, and new sentences in roff format are supposed to
> start on their own lines. I can send a separate change to fix those if you
> don't feel like fixing them as part of this change.
No problem. I'll respin the series to get the whitespace right in this patch,
and add a patch for the grammar fixes and newline-before-sentence
(there's a few plurals
in the rest of the paragraph that aren't very convincing either)
>> if (sscanf (argv[i], "%lfx%lf", &sx, &sy) != 2)
>> - argerr ("failed to parse '%s' as a scaling factor\n",
>> argv[i]);
>> + {
>> + if (sscanf (argv[i], "%lf", &sx) != 1)
>
>
> This looks like it's indented too far. Should be two tabs and no spaces, and
> the next line should be two tabs and four spaces. Yes, this is terrible and
> I hate it. ;)
Let's see if I can get it right 8-)
--
Giuseppe "Oblomov" Bilotta
___
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
[PATCH xrandr v2 1/2] xrandr: allow a single value for --scale
This allows using e.g. --scale 0.5 as a shorthand for --scale 0.5x0.5
Signed-off-by: Giuseppe Bilotta
---
man/xrandr.man | 7 ---
xrandr.c | 8 ++--
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/man/xrandr.man b/man/xrandr.man
index 65ccc2a..e59abbe 100644
--- a/man/xrandr.man
+++ b/man/xrandr.man
@@ -34,7 +34,7 @@ xrandr \- primitive command line interface to RandR extension
[\-\-current]
[\-\-noprimary]
[\-\-panning
\fIwidth\fPx\fIheight\fP[+\fIx\fP+\fIy\fP[/\fItrack_width\fPx\fItrack_height\fP+\fItrack_x\fP+\fItrack_y\fP[/\fIborder_left\fP/\fIborder_top\fP/\fIborder_right\fP/\fIborder_bottom\fP
-[\-\-scale \fIx\fPx\fIy\fP]
+[\-\-scale \fIx\fP[x\fIy\fP]]
[\-\-scale-from \fIw\fPx\fIh\fP]
[\-\-transform
\fIa\fP,\fIb\fP,\fIc\fP,\fId\fP,\fIe\fP,\fIf\fP,\fIg\fP,\fIh\fP,\fIi\fP]
[\-\-primary]
@@ -207,8 +207,9 @@ values are used (a unit matrix without filter).
Chooses the scaling filter method to be applied when the screen is scaled or
transformed.
Can be either 'bilinear' or 'nearest'.
-.IP "\-\-scale \fIx\fPx\fIy\fP"
-Changes the dimensions of the output picture. Values superior to 1 will lead to
+.IP "\-\-scale \fIx\fP[x\fIy\fP]"
+Changes the dimensions of the output picture. If the \fIy\fP value is omitted,
+the \fIx\fP value will be used for both dimensions. Values superior to 1 will
lead to
a compressed screen (screen dimension bigger than the dimension of the output
mode), and values below 1 leads to a zoom in on the output. This option is
actually a shortcut version of the \fI\-\-transform\fP option.
diff --git a/xrandr.c b/xrandr.c
index 2d4cb72..4433724 100644
--- a/xrandr.c
+++ b/xrandr.c
@@ -137,7 +137,7 @@ usage(void)
" --below \n"
" --same-as \n"
" --set \n"
- " --scale x\n"
+ " --scale [x]\n"
" --scale-from x\n"
" --transform \n"
" --filter nearest,bilinear\n"
@@ -3017,7 +3017,11 @@ main (int argc, char **argv)
if (!config_output) argerr ("%s must be used after --output\n",
argv[i]);
if (++i >= argc) argerr ("%s requires an argument\n", argv[i-1]);
if (sscanf (argv[i], "%lfx%lf", &sx, &sy) != 2)
- argerr ("failed to parse '%s' as a scaling factor\n", argv[i]);
+ {
+ if (sscanf (argv[i], "%lf", &sx) != 1)
+ argerr ("failed to parse '%s' as a scaling
factor\n", argv[i]);
+ sy = sx;
+ }
init_transform (&config_output->transform);
config_output->transform.transform.matrix[0][0] = XDoubleToFixed
(sx);
config_output->transform.transform.matrix[1][1] = XDoubleToFixed
(sy);
--
2.13.0.rc0.207.gb442654931
___
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
[PATCH xrandr v2 0/2] xrandr: improve --scale option parsing
A couple of trivial patches. The first one allows the specification of a single scaling value (--scale 2 for --scale 2x2), the second makes parsing stricter by refusing the value if there is junk after an assumingly valid scaling factor (2x3a or 4j). v2: rebased on current head. Giuseppe Bilotta (2): xrandr: allow a single value for --scale xrandr: stricter --scale argument parsing man/xrandr.man | 7 --- xrandr.c | 11 --- 2 files changed, 12 insertions(+), 6 deletions(-) -- 2.13.0.rc0.207.gb442654931 ___ 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
[PATCH xrandr v2 2/2] xrandr: stricter --scale argument parsing
We used to accept something like --scale 2x3junk as a valid input
(scaling x by 2 and y by 3), even though this isn't really a valid
scaling factor.
Fix by making sure there is nothing after the parsed number(s).
Signed-off-by: Giuseppe Bilotta
---
xrandr.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/xrandr.c b/xrandr.c
index 4433724..5056e8b 100644
--- a/xrandr.c
+++ b/xrandr.c
@@ -3014,11 +3014,12 @@ main (int argc, char **argv)
if (!strcmp ("--scale", argv[i]))
{
double sx, sy;
+ char junk;
if (!config_output) argerr ("%s must be used after --output\n",
argv[i]);
if (++i >= argc) argerr ("%s requires an argument\n", argv[i-1]);
- if (sscanf (argv[i], "%lfx%lf", &sx, &sy) != 2)
+ if (sscanf (argv[i], "%lfx%lf%c", &sx, &sy, &junk) != 2)
{
- if (sscanf (argv[i], "%lf", &sx) != 1)
+ if (sscanf (argv[i], "%lf%c", &sx, &junk) != 1)
argerr ("failed to parse '%s' as a scaling
factor\n", argv[i]);
sy = sx;
}
--
2.13.0.rc0.207.gb442654931
___
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
[PATCH xrandr 2/2] xrandr: stricter --scale argument parsing
We used to accept something like --scale 2x3junk as a valid input
(scaling x by 2 and y by 3), even though this isn't really a valid
scaling factor.
Fix by making sure there is nothing after the parsed number(s).
Signed-off-by: Giuseppe Bilotta
---
xrandr.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/xrandr.c b/xrandr.c
index 9f73d0f..9673b0e 100644
--- a/xrandr.c
+++ b/xrandr.c
@@ -2981,11 +2981,12 @@ main (int argc, char **argv)
if (!strcmp ("--scale", argv[i]))
{
double sx, sy;
+ char junk;
if (!config_output) argerr ("%s must be used after --output\n",
argv[i]);
if (++i >= argc) argerr ("%s requires an argument\n", argv[i-1]);
- if (sscanf (argv[i], "%lfx%lf", &sx, &sy) != 2)
+ if (sscanf (argv[i], "%lfx%lf%c", &sx, &sy, &junk) != 2)
{
- if (sscanf (argv[i], "%lf", &sx) != 1)
+ if (sscanf (argv[i], "%lf%c", &sx, &junk) != 1)
argerr ("failed to parse '%s' as a scaling
factor\n", argv[i]);
sy = sx;
}
--
2.13.0.rc0.207.gb442654931
___
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
[PATCH xrandr 1/2] xrandr: allow a single value for --scale
This allows using e.g. --scale 0.5 as a shorthand for --scale 0.5x0.5
Signed-off-by: Giuseppe Bilotta
---
man/xrandr.man | 7 ---
xrandr.c | 8 ++--
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/man/xrandr.man b/man/xrandr.man
index 5742286..1be771d 100644
--- a/man/xrandr.man
+++ b/man/xrandr.man
@@ -34,7 +34,7 @@ xrandr \- primitive command line interface to RandR extension
[\-\-current]
[\-\-noprimary]
[\-\-panning
\fIwidth\fPx\fIheight\fP[+\fIx\fP+\fIy\fP[/\fItrack_width\fPx\fItrack_height\fP+\fItrack_x\fP+\fItrack_y\fP[/\fIborder_left\fP/\fIborder_top\fP/\fIborder_right\fP/\fIborder_bottom\fP
-[\-\-scale \fIx\fPx\fIy\fP]
+[\-\-scale \fIx\fP[x\fIy\fP]]
[\-\-scale-from \fIw\fPx\fIh\fP]
[\-\-transform
\fIa\fP,\fIb\fP,\fIc\fP,\fId\fP,\fIe\fP,\fIf\fP,\fIg\fP,\fIh\fP,\fIi\fP]
[\-\-primary]
@@ -200,8 +200,9 @@ As a special argument, instead of
passing a matrix, one can pass the string \fInone\fP, in which case the default
values are used (a unit matrix without filter).
.RE
-.IP "\-\-scale \fIx\fPx\fIy\fP"
-Changes the dimensions of the output picture. Values superior to 1 will lead to
+.IP "\-\-scale \fIx\fP[x\fIy\fP]"
+Changes the dimensions of the output picture. If the \fIy\fP value is omitted,
+the \fIx\fP value will be used for both dimensions. Values superior to 1 will
lead to
a compressed screen (screen dimension bigger than the dimension of the output
mode), and values below 1 leads to a zoom in on the output. This option is
actually a shortcut version of the \fI\-\-transform\fP option.
diff --git a/xrandr.c b/xrandr.c
index 2aad946..9f73d0f 100644
--- a/xrandr.c
+++ b/xrandr.c
@@ -132,7 +132,7 @@ usage(void)
" --below \n"
" --same-as \n"
" --set \n"
- " --scale x\n"
+ " --scale [x]\n"
" --scale-from x\n"
" --transform \n"
" --off\n"
@@ -2984,7 +2984,11 @@ main (int argc, char **argv)
if (!config_output) argerr ("%s must be used after --output\n",
argv[i]);
if (++i >= argc) argerr ("%s requires an argument\n", argv[i-1]);
if (sscanf (argv[i], "%lfx%lf", &sx, &sy) != 2)
- argerr ("failed to parse '%s' as a scaling factor\n", argv[i]);
+ {
+ if (sscanf (argv[i], "%lf", &sx) != 1)
+ argerr ("failed to parse '%s' as a scaling
factor\n", argv[i]);
+ sy = sx;
+ }
init_transform (&config_output->transform);
config_output->transform.transform.matrix[0][0] = XDoubleToFixed
(sx);
config_output->transform.transform.matrix[1][1] = XDoubleToFixed
(sy);
--
2.13.0.rc0.207.gb442654931
___
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
[PATCH xrandr 0/2] xrandr: improve --scale option parsing
A couple of trivial patches. The first one allows the specification of a single scaling value (--scale 2 for --scale 2x2), the second makes parsing stricter by refusing the value if there is junk after an assumingly valid scaling factor (2x3a or 4j). Giuseppe Bilotta (2): xrandr: allow a single value for --scale xrandr: stricter --scale argument parsing man/xrandr.man | 7 --- xrandr.c | 11 --- 2 files changed, 12 insertions(+), 6 deletions(-) -- 2.13.0.rc0.207.gb442654931 ___ 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
[PATCH xrandr] xrandr: suppress misleading indentation warning
When printing out rotations, we print a space before any item other than
the first, and set `first = False` in each block where we print.
However, this is done in the same line as the conditional that checks if
first is set, which may give the impression that the assignment is also
under the conditional. This is not the case, and recent GCC warns about
this.
Move the assignment to after we print the value we want to print, which
(1) doesn't mislead about the indentation, and
(2) makes logical sense as the _next_ entry is what won't be the first.
Signed-off-by: Giuseppe Bilotta
---
xrandr.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
A possible alternative would be to wrap the whole line (after the conditional)
in { }, but I wasn't sure if this was the intent or not.
diff --git a/xrandr.c b/xrandr.c
index dcfdde0..2aad946 100644
--- a/xrandr.c
+++ b/xrandr.c
@@ -3703,14 +3703,16 @@ main (int argc, char **argv)
printf (" (");
for (i = 0; i < 4; i ++) {
if ((rotations >> i) & 1) {
- if (!first) printf (" "); first = False;
+ if (!first) printf (" ");
printf("%s", direction[i]);
+ first = False;
}
}
if (rotations & RR_Reflect_X)
{
- if (!first) printf (" "); first = False;
+ if (!first) printf (" ");
printf ("x axis");
+ first = False;
}
if (rotations & RR_Reflect_Y)
{
--
2.8.1.372.g9612035
___
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
[PATCH xrandr] xrandr: document that we accept '--dpi output'
Signed-off-by: Giuseppe Bilotta --- man/xrandr.man | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/man/xrandr.man b/man/xrandr.man index 73d337c..5742286 100644 --- a/man/xrandr.man +++ b/man/xrandr.man @@ -41,7 +41,7 @@ xrandr \- primitive command line interface to RandR extension [\-\-prop] [\-\-fb \fIwidth\fPx\fIheight\fP] [\-\-fbmm \fIwidth\fPx\fIheight\fP] -[\-\-dpi \fIdpi\fP] +[\-\-dpi \fIdpi\fP/\fIoutput\fP] [\-\-newmode \fIname\fP \fImode\fP] [\-\-rmmode \fIname\fP] [\-\-addmode \fIoutput\fP \fIname\fP] @@ -228,10 +228,10 @@ option provides a way to override that behaviour. Sets the reported values for the physical size of the screen. Normally, xrandr resets the reported physical size values to keep the DPI constant. This overrides that computation. -.IP "\-\-dpi \fIdpi\fP" -This also sets the reported physical size values of the screen, it uses the -specified DPI value to compute an appropriate physical size using whatever -pixel size will be set. +.IP "\-\-dpi \fIdpi\fP/\fIoutput\fP" +This also sets the reported physical size values of the screen, it uses either +the specified DPI value, or the DPI of the given output, to compute an appropriate +physical size using whatever pixel size will be set. .IP "\-\-newmode \fIname\fP \fImode\fP" New modelines can be added to the server and then associated with outputs. This option does the former. The \fImode\fP is specified using the ModeLine -- 2.8.1.372.g9612035 ___ 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: [PATCH xserver] tests: link against libos too
On Sat, Jan 14, 2017 at 12:27 PM, Mihail Konev wrote: > Thanks and sorry for late response. > With dtrace being present, this breaks the build. > Conditioned patch attached. Just tried with my patch reversed and yours applied, works for me, thanks. -- Giuseppe "Oblomov" Bilotta ___ 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
[PATCH xserver] tests: link against libos too
Without it, compiling tests fails due to the xsha1 functions defined in libos and referenced from HashGlyph in render. Signed-off-by: Giuseppe Bilotta --- test/Makefile.am | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/test/Makefile.am b/test/Makefile.am index 729402f..78d8f9f 100644 --- a/test/Makefile.am +++ b/test/Makefile.am @@ -140,7 +140,8 @@ tests_LDADD += \ $(top_builddir)/hw/xfree86/i2c/libi2c.la \ $(top_builddir)/hw/xfree86/dixmods/libxorgxkb.la \ $(top_builddir)/Xext/libXvidmode.la \ -@XORG_LIBS@ +@XORG_LIBS@ \ +@OS_LIB@ BUILT_SOURCES = sdksyms.c CLEANFILES += sdksyms.c -- 2.8.1.372.g9612035 ___ 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: [PATCH synaptic 1/2] config: collect options during preinit
On Wed, Sep 22, 2010 at 6:31 PM, Peter Hutterer wrote: > > with the new input API, the server calls xf86CollectInputOptions() already, > so this only needs to go into the old PreInit function. ACK to the second > patch though, please send me a new version of this and I'll push it. thanks. Thanks for the review and for the information. I sent a v2 of this patch, let me know if I misinterpreted your words and put the call in the wrong place again 8-) -- Giuseppe "Oblomov" Bilotta ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCHv2 synaptic 1/2] config: collect options during preinit
This must to ensure that the "Device" option is set correctly before SetDeviceAndProtocol is called, but it's only needed when the old input API is used. Signed-off-by: Giuseppe Bilotta --- src/synaptics.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/src/synaptics.c b/src/synaptics.c index eae48d2..57b463c 100644 --- a/src/synaptics.c +++ b/src/synaptics.c @@ -674,6 +674,8 @@ SynapticsPreInit(InputDriverPtr drv, IDevPtr dev, int flags) pInfo->conf_idev = dev; pInfo->always_core_feedback= 0; +xf86CollectInputOptions(pInfo, NULL, NULL); + if (NewSynapticsPreInit(drv, pInfo, flags) != Success) return NULL; -- 1.7.3.rc1.230.gdf48043 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH synaptic 2/2] config: don't autoprobe when device was set
If device was already set, we were asked to handle that specific device
and we should not go probing around. If we do, we might end up handling
a device different from what the X server thinks we are handling, with
dire consequences in case of hot plugging and unplugging.
Without this patch, a situation such as the following can happen.
A user has both a built-in laptop touchpad and a tablet such as the
Wacom Bamboo Pen & Touch, that is also exposed as a touchpad.
The tablet is plugged in before the server starts, and during setup the
server calls the synaptic driver for the /dev/input/mouseX device
corresponding to the touch device of the tablet; we end up in the
autoprobe path even though `device' was set, and the driver scans
/dev/input, where the first useful device it finds is the event device
for the built-in touchpad.
The driver starts managing the built-in touchpad, preventing future
instances from managing it too, while the server thinks the driver is
managing the tablet.
When the user disconnects the tablet, the corresponding instance of the
synpatics driver (which is actually managing the touchpad instead) is
unloaded: the built-in touchpad stops working in X.
Signed-off-by: Giuseppe Bilotta
---
src/synaptics.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/synaptics.c b/src/synaptics.c
index 89398f5..e0b93a0 100644
--- a/src/synaptics.c
+++ b/src/synaptics.c
@@ -275,7 +275,7 @@ SetDeviceAndProtocol(InputInfoPtr pInfo)
proto = SYN_PROTO_ALPS;
} else { /* default to auto-dev */
#ifdef BUILD_EVENTCOMM
- if (event_proto_operations.AutoDevProbe(pInfo))
+ if (!device && event_proto_operations.AutoDevProbe(pInfo))
proto = SYN_PROTO_EVENT;
#endif
}
--
1.7.3.rc1.230.gdf48043
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH synaptic 1/2] config: collect options during preinit
This must be done before SetDeviceAndProtocol to ensure that the "Device" option is set correctly. Signed-off-by: Giuseppe Bilotta --- src/synaptics.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/src/synaptics.c b/src/synaptics.c index eae48d2..89398f5 100644 --- a/src/synaptics.c +++ b/src/synaptics.c @@ -705,6 +705,8 @@ SynapticsPreInit(InputDriverPtr drv, InputInfoPtr pInfo, int flags) pInfo->conversion_proc = ConvertProc; pInfo->private = priv; +xf86CollectInputOptions(pInfo, NULL, NULL); + xf86OptionListReport(pInfo->options); /* allocate now so we don't allocate in the signal handler */ -- 1.7.3.rc1.230.gdf48043 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH synaptic 0/2] config: don't mess with hotplug device assignment
The following two patches make sure that during hotplug the driver will (try to) manage the device it's being assigned, and not what it gets to guess from autoprobe. The second one in particular (which depends on the first one) makes sure that I can plug and unplug my Wacom Pen & Touch tablet without losing functionality on the built-in touchpad of my laptop. Giuseppe Bilotta (2): config: collect options during preinit config: don't autoprobe when device was set src/synaptics.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) -- 1.7.3.rc1.230.gdf48043 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
