[PATCH xinput 5/5] Replace NVIDIA-specific output checking

Peter Hutterer peter.hutterer at who-t.net
Wed Feb 22 17:06:12 PST 2012


On Tue, Feb 21, 2012 at 11:38:00AM -0800, Aaron Plattner wrote:
> On 02/19/2012 07:37 PM, Peter Hutterer wrote:
> >If the binary driver drives at least one screen, the old method did
> >not allow for randr-style screen binding (on the other screen).
> >
> >Change the logic to:
> >- check if the output an randr output
> >- if not, check if the "default" randr output is present and the output name
> >   was "HEAD-n"
> >   - if so, use Xinerama-style mapping
> >
> >This keeps the current behaviour of not allowing Xinerama-style mapping if
> >all outputs are RandR capable.
> 
> It looks like find_output_xrandr only looks at the default screen,
> which means that users need to set DISPLAY=<wherever>.<n> to choose
> the screen number to look for outputs on.
> 
> Maybe it would be a good follow-on change to make it loop over all
> screens, ignoring screens with a single output named "default"?
> That might make it difficult to disambiguate screens that have
> outputs with the same name, though.

well, this is xinput, a little helper app. I'm not sure there's that many
hoops I want to jump through to get it to do something that the desktop
environment should control anyway.

in addition, this is just a convenience wrapper for the transformation
matrix anyway. exotic setups that aren't covered by the current
functionality can still set the matrix manually to the screen proportions
(which is all this command does anyway).

if you want to write the patch, go for it. But I doubt I'll get to it
soon.

> 
> This code allows you to run "xinput map-to-output <dev> default" but
> I think that's okay because it just does nothing.
> 
> >Signed-off-by: Peter Hutterer <peter.hutterer at who-t.net>
> 
> Given the above caveats,
> 
> Reviewed-by: Aaron Plattner <aplattner at nvidia.com>
> Tested-by: Aaron Plattner <aplattner at nvidia.com>
 

thanks.

Cheers,
  Peter

> >---
> >Untested, I don't have this hw configuration available right now.
> >
> >  src/transform.c |   26 +++++++++++++++-----------
> >  1 files changed, 15 insertions(+), 11 deletions(-)
> >
> >diff --git a/src/transform.c b/src/transform.c
> >index 15fda59..f80a592 100644
> >--- a/src/transform.c
> >+++ b/src/transform.c
> >@@ -253,10 +253,9 @@ out:
> >  int
> >  map_to_output(Display *dpy, int argc, char *argv[], char *name, char *desc)
> >  {
> >-    int opcode, event, error;
> >-    int maj, min;
> >      char *output_name;
> >      XIDeviceInfo *info;
> >+    XRROutputInfo *output_info;
> >
> >      if (argc<  2)
> >      {
> >@@ -272,14 +271,19 @@ map_to_output(Display *dpy, int argc, char *argv[], char *name, char *desc)
> >      }
> >
> >      output_name = argv[1];
> >+    output_info = find_output_xrandr(dpy, output_name);
> >+    if (!output_info)
> >+    {
> >+        /* Output doesn't exist. Is this a (partial) non-RandR setup?  */
> >+        output_info = find_output_xrandr(dpy, "default");
> >+        if (output_info)
> >+        {
> >+            XRRFreeOutputInfo(output_info);
> >+            if (strncmp("HEAD-", output_name, strlen("HEAD-")) == 0)
> >+                return map_output_xinerama(dpy, info->deviceid, output_name);
> >+        }
> >+    } else
> >+        XRRFreeOutputInfo(output_info);
> >
> >-    /* Check for RandR 1.2. Server bug causes the NVIDIA driver to
> >-     * report with RandR 1.3 support but it doesn't expose RandR outputs.
> >-     * Force Xinerama if NV-CONTROL is present */
> >-    if (XQueryExtension(dpy, "NV-CONTROL",&opcode,&event,&error) ||
> >-        !XQueryExtension(dpy, "RANDR",&opcode,&event,&error) ||
> >-        !XRRQueryVersion(dpy,&maj,&min) || (maj * 1000 + min)<  1002)
> >-       return map_output_xinerama(dpy, info->deviceid, output_name);
> >-    else
> >-       return map_output_xrandr(dpy, info->deviceid, output_name);
> >+    return map_output_xrandr(dpy, info->deviceid, output_name);
> >  }
> 


More information about the xorg-devel mailing list