USB GPU bugs

Hans de Goede hdegoede at
Fri Oct 11 22:33:26 UTC 2019


On 11-10-2019 12:13, Pekka Paalanen wrote:
> On Thu, 10 Oct 2019 09:40:30 +0200
> Hans de Goede <hdegoede at> wrote:
>> Hi,
>> On 09-10-2019 12:23, Pekka Paalanen wrote:
>>> On Wed, 9 Oct 2019 09:59:29 +0200
>>> Hans de Goede <hdegoede at> wrote:
>> <snip>
>>>> I think I might also be seeing some variant of your "not enough hotplug
>>>> events" bug. With the gm12u320 projector when hotplugged it is listed
>>>> as "unknown" in gnome's display-settings until I change the settings
>>>> once and then it becomes "Acer" as it should be. I believe that this
>>>> issue is actually also present in the 1.20 branch.
>>> In my case, I see an "add" and three HOTPLUG events via udev when I
>>> hotplug the DisplayLink dock and it creates the DRM device node on the
>>> spot. Mutter receives just one RandR event though, which it deems is
>>> not a hotplug, and looking at the config timestamps I think the event
>>> indeed is reflecting too old state. 'xrandr' will show everything about
>>> the new connector just fine though, IIRC.
>> I just realized I should probably respond to this bit. You see that
>> after "xrandr" everything looks ok, but the "xrandr" command causes
>> a round trip to the kernel and even causes the kernel to re-poll all
>> connectors. Have you tried "xrandr --current" ? That will return the
>> current state stored inside the xserver without re-querying the kernel.
>> Not sure of this helps, but I thought I should mention it.
> Hi Hans,
> that's a good hint. 'xrandr --current' reports the connector as
> connected and with a good looking mode list, when Mutter does not
> autoenable it.
> Does 'xrandr' call into the kernel with drmModeGetConnectorCurrent(),
> or does it really return only what Xorg had internally cached? If it
> calls into kernel, then I'm not surprised it returns the good info,
> since I believe that Xorg is somehow ignoring a udev hotplug event, or
> not realizing that something did still change since the last time it
> sent out RandR events.

AFAIK xrandr without --current calls into the kernel. With --current it
just returns only what Xorg had internally cached.



More information about the xorg-devel mailing list