[PATCH xserver] randr: Do not check the screen size bound for gpu screens

Nikhil Mahale nmahale at nvidia.com
Thu May 26 08:21:58 UTC 2016


On 05/26/2016 01:31 PM, Timo Aaltonen wrote:
> On 20.05.2016 08:00, Nikhil Mahale wrote:
>> For gpu screen, CrtcSet set/adjust the master screen size along
>> mode in following callstack -
>>
>>   ProcRRSetCrtcConfig()
>>     |
>>     -> RRCrtcSet()
>>         |
>>         -> rrCheckPixmapBounding()
>>             |
>>             -> pScrPriv->rrScreenSetSize()
>>
>> Checking screen size bound for gpus screen cause some configurations
>> to fails, e.g
>>
>>   $ xrandr --output eDP --mode 1920x1080 --pos 0x0 --output HDMI \
>>   --mode 2560x1440 --pos 0x0
>>
>>   Here xrandr utility first sets screen size to 2560x1440 which
>>   gets resized to 1920x1080 on RRSetCrtcConfig request for eDP,
>>   and then RRSetCrtcConfig request for HDMI fails because
>>   of failure of screen bound check.
>>
>> Signed-off-by: Nikhil Mahale <nmahale at nvidia.com>
>
> I've tried to come up with a test that would hang/crash the xserver
> reliably, but failed. It usually takes a number of cycles through
> mirrored/extended/external-only modes, or switching between
> external-only and mirrored. Anyway, the impact is that on intel+nvidia
> hybrid the server can crash or hang or just fail to set the mode without
> these two patches.
>

Sorry Timo, I don't think I understand what you want to say. This patch 
was not intended to fix hang/crash, it simple fixes modeset failure for 
the use cases like I mentioned in description of patch.

The second "[PATCH xserver] randr: Adjust master's last set time with 
slaves" fixes XRandr's client confusion about lastConfigTimes and 
lastSetTime, I seen client was repeatedly sending modeset request 
because each time it gets lastSetTime < lastConfigTime.

Both the patches only impacting prime configurations.

Thanks,
Nikhil Mahale

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------


More information about the xorg-devel mailing list