Re: xserver release process
On Tue, 2019-10-08 at 22:19 +0200, Hans de Goede wrote: > Hi, > > On 08-10-2019 18:28, Adam Jackson wrote: > > > In short, releases need to happen, and we have CI, so let's just pop a > > release out on scheduled dates assuming CI passes. > > Given that the Xorg xserver has a lot of hw interaction, we are > never going to catch everything with CI, so this seems a bit > over-simplified. I mean, yes, it's over-simplified. The alternative is not doing releases, apparently. The idea here is that we keep adding more coverage to CI, and we fake hardware coverage if we need to by writing more tooling around vkms and friends. This may mean that any given point-zero release is less stable than we might like, but that's not exactly new, and having cheap-and-frequent stable releases should help mitigate that. > I think it would be good to have 2 things: > > 1. A way to track potential blocker bugs. Note I'm not advocating some > process heavy approach here. The blocker bugs can just be gitlab issues > with a special tag I guess. The idea is that the release-coordinator > at least can get a list of known issues and then decide if those are bad > enough to delay a release or not. Milestones: https://gitlab.freedesktop.org/xorg/xserver/-/milestones - ajax ___ 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: xserver release process
On 10/8/19 1:19 PM, Hans de Goede wrote: Hi, On 08-10-2019 18:28, Adam Jackson wrote: In short, releases need to happen, and we have CI, so let's just pop a release out on scheduled dates assuming CI passes. Given that the Xorg xserver has a lot of hw interaction, we are never going to catch everything with CI, so this seems a bit over-simplified. I think it would be good to have 2 things: 1. A way to track potential blocker bugs. Note I'm not advocating some process heavy approach here. The blocker bugs can just be gitlab issues with a special tag I guess. The idea is that the release-coordinator at least can get a list of known issues and then decide if those are bad enough to delay a release or not. If you have issues or merge requests that need to block a release, please tag them with the appropriate GitLab milestone: https://gitlab.freedesktop.org/xorg/xserver/-/milestones -- Aaron 2. Send out a notice that a new release will happen in say 4 weeks from date of sending with a request for testing + getting any pending *fixes* upstream asao, maybe together with some "beta" or "rc" tarbals, but that is optional. My main reason for suggesting either one is that I personally am aware of at least 2 issues (both related to secondary USB GPUs handling) which are only present in master and not in the 1.20 branch and which I really would like to see fixed before a new release. I have taking a look at these on my to do list, but not at the top of it (yet). Having 1. would help in tracking such known issues, I doubt I'm the only one who has a couple of "I need to look into this and fix it" items on their TODO, so being able to track these would be good. Having 2. would help me bump up these TODOs in priority to try and get them fixed before the release :) 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 ___ 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
Hi, On 09-10-2019 12:23, Pekka Paalanen wrote: On Wed, 9 Oct 2019 09:59:29 +0200 Hans de Goede wrote: Let's keep each other updated, so we don't do duplicate effort. :-) Ack I will drop you a mail when I find / make time to look into this. 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 Wed, 9 Oct 2019 09:59:29 +0200
Hans de Goede wrote:
> Hi Pekka,
>
> On 09-10-2019 09:47, Pekka Paalanen wrote:
> > On Tue, 8 Oct 2019 22:19:45 +0200
> > Hans de Goede wrote:
> >
> >> My main reason for suggesting either one is that I personally am aware
> >> of at least 2 issues (both related to secondary USB GPUs handling) which
> >> are only present in master and not in the 1.20 branch and which I really
> >> would like to see fixed before a new release. I have taking a look at
> >> these on my to do list, but not at the top of it (yet).
> >
> > Hi Hans,
> >
> > it so happens that I am, too, looking at some secondary DRM device
> > hotplug issues. I think I've seen three different things: not enough
> > RandR events to make Mutter take a hotplugged device & output into use,
> > Xorg crash on DRM device hotplug, and failure to start with Xorg USB
> > DRM device plugged in.
> >
> > Do you have any public records of the issues you have on your plate?
>
> No I've not filed issues yet, since I was planning on debugging them
> myself, but if are both seeing these issues then having gitlab
> issues to track them might be a good idea.
>
> I am using a gm12u320 based mini projector (Acer C120) for most of
> my tests, but I believe that this will reproduce with an udl (USB 2 version)
> device too. If necessary I can try to reproduce with an udl device too.
Hi Hans,
I'm working with a Dell DisplayLink dock, USB 3 version, so it's using
the proprietary userspace and the EVDI out-of-tree kernel driver (open
source).
I'd prefer talking about DRM devices or such, because these USB things
do not have a GPU. Having a GPU or not behind a DRM device is sometimes
noteworthy.
> Thinking more about it I'm seeing 3 things:
>
> 1. USB GPU is not seen (not shown in xrandr --list-providers, not usable)
> when present before Xorg is started.
For me, this case seems to stop Xorg from starting:
MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to open evdi (search paths
/usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri)
failed to load driver: evdi
(EE)
Fatal server error:
(EE) AddScreen/ScreenInit failed for gpu driver 0 -1
>
> 2. Hot plugging the USB GPU sometimes causes things to crash shortly
> afterwards.
I've seen this. Looks like a bad pointer, but I couldn't yet figure out
where from. I did get Valgrind to tell me this:
==1843== Invalid free() / delete / delete[] / realloc()
==1843==at 0x483AD4B: realloc (in
/usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==1843==by 0x24BA68: XNFreallocarray (utils.c:1167)
==1843==by 0x26D4F1: xf86SetDepthBpp (xf86Helper.c:558)
==1843==by 0x644DB72: PreInit (driver.c:951)
==1843==by 0x27F3B6: xf86platformAddDevice (xf86platformBus.c:638)
==1843==by 0x29E1F0: NewGPUDeviceRequest (lnx_platform.c:176)
==1843==by 0x2C27FB: device_added (udev.c:140)
==1843==by 0x2C2D9F: socket_handler (udev.c:375)
==1843==by 0x249B40: ospoll_wait (ospoll.c:657)
==1843==by 0x243682: WaitForSomething (WaitFor.c:208)
==1843==by 0x17ADBB: Dispatch (dispatch.c:421)
==1843==by 0x17EFF5: dix_main (main.c:274)
==1843== Address 0x5d982d0 is 0 bytes after an unallocated block of size 0 in
arena "client"
> 3. Hot unplugging the USB GPU always causes a crash shortly
> afterwards.
Unplugging does not happen in my case, because EVDI does not remove the
DRM device. It simply marks the connector as disconnected instead, and
the DRM device is re-used for the next DisplayLink device.
>
> My test environment is xserver master + mutter/gnome-shell 3.34 on
> top of Xorg. Last time I tried downgrading the xserver to 1.20 made all
> 3 issues go away (*)
Good to know. I was debugging a first hotplug issue on
gnome-shell/mutter from git, a revision within the past few weeks.
Xserver was stock Ubuntu 19.04 (1.20.4), but then I wanted to add
prints in it, switched to git master without thinking, and started
seeing these crashes.
> 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.
Knowing that there are regressions in xserver master, I will first
concentrate on my primary issue with the "not enough hotplug events".
Once I have that sorted out, I might be able to help with the other
issues.
Let's keep each other
Re: xserver release process
On 2019-10-08 6:28 p.m., Adam Jackson wrote: I gave a brief lightning talk about this at XDC Montreal [1], and nobody seemed to object, but here's a recap for those who weren't present or have other ideas or preferences. In short, releases need to happen, and we have CI, so let's just pop a release out on scheduled dates assuming CI passes. Six months seems to be a pretty reasonable cadence for xserver major releases as new feature development has tailed off a bit. Likewise for stable branches, if there's been changes to the branch and it's been (say) two weeks since the last release on that branch, and CI passes, automatically do a new release. I intend to make this _entirely_ automatic, with a robot doing the actual commits and release uploads. I like the idea of doing automatic release snapshots / candidates, but I think that's a bit too aggressive for actual releases at this point, at least on the stable branch. E.g. the recent 32-bit ABI breakage on the 1.20 branch would likely have made it into a 1.20.y release with this scheme. Also, let's adopt the Mesa "last two digits of the year" version scheme, it makes it easy to see how old your software is at a glance. We'll need to be slightly careful about this to ensure we don't make the (protocol) release number go crazy, so the scheme looks something like this (underscores for clarity): - xserver 1.20.5 → 1_20_05_000 - xserver 19.0.0 → 1_20_19_000 - xserver 19.0.1 → 1_20_19_001 - xserver 19.1.0 → 1_20_19_100 - xserver 20.0.0 → 1_20_20_000 And then 1_21_*_* as of 21.x.y? Either way, sounds good. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ 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
Hi Pekka, On 09-10-2019 09:47, Pekka Paalanen wrote: On Tue, 8 Oct 2019 22:19:45 +0200 Hans de Goede wrote: My main reason for suggesting either one is that I personally am aware of at least 2 issues (both related to secondary USB GPUs handling) which are only present in master and not in the 1.20 branch and which I really would like to see fixed before a new release. I have taking a look at these on my to do list, but not at the top of it (yet). Hi Hans, it so happens that I am, too, looking at some secondary DRM device hotplug issues. I think I've seen three different things: not enough RandR events to make Mutter take a hotplugged device & output into use, Xorg crash on DRM device hotplug, and failure to start with Xorg USB DRM device plugged in. Do you have any public records of the issues you have on your plate? No I've not filed issues yet, since I was planning on debugging them myself, but if are both seeing these issues then having gitlab issues to track them might be a good idea. I am using a gm12u320 based mini projector (Acer C120) for most of my tests, but I believe that this will reproduce with an udl (USB 2 version) device too. If necessary I can try to reproduce with an udl device too. Thinking more about it I'm seeing 3 things: 1. USB GPU is not seen (not shown in xrandr --list-providers, not usable) when present before Xorg is started. 2. Hot plugging the USB GPU sometimes causes things to crash shortly afterwards. 3. Hot unplugging the USB GPU always causes a crash shortly afterwards. My test environment is xserver master + mutter/gnome-shell 3.34 on top of Xorg. Last time I tried downgrading the xserver to 1.20 made all 3 issues go away (*) 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. Regards, Hans *) Which is why I've not given these bugs a high priority so far ___ 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
USB GPU bugs
On Tue, 8 Oct 2019 22:19:45 +0200 Hans de Goede wrote: > My main reason for suggesting either one is that I personally am aware > of at least 2 issues (both related to secondary USB GPUs handling) which > are only present in master and not in the 1.20 branch and which I really > would like to see fixed before a new release. I have taking a look at > these on my to do list, but not at the top of it (yet). Hi Hans, it so happens that I am, too, looking at some secondary DRM device hotplug issues. I think I've seen three different things: not enough RandR events to make Mutter take a hotplugged device & output into use, Xorg crash on DRM device hotplug, and failure to start with Xorg USB DRM device plugged in. Do you have any public records of the issues you have on your plate? I haven't filed any for mine yet, I'm still trying to untangle them. Thanks, pq pgpxmYWnHbGXE.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
XDC 2019 feedback and comments
Hi all, Once more huge thanks to the entire team from Collabora, for their great work organizing XDC 2019! As usual we're looking for feedback on both XDC itself, and the CFP process and program selection. Both about what was great and should be kept for next year's edition, and where there's room for improvement. The board does keep some notes, for those interested in what we have already: - XDC notes for prospective organizers: https://www.x.org/wiki/Events/RFP/ - CFP notes: https://www.x.org/wiki/Events/PapersCommittee/ If you want to send in your comments in private, please send them to the x.org board. Cheers, Sam signature.asc Description: This is a digitally signed message part ___ 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
