CFT update day 2

[Matthew Macy]

 ---- On Sun, 29 May 2016 13:00:10 -0700 René Ladan <rene at freebsd.org> wrote ---- 
 > On 29-05-16 21:43, Matthew Macy wrote: 
 > > The kernel may be at fault. But my guess is that user and kernel are 
 > > really supposed to be somewhat in sync. You're running the absolute 
 > > latest kernel bits with a 3 1/2(?) year old user. It's nice that it 
 > > works as well as it does. 
 > Hmm yes, I didn't even realize the userland was that old. 
 >  
 > But isn't there a danger that updating xf86-video-intel also means 
 > updating other bits and pieces of Xorg? 
 >  

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é 
 > > ---- On Sun, 29 May 2016 12:30:23 -0700 René Ladan<rene at freebsd.org> 
 > > wrote ---- 
 > > 
 > >     On 29-05-16 21:21, Matthew Macy wrote: 
 > >     > It sounds like I just need to make the newer xf86-intel work. 
 > >     The old 
 > >     > one probably simply isn't able to support newer chips. Thanks 
 > >     for the 
 > >     > report. 
 > >     > 
 > >     > 
 > >     So it is not something in the kernel module? 
 > > 
 > >     (back to the unpatched xf86-video-intel driver for now) 
 > > 
 > >     René 
 > >     > 
 > >     > -M 
 > >     > 
 > >     > 
 > >     > 
 > >     > ---- On Sun, 29 May 2016 12:15:47 -0700 René 
 > >     Ladan<rene at freebsd.org <mailto:rene at freebsd.org>> 
 > >     > wrote ---- 
 > >     > 
 > >     > On 29-05-16 18:37, Matthias Haas wrote: 
 > >     > > Am 29.05.2016 um 16:51 schrieb René Ladan: 
 > >     > >> On 23-05-16 10:12, Matthew Macy wrote: 
 > >     > >>> The highlights for today are the following: 
 > >     > >>> 
 > >     > >>> Bug fixes: 
 > >     > >>> - Will Andrews fixed attach for some laptops (such as the 
 > >     > Carbon X1). 
 > >     > >>> The Carbon X1 has a quirky BIOS that doesn't allow the OS to 
 > >     > >>> enumerate the GPU's interrupt. 
 > >     > >>> - Will Andrews identified a conditionally uninitialized 
 > >     return in 
 > >     > >>> idr_find that could lead to a panic in some cases. 
 > >     > >>> - Fixed a panic in mtrr_del frequently seen when attach failed. 
 > >     > >>> - Sleep/wakeups with interrupts are largely implemented 
 > >     correctly 
 > >     > >>> now. Previously a polling 10ms sleep was used. I'm still 
 > >     > >>> concerned that the code really needs to be level-triggered. 
 > >     > >>> 
 > >     > >>> Cleanups: 
 > >     > >>> - Logging is now enabled for the first 10s after attach unless 
 > >     > >>> dev.drm.drm_debug_keep=1. 
 > >     > >>> - Unimplemented warnings are off by default. 
 > >     > >>> 
 > >     > >> [...snip USB instructions...] 
 > >     > >>> If using the github repo, make sure you're using the 
 > >     drm-next-4.6 
 > >     > >>> branch. 
 > >     > >>> 
 > >     > >> I tested the latest github version on my laptop (an Acer Aspire 
 > >     > >> E5-773G-78RN with an Intel HD 520 GPU, see [1]), some results: 
 > >     > >> 
 > >     > >> - xfce4 starts, no visual artifacts 
 > >     > >> - XV is disabled but present according to xdpyinfo, i.e. 
 > >     > mplayer renders 
 > >     > >> movies with black borders in full screen mode 
 > >     > >> - glxgears gets up to 30 fps full screen (so something is not 
 > >     > >> accelerated) 
 > >     > >> - HDMI output works (when X is started after initially plugging 
 > >     > in the 
 > >     > >> cable), the TV image keeps getting updated if I close the lid 
 > >     > >> - switching back and forth between X and the console works 
 > >     > >> - stellarium works 
 > >     > >> 
 > >     > >> Maybe xf86-video-intel 2.21.15 is missing an PCI id? 
 > >     > > It is indeed missing a few PCI ids, I created 2 patches that add 
 > >     > those 
 > >     > > missing ids, but that doesn't seem to be enough in my case (Iris 
 > >     > 550). 
 > >     > > You may try them anyway and see if they change anything for you, 
 > >     > but I 
 > >     > > can't give any support as I'm only a web developer and all this 
 > >     > stuff is 
 > >     > > not really my area of expertise. 
 > >     > 
 > >     > With a patched xf86-video-intel the screen freezes and switching 
 > >     > back to 
 > >     > the console does not work either. SSH login still works fine. 
 > >     > Although 
 > >     > Xorg looks frozen, Xorg.log shows that acceleration should work 
 > >     > now, as 
 > >     > shown in the attached Xorg.log diff (with timestamps removed). A 
 > >     > kernel 
 > >     > log from around the freeze is attached too. 
 > >     > 
 > >     > This is with the drm-next-4.6 branch at commit 
 > >     > 1e9ceda8a2a5b5eb45b3cd692987edc8b410817f 
 > >     > 
 > >     > >> [1] https://wiki.freebsd.org/Laptops/Acer_Aspire_E5_773G_78RN 
 > >     > 
 > >     > Cheers, 
 > >     > René 
 > >     > 
 > > 
 >  
 >