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.
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.
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. > >
-- 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.