From owner-freebsd-questions@freebsd.org Wed Apr 22 22:14:40 2020 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8D2FB2C4601; Wed, 22 Apr 2020 22:14:40 +0000 (UTC) (envelope-from chardon.frederic@gmail.com) Received: from mail-il1-x142.google.com (mail-il1-x142.google.com [IPv6:2607:f8b0:4864:20::142]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 496vqh1lV0z43dT; Wed, 22 Apr 2020 22:14:39 +0000 (UTC) (envelope-from chardon.frederic@gmail.com) Received: by mail-il1-x142.google.com with SMTP id i16so3602283ils.12; Wed, 22 Apr 2020 15:14:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=jE+dL3RlSoJvp/TDoMxbEI5Yvzgoq0rBAxuV6f6p4IY=; b=B2WW76jbR6Vb4/zdEoJe6Sscew/uA1mIscqllSfqmiA1hsPmA7SlZNPLV6eA0D2/sD ttLXEK4E8dPzINiQouNQ28zbkEbhHygJQVgIm44zpPdLQkyfWNnd0S08OAmfLHhxg+72 EfiwFdnmaNU+TYLhl+Vxn//FT93e/Dc+nkn63YWA8gPND73tXjjZlXfhh0aBEbjB7RUJ 6+i1NPAeFKrmdqF9Y2G1QsxCbFlOzvUPENI7FV6YIRunm1tZ9boJDkCcuRyy9NFkkv6Z 0F56va7GbRtAA8O5Uvl+YjQgAwrumubJQOtuFtYFGRXhvJOP/e9u/Nh0WlxjyHpIfGAA yzvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=jE+dL3RlSoJvp/TDoMxbEI5Yvzgoq0rBAxuV6f6p4IY=; b=JTVOnIBgoEHMPVC5GfIysc+kLEaAaeM5smdVTIeY0rPPrgz6lolckYkYXA7H9hOm6j ZP9l5ggFHRv3UjKwUCSiXTxm1IoWdKy19tizE6xkqfo5CRdpT2oeKPOEbv2xqL27sBZ4 HR0Zi7JvEjgcfOZbxmWkuq8FCyEwIQDx1wrxGwKq2seS4hgnLyyGN3qE79SiX1nPvJ11 nxtC0PgDlLass5HX/OUxhLyBAl2NbEDHrWEg9SMvYPNynJ0KSj5q6BI53KRYKpsTB9Sc U/gDQtFPdOPG8lSCy7ywokmX7fAmbzkKtqPfIoZ+uVPd8RKDWPuiTNil0gsIrFcZZArB JBgA== X-Gm-Message-State: AGi0Pua70vDCIO4TrlLAYCdjgCslkG52dS22Xjef2MqT0Z4u4+ZzLfrX I/9G5I5u/72E+U0DKe9KQ1aSg94FD6eRoXnIINUgBeFN0+g= X-Google-Smtp-Source: APiQypLbh7N9uVa/NCI8pUZLPYpH3ozkBflagZGNz5buAmxrDUbQMYcp5NSBm5U4cVpdz53Hkn2182SfBouSmZX9WYY= X-Received: by 2002:a92:ce08:: with SMTP id b8mr619098ilo.69.1587593678696; Wed, 22 Apr 2020 15:14:38 -0700 (PDT) MIME-Version: 1.0 References: <6c7abdcf-aeef-4af4-b8f4-9d7fd0e45cf0@localhost> <7fba319c-c012-8893-3ce0-e2a166c38d2d@daemonic.se> In-Reply-To: From: Frederic Chardon Date: Thu, 23 Apr 2020 00:14:26 +0200 Message-ID: Subject: Re: Wayland on FreeBSD To: Jan Beich Cc: Niclas Zeising , freebsd-x11@freebsd.org, FreeBSD Questions Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 496vqh1lV0z43dT X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; TAGGED_RCPT(0.00)[freebsd]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 22:14:40 -0000 Le mer. 22 avr. 2020 =C3=A0 16:51, Jan Beich a =C3=A9c= rit : > > Frederic Chardon writes: > > > Le lun. 20 avr. 2020 =C3=A0 23:06, Jan Beich a =C3= =A9crit : > > > >> > >> Frederic Chardon writes: > >> > >> > > >> > The trace shows usage of llvmpipe after the failed ioctl on > >> > /dev/dri/card0, so as I understand the lack of hardware acceleration > >> > concerns only Xwayland, whereas wayland itself is accelerated ? > >> > >> Yep. Check which ioctls fail then try to reproduce outside of Mesa or > >> hardcode the result. Overriding PCI ID via INTEL_DEVID_OVERRIDE is > >> unlikely to help e.g., > > > > All below failure occurs only in xwayland, X11 and wayland succeed. > > > > The first failure is with I915_PARAM_CHIPSET_ID. When I hardcode the > > correct ID I get a failure with I915_PARAM_HAS_RELAXED_DATA. When I > > force the result to be true (as with X11 and Wayland), the ioctl > > DRM_I915_GEM_EXECBUFFER2_WR fails with errno EPERM. > > Thanks for investigating. Maybe either DRM_AUTH or DRM_RENDER_ALLOW fails= . > Does setuid bit on Xwayland binary help? Yes, hardware acceleration works. eglinfo still complain about invalid 0xffffffff PCI ID though > Does disabling render node help > e.g., chmod 0000 /dev/dri/renderD128 ? No What helps however is to mount the different linux filesystems after i915kms is loaded. eg I added "late" keyword to fstab as below devfs /compat/linux/dev devfs rw,late 0 0 fdesc /compat/linux/dev/fd fdescfs rw,late,linrdlnk 0 0 linproc /compat/linux/proc linprocfs rw,late 0 0 linsys /compat/linux/sys linsysfs rw,late 0 0 without the late keyword, acceleration works if devfs alone is mounted. any other fs (with or without devfs) makes Xwayland use software rendering. As with setuid Xwayland, eglinfo complains about invalid PCI ID. > > Can you check major number is the same for primary and render nodes? > Also check if render node device type is correct in case something > like https://github.com/intel/libva/pull/292 affects Mesa. > > $ ls -lL /dev/dri > total 0 > crw-rw---- 1 root video 0x25b Apr 22 13:04 card0 > crw-rw---- 1 root video 0x2db Apr 22 13:04 renderD128 > > # Based on major() from /usr/include/sys/types.h > $ echo $(( (((0x25b >> 32) & 0xffffff00) | ((0x25b >> 8) & 0xff)) )) > 2 > $ echo $(( (((0x2db >> 32) & 0xffffff00) | ((0x2db >> 8) & 0xff)) )) > 2 > > # Based on drmGetMinorBase() from graphics/libdrm > $ echo $(( 0x2db & 0x80 )) > 128 In my case card0 has major 0 and renderD128 major 1 Bit 0x80 is sometimes set, sometimes not, but I couln't find a pattern (it doesn't seem to affect whether hardware rendering is used or not) > > Should I open an issue on drm-kms github? Or it is more likely a > > problem on mesa side? > > In kms-drm but before that try pending updates just in case: > > https://github.com/FreeBSDDesktop/kms-drm/pull/217 > https://github.com/FreeBSDDesktop/kms-drm/pull/221 # maybe unstable No impact, hardware acceleration is enabled or not solely based on the mounting of linuxulator pseudofs. > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D235570 > https://github.com/myfreeweb/freebsd-ports-dank/tree/lite/graphics/mesa-d= ev > > > >> https://lists.freebsd.org/pipermail/freebsd-x11/2019-January/022551.ht= ml > >> > >> If you still have no clue try playing with sysctls under compat.linuxk= pi > >> via /boot/loader.conf. > > > > Any hints which ones are worth a try? How did you solve your issue (as > > it seems to be pretty similar). > > Disappeared on its own. In bug 241821 for some time I could reliably > reproduce but not anymore. The issue seems to be vaguely related to the > order hardware is initialized during boot. Unfortunately, bug 241821 > didn't document "ls -lL /dev/dri" output but on the mailing list > /dev/dri/renderD128 didn't have 0x80 bit set. Thanks Jan!