Re: USB GPU bugs
Hi, On 11-10-2019 12:13, Pekka Paalanen wrote: On Thu, 10 Oct 2019 09:40:30 +0200 Hans de Goede wrote: Hi, On 09-10-2019 12:23, Pekka Paalanen wrote: On Wed, 9 Oct 2019 09:59:29 +0200 Hans de Goede wrote: 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. Regards, Hans ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: USB GPU bugs
On Thu, 10 Oct 2019 09:40:30 +0200 Hans de Goede wrote: > Hi, > > On 09-10-2019 12:23, Pekka Paalanen wrote: > > On Wed, 9 Oct 2019 09:59:29 +0200 > > Hans de Goede wrote: > > > > >> 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. I finally created an upstream issue for this one: https://gitlab.freedesktop.org/xorg/xserver/issues/909 I'll continue staring at it next week. Thanks, pq pgpgI81IODQxD.pgp Description: OpenPGP digital signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
