Bug 93354

Summary: fixes to allow use of xrandr for setprovideroutputsource type configs
Product: xorg Reporter: guy goode <good1.2guy>
Component: Server/GeneralAssignee: Xorg Project Team <xorg-team>
Status: RESOLVED MOVED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: peter
Version: unspecified   
Hardware: All   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
tarball of patches and related data
none
attachment-31088-0.html none

Description guy goode 2015-12-11 18:52:33 UTC
Created attachment 120467 [details]
tarball of patches and related data

Recent mods to X server can cause xrandr --setprovideroutputsource to be
lost due to dispatchException. This command is used to configure a gpu/master type config.  This mod corrects a few minor bugs, and creates a work-around for the use of xrandr setprovideroutputsource.

This change was submitted to NVIDIA, but they have indicated it is low priority, and so I thought maybe it would be worth a try here.

The attachment contains:
==== x.patch
fix to rrprovider.c
  missing "if" guarding a swapl in ProcRRGetProviderInfo
fix to rrmonitor.c
  use list version of crtc set, since "c" is an index to mon_list. 
==== y.patch
add --retain parameter to xrand
  the effect of setprovideroutputsource (et. al.) are lost in the current implementation since a dispatchException is created by the use of these commands.  The exception causes a server generation cycle to be executed, which reloads the config from conf.  This deletes the effect of the desired config change.  The patch does not address that conf no longer agrees with config, and that any dispatchException will reverse all accumualated xrandr config updates.

==== xinitrc
example .xinitrc when using this kind of config

This mod was tested on an HP Envy model 17t-n000 laptop, which uses an intel/nvidia design, but it applies to any config which uses this style of configuration, that is: xrandr generated master/gpus via setprovideroutputsource.
Comment 1 Peter Wu 2016-06-05 12:24:13 UTC
Not a dev, but your chances of getting this merged will increase if you do not put your patches in a tarball but send them to the xorg-devel list with an appropriate commit message.

Based on the indentation, the xrrprovider.c change in x.patch seems reasonable, it handles clients which use a different byte order. No idea about the rrmonitor.c changes though.

About y.patch, as a user I read the manual page and still have no idea what the "--retain" option does.
Comment 2 guy goode 2016-06-05 16:34:03 UTC
Created attachment 124334 [details]
attachment-31088-0.html

This patch was originally intended to support a form of gpu output source
provider which made my hp envy laptop work with 950 nvidia/intel ramdac
type graphics design.  Since then, there have been patches made to
render/xrandr and I am not interested in porting the design forwards.  HP
and NVIDIA are the beneficiary of this patch, and they did not seem
interested in even looking.  Today, to use this device you must fallback to
just the intel ramdac, and lose the gpu entirely.  too bad.

but thanks for looking.  your the first person to even look.

incidentally, the --retain option repairs a problem where the update is
applied in the server, and then immediately replaced with the default
config, which removes the effect of the xrandr reconfig.  --retain causes
the change to stick, and therefore be effective.

Like I said, this change is of low value since HP / NVIDIA support is not
interested in it.



On Sun, Jun 5, 2016 at 6:24 AM, <bugzilla-daemon@freedesktop.org> wrote:

> Peter Wu <peter@lekensteyn.nl> changed bug 93354
> <https://bugs.freedesktop.org/show_bug.cgi?id=93354>
> What Removed Added
> CC   peter@lekensteyn.nl
>
> *Comment # 1 <https://bugs.freedesktop.org/show_bug.cgi?id=93354#c1> on
> bug 93354 <https://bugs.freedesktop.org/show_bug.cgi?id=93354> from Peter
> Wu <peter@lekensteyn.nl> *
>
> Not a dev, but your chances of getting this merged will increase if you do not
> put your patches in a tarball but send them to the xorg-devel list with an
> appropriate commit message.
>
> Based on the indentation, the xrrprovider.c change in x.patch seems reasonable,
> it handles clients which use a different byte order. No idea about the
> rrmonitor.c changes though.
>
> About y.patch, as a user I read the manual page and still have no idea what the
> "--retain" option does.
>
> ------------------------------
> You are receiving this mail because:
>
>    - You reported the bug.
>
>
Comment 3 GitLab Migration User 2018-12-13 22:34:56 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/493.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.