From owner-freebsd-x11@freebsd.org Sun May 29 20:03:30 2016 Return-Path: Delivered-To: freebsd-x11@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 70F3CB54074 for ; Sun, 29 May 2016 20:03:30 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6161312C5; Sun, 29 May 2016 20:03:30 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1464552208189953.5894152602123; Sun, 29 May 2016 13:03:28 -0700 (PDT) Date: Sun, 29 May 2016 13:03:28 -0700 From: Matthew Macy To: =?UTF-8?Q?=22Ren=C3=A9_Ladan=22?= Cc: "freebsd-x11" Message-ID: <154fe1d36eb.dbad06fa506617.2766905574315160021@nextbsd.org> In-Reply-To: References: <154dcac7f27.f5da66a0148247.6294302194451585046@nextbsd.org> <5e9c72c8-eb73-eff6-9d20-03e5bc423ec0@freebsd.org> <154fdf6a252.ded3c290281065.8333167109007661706@nextbsd.org> <154fe0aa212.fc5ef2fe227320.132485229697148150@nextbsd.org> Subject: Re: CFT update day 2 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 20:03:30 -0000 ---- On Sun, 29 May 2016 13:00:10 -0700 Ren=C3=A9 Ladan = wrote ----=20 > On 29-05-16 21:43, Matthew Macy wrote:=20 > > The kernel may be at fault. But my guess is that user and kernel are= =20 > > really supposed to be somewhat in sync. You're running the absolute=20 > > latest kernel bits with a 3 1/2(?) year old user. It's nice that it=20 > > works as well as it does.=20 > Hmm yes, I didn't even realize the userland was that old.=20 > =20 > But isn't there a danger that updating xf86-video-intel also means=20 > updating other bits and pieces of Xorg?=20 > =20 Not a danger, a certainty. Ultimately 4.6 users will need to run an up to = date X. Newer hardware needs newer software. -M > René=20 > > ---- On Sun, 29 May 2016 12:30:23 -0700 René Ladan=20 > > wrote ----=20 > >=20 > > On 29-05-16 21:21, Matthew Macy wrote:=20 > > > It sounds like I just need to make the newer xf86-intel work.=20 > > The old=20 > > > one probably simply isn't able to support newer chips. Thanks=20 > > for the=20 > > > report.=20 > > >=20 > > >=20 > > So it is not something in the kernel module?=20 > >=20 > > (back to the unpatched xf86-video-intel driver for now)=20 > >=20 > > René=20 > > >=20 > > > -M=20 > > >=20 > > >=20 > > >=20 > > > ---- On Sun, 29 May 2016 12:15:47 -0700 René=20 > > Ladan>=20 > > > wrote ----=20 > > >=20 > > > On 29-05-16 18:37, Matthias Haas wrote:=20 > > > > Am 29.05.2016 um 16:51 schrieb René Ladan:=20 > > > >> On 23-05-16 10:12, Matthew Macy wrote:=20 > > > >>> The highlights for today are the following:=20 > > > >>>=20 > > > >>> Bug fixes:=20 > > > >>> - Will Andrews fixed attach for some laptops (such as the=20 > > > Carbon X1).=20 > > > >>> The Carbon X1 has a quirky BIOS that doesn't allow the OS to= =20 > > > >>> enumerate the GPU's interrupt.=20 > > > >>> - Will Andrews identified a conditionally uninitialized=20 > > return in=20 > > > >>> idr_find that could lead to a panic in some cases.=20 > > > >>> - Fixed a panic in mtrr_del frequently seen when attach fail= ed.=20 > > > >>> - Sleep/wakeups with interrupts are largely implemented=20 > > correctly=20 > > > >>> now. Previously a polling 10ms sleep was used. I'm still=20 > > > >>> concerned that the code really needs to be level-triggered.= =20 > > > >>>=20 > > > >>> Cleanups:=20 > > > >>> - Logging is now enabled for the first 10s after attach unle= ss=20 > > > >>> dev.drm.drm_debug_keep=3D1.=20 > > > >>> - Unimplemented warnings are off by default.=20 > > > >>>=20 > > > >> [...snip USB instructions...]=20 > > > >>> If using the github repo, make sure you're using the=20 > > drm-next-4.6=20 > > > >>> branch.=20 > > > >>>=20 > > > >> I tested the latest github version on my laptop (an Acer Aspi= re=20 > > > >> E5-773G-78RN with an Intel HD 520 GPU, see [1]), some results= :=20 > > > >>=20 > > > >> - xfce4 starts, no visual artifacts=20 > > > >> - XV is disabled but present according to xdpyinfo, i.e.=20 > > > mplayer renders=20 > > > >> movies with black borders in full screen mode=20 > > > >> - glxgears gets up to 30 fps full screen (so something is not= =20 > > > >> accelerated)=20 > > > >> - HDMI output works (when X is started after initially pluggi= ng=20 > > > in the=20 > > > >> cable), the TV image keeps getting updated if I close the lid= =20 > > > >> - switching back and forth between X and the console works=20 > > > >> - stellarium works=20 > > > >>=20 > > > >> Maybe xf86-video-intel 2.21.15 is missing an PCI id?=20 > > > > It is indeed missing a few PCI ids, I created 2 patches that a= dd=20 > > > those=20 > > > > missing ids, but that doesn't seem to be enough in my case (Ir= is=20 > > > 550).=20 > > > > You may try them anyway and see if they change anything for yo= u,=20 > > > but I=20 > > > > can't give any support as I'm only a web developer and all thi= s=20 > > > stuff is=20 > > > > not really my area of expertise.=20 > > >=20 > > > With a patched xf86-video-intel the screen freezes and switching= =20 > > > back to=20 > > > the console does not work either. SSH login still works fine.=20 > > > Although=20 > > > Xorg looks frozen, Xorg.log shows that acceleration should work= =20 > > > now, as=20 > > > shown in the attached Xorg.log diff (with timestamps removed). A= =20 > > > kernel=20 > > > log from around the freeze is attached too.=20 > > >=20 > > > This is with the drm-next-4.6 branch at commit=20 > > > 1e9ceda8a2a5b5eb45b3cd692987edc8b410817f=20 > > >=20 > > > >> [1] https://wiki.freebsd.org/Laptops/Acer_Aspire_E5_773G_78RN= =20 > > >=20 > > > Cheers,=20 > > > René=20 > > >=20 > >=20 > =20 >=20