Re: gitlab merge requests are (mostly) enabled
On Mon, 2018-09-10 at 10:28 -0400, Adam Jackson wrote: > If you haven't logged into patchwork yet and turned on notifications ^ Erk, that should say gitlab not patchwork. - 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
gitlab merge requests are (mostly) enabled
I've turned merge requests on for most modules. I haven't done the drivers yet (hopefully by the end of the day), and will continue to leave them disabled for the drivers whose maintainers have asked they be left disabled. In particular, merge requests are enabled for xserver now, and that's how I'll be managing the merges I do. If you've forked xserver in gitlab and push to your repo, you'll see a link to create a merge request for that branch, like so: remote: To create a merge request for patchwork-246007, visit: remote: https://gitlab.freedesktop.org/ajax/xserver/merge_requests/new?merge_request%5Bsource_branch%5D=patchwork-246007 remote: To gitlab.freedesktop.org:ajax/xserver.git * [new branch]patchwork-246007 -> patchwork-246007 This has the advantage of running the CI pipeline automatically. I strongly encourage others to use the MR workflow as much as possible. I make no promises about patches sent only to the mailing list, and any such that I do pay attention to will be proxied into merge requests (as above). If you haven't logged into patchwork yet and turned on notifications for the modules and groups you're interested in, now would be a good time to do that. - 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: [Pixman] [BUG] SIGSEGV in sse2_fill
On 2018-09-10 12:01 p.m., Frédéric Fauberteau wrote: > Le 2018-09-10 09:26, Michel Dänzer a écrit : >> On 2018-09-10 8:22 a.m., Frédéric Fauberteau wrote: >>> Le 2018-09-01 15:16, Michel Dänzer a écrit : On 2018-09-01 9:22 a.m., Frédéric Fauberteau wrote: > > [ 5770.134] (EE) RADEON(0): Failed to make prime FD for handle: 22 > [ 5770.134] (EE) RADEON(0): Failed to create textured screen. This is the problem. Please try current xf86-video-ati Git master, specifically https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/commit/db28d35ce9fd07a2a4703f3df0633d4c8291ff9b could help for this. >>> >>> I just tested this commit and xorg server now starts without >>> segfaulting. >>> >>> I am from a remote host and I don't know if the display is correct. But >>> the log file shows an error: >>> >>> [688070.735] (II) Initializing extension DRI2 >>> [688070.737] (II) RADEON(0): Setting screen physical size to 783 x 277 >>> [688070.923] failed to add FB for modeset >>> [688070.923] (WW) RADEON(0): Failed to set mode on CRTC 0 >>> [688070.954] failed to add FB for modeset >>> [688070.954] (WW) RADEON(0): Failed to set mode on CRTC 1 >>> [688070.955] (EE) RADEON(0): Failed to enable any CRTC >> >> Please try the Git master branch, which will soon become the 18.1 >> release. If there's still a problem with that, please provide the >> corresponding full Xorg log file. > > Please find the Xorg.0.log produced after upgrading the driver to > de88ea2755611bdcb18d91d8234d2ab5be8ff2e9: Thanks, the rest of the log file looks fine. The above warning and error messages indicate that drmModeAddFB fails. Since you got the "Failed to make prime FD for handle" error message from glamor with the 18.0.1 driver, there might still be an issue related to the GEM handle of the front buffer. I've never seen this before, so I suspect it could be an issue specific to NetBSD's KMS support. Can you poke around a bit to see why drmModeAddFB fails? E.g., what are the parameters passed to it by radeon_fb_create, and what error does it return? -- Earthling Michel Dänzer | http://www.amd.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: [Pixman] [BUG] SIGSEGV in sse2_fill
Le 2018-09-10 09:26, Michel Dänzer a écrit : On 2018-09-10 8:22 a.m., Frédéric Fauberteau wrote: Le 2018-09-01 15:16, Michel Dänzer a écrit : On 2018-09-01 9:22 a.m., Frédéric Fauberteau wrote: [ 5770.134] (EE) RADEON(0): Failed to make prime FD for handle: 22 [ 5770.134] (EE) RADEON(0): Failed to create textured screen. This is the problem. Please try current xf86-video-ati Git master, specifically https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/commit/db28d35ce9fd07a2a4703f3df0633d4c8291ff9b could help for this. I just tested this commit and xorg server now starts without segfaulting. I am from a remote host and I don't know if the display is correct. But the log file shows an error: [688070.735] (II) Initializing extension DRI2 [688070.737] (II) RADEON(0): Setting screen physical size to 783 x 277 [688070.923] failed to add FB for modeset [688070.923] (WW) RADEON(0): Failed to set mode on CRTC 0 [688070.954] failed to add FB for modeset [688070.954] (WW) RADEON(0): Failed to set mode on CRTC 1 [688070.955] (EE) RADEON(0): Failed to enable any CRTC Please try the Git master branch, which will soon become the 18.1 release. If there's still a problem with that, please provide the corresponding full Xorg log file. Please find the Xorg.0.log produced after upgrading the driver to de88ea2755611bdcb18d91d8234d2ab5be8ff2e9: [701577.138] X.Org X Server 1.20.0 X Protocol Version 11, Revision 0 [701577.138] Build Operating System: NetBSD-8.0-x86_64 The NetBSD Foundation [701577.138] Current Operating System: NetBSD hydralisk 8.0 NetBSD 8.0 (HYDRALISK) #6: Sat Sep 1 17:09:53 CEST 2018 root@hydralisk:/usr/obj/sys/arch/amd64/compile/HYDRALISK amd64 [701577.138] Build Date: 30 August 2018 05:39:00AM [701577.138] [701577.138] Current version of pixman: 0.34.0 [701577.138]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [701577.138] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [701577.138] (==) Log file: "/var/log/Xorg.0.log", Time: Mon Sep 10 11:54:35 2018 [701577.139] (==) Using config file: "/etc/xorg.conf" [701577.139] (==) Using system config directory "/usr/pkg/share/X11/xorg.conf.d" [701577.139] (==) No Layout section. Using the first Screen section. [701577.139] (==) No screen section available. Using defaults. [701577.139] (**) |-->Screen "Default Screen Section" (0) [701577.139] (**) | |-->Monitor "" [701577.139] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [701577.139] (==) Not automatically adding devices [701577.139] (==) Not automatically enabling devices [701577.139] (==) Not automatically adding GPU devices [701577.139] (==) Max clients allowed: 256, resource mask: 0x1f [701577.139] (WW) The directory "/usr/local/pkg/share/fonts/X11/100dpi" does not exist. [701577.139]Entry deleted from font path. [701577.139] (WW) The directory "/usr/local/pkg/share/fonts/X11/75dpi" does not exist. [701577.139]Entry deleted from font path. [701577.139] (WW) The directory "/usr/local/pkg/share/fonts/X11/misc" does not exist. [701577.139]Entry deleted from font path. [701577.139] (WW) The directory "/usr/local/pkg/share/fonts/X11/TTF" does not exist. [701577.139]Entry deleted from font path. [701577.139] (WW) The directory "/usr/local/pkg/share/fonts/X11/Type1" does not exist. [701577.139]Entry deleted from font path. [701577.139] (WW) The directory "/usr/local/pkg/share/fonts/X11/cyrillic" does not exist. [701577.139]Entry deleted from font path. [701577.139] (WW) The directory "/usr/local/pkg/share/fonts/X11/misc" does not exist. [701577.139]Entry deleted from font path. [701577.139] (WW) The directory "/usr/pkg/share/fonts/X11/OTF" does not exist. [701577.139]Entry deleted from font path. [701577.140] (WW) The directory "/usr/pkg/lib/X11/fonts/misc" does not exist. [701577.140]Entry deleted from font path. [701577.140] (WW) The directory "/usr/pkg/lib/X11/fonts/TTF" does not exist. [701577.140]Entry deleted from font path. [701577.140] (WW) The directory "/usr/pkg/lib/X11/fonts/OTF" does not exist. [701577.140]Entry deleted from font path. [701577.140] (WW) The directory "/usr/pkg/lib/X11/fonts/Type1" does not exist. [701577.140]Entry deleted from font path. [701577.140] (WW) The directory "/usr/pkg/lib/X11/fonts/100dpi" does not exist. [701577.140]Entry deleted from font path. [701577.140] (WW) The directory "/usr/pkg/lib/X11/fonts/75dpi" does not exist. [701577.140]Entry deleted from font path. [701577.140] (WW) The directory "/usr/pkg/lib/X11/fonts/cyrillic" does not exist. [701577.140]Entry deleted from font path. [701577.140] (**) FontPath set to: /usr/pkg/share/fonts/X11/misc,
Re: WebKit failing to find GLXFBConfig, confusion around fbconfigs + swrast
On Fri, Sep 7, 2018 at 7:05 AM, Jasper St. Pierre wrote: > So this is a fun question and took me a day or two of random spelunking. > Let's start with the last question, since it gives us a good starting point: > why are the PCI IDs necessary? > > The answer is "DRI2 needs to figure out the driver to load if the user > doesn't pass it into DRI2Connect". > https://gitlab.freedesktop.org/xorg/xserver/blob/master/hw/xfree86/dri2/dri2.c#L1440 Thanks Jasper. Highly informative as usual! > Let's now ask and answer two more follow-up questions: 1. Why is the server > using DRI2, 2. Why does the server need the driver name, and 3. Why doesn't > mesa pass the driver name along? > > My best guess for why DRI2 is being used is that xf86-video-intel turns it > off by default, because ickle didn't like the implicit synchronization that > DRI3 had and refused to fix some bugs in it. So if you load > xf86-video-intel, unless you configure it to turn on DRI3, you get DRI2. > Yay. > > As for why mesa doesn't pass the driver name along, the answer just is that > it doesn't. Maybe it should? > https://github.com/mesa3d/mesa/blob/bd963f84302adb563136712c371023f15dadbea7/src/glx/dri2_glx.c#L1196 > > DRI3 works a bit differently -- an FD is passed to the X server by mesa, and > the DDX figures out how to interpret that FD. The full flow in rootless X is > that logind picks an FD, passes that to the X server, and then the DDX > driver (likely -modesetting) calls drmGetDeviceNameFromFd2, and all the > logic is encapsulated in libdrm and mesa. But the generic DRI2 doesn't have > an FD, really, so you have to get something. I really appreciate all the info and explanations. This part (pass driver name and/or switch to DRI3) looks like it may be the most easily actionable improvement that could be made, I'll look into it as time permits. Daniel ___ 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: [Pixman] [BUG] SIGSEGV in sse2_fill
On 2018-09-10 8:22 a.m., Frédéric Fauberteau wrote: > Le 2018-09-01 15:16, Michel Dänzer a écrit : >> On 2018-09-01 9:22 a.m., Frédéric Fauberteau wrote: >>> >>> [ 5770.134] (EE) RADEON(0): Failed to make prime FD for handle: 22 >>> [ 5770.134] (EE) RADEON(0): Failed to create textured screen. >> >> This is the problem. Please try current xf86-video-ati Git master, >> specifically >> https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/commit/db28d35ce9fd07a2a4703f3df0633d4c8291ff9b >> >> could help for this. > > I just tested this commit and xorg server now starts without segfaulting. > > I am from a remote host and I don't know if the display is correct. But > the log file shows an error: > > [688070.735] (II) Initializing extension DRI2 > [688070.737] (II) RADEON(0): Setting screen physical size to 783 x 277 > [688070.923] failed to add FB for modeset > [688070.923] (WW) RADEON(0): Failed to set mode on CRTC 0 > [688070.954] failed to add FB for modeset > [688070.954] (WW) RADEON(0): Failed to set mode on CRTC 1 > [688070.955] (EE) RADEON(0): Failed to enable any CRTC Please try the Git master branch, which will soon become the 18.1 release. If there's still a problem with that, please provide the corresponding full Xorg log file. -- Earthling Michel Dänzer | http://www.amd.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
Xorg doesn't like sending damage events for some reason
Hi, Recently, some users of compton[1] has noticed a bug, where the contents of windows will freeze while there are indeed updates happening (e.g. when viewing a video, the video will freeze while the sound is still playing). For more background, please see[2]. So I tried to look into this problem. Internally, compton uses the damage event to track if the screen needs updating. Essentially, when a new window is created, XDamageCreate is called to get damage events (DamageReportNonEmpty), then compton sits in a select() loop, and process damage events accordingly. Every time a damage notify is received, DamageSubtract is called to clear the damage, and the screen is repainted. The problem is, some time, the select() will just not return, even when contents of some windows are clearly been updated. Usually if some other event happens when this is going on, select() will return, and XNextEvent() will return the other event, and the damage notify event. So looks like the damage event is not lost, and is probably just stuck in some queue somewhere. Also, this problem seems to be heavily timing dependent. I haven't been able to reproduce this problem when running compton under strace. Right now I'm working around this problem by using DamageReportRawRectangles, which seems to work. If you have any idea where the problem could be, please help. Thanks. [1]: https://github.com/chjj/compton [2]: https://github.com/chjj/compton/issues/494 -- Regards Yuxuan Shui ___ 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: [Pixman] [BUG] SIGSEGV in sse2_fill
Le 2018-09-01 15:16, Michel Dänzer a écrit : On 2018-09-01 9:22 a.m., Frédéric Fauberteau wrote: [ 5770.134] (EE) RADEON(0): Failed to make prime FD for handle: 22 [ 5770.134] (EE) RADEON(0): Failed to create textured screen. This is the problem. Please try current xf86-video-ati Git master, specifically https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/commit/db28d35ce9fd07a2a4703f3df0633d4c8291ff9b could help for this. I just tested this commit and xorg server now starts without segfaulting. I am from a remote host and I don't know if the display is correct. But the log file shows an error: [688070.735] (II) Initializing extension DRI2 [688070.737] (II) RADEON(0): Setting screen physical size to 783 x 277 [688070.923] failed to add FB for modeset [688070.923] (WW) RADEON(0): Failed to set mode on CRTC 0 [688070.954] failed to add FB for modeset [688070.954] (WW) RADEON(0): Failed to set mode on CRTC 1 [688070.955] (EE) RADEON(0): Failed to enable any CRTC I will give a feedback as soon as I can have a look at the screen. ___ 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
