[PATCH xserver] randr: Do not check the screen size bound for gpu screens
Timo Aaltonen
tjaalton at ubuntu.com
Thu May 26 08:24:20 UTC 2016
On 26.05.2016 11:21, Nikhil Mahale wrote:
> 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.
It was for whoever reviews these. The server certainly can crash without
the patches with prime setup, according to my tests..
--
t
More information about the xorg-devel
mailing list