Re: CFT update day 2

 ---- On Mon, 23 May 2016 14:30:51 -0700 Matthias Haas <freebsd-x11_at_mathaas.de> wrote ---- 
 > That was the first thing I tried, but it's too old to even recognize the  
 > gpu, I guess there are only some pci ids or something similar missing, I  
 > may try patching them in tomorrow if I can find out what exactly is  
 > missing. 
 

Try working with the ports people. The module load and missing pciids are a ports problem. The outputs not working and visual artifacts are mine.

-M


 > On 2016-05-23 23:21, Matthew Macy wrote: 
 > > Have you tried with the xf86-intel in ports. That actually works 
 > > better for most. Also try SNA. What does pciconf -lvbc show for 
 > > graphics? 
 > >  
 > > ---- On Mon, 23 May 2016 14:17:41 -0700 Matthias 
 > > Haas<freebsd-x11_at_mathaas.de> wrote ---- 
 > >  
 > >> First of all thanks for your great work so far. 
 > >>  
 > >> I have tried the driver on my notebook with Iris 550. 
 > >> After patching libdrm with 
 > >>  
 > > https://cgit.freedesktop.org/mesa/drm/commit/?id=e3623d34cad0ac3f181b0deee0931df202b8f909 
 > >> [1] 
 > >> and installing the experimental xf86-video-intel driver it is 
 > >> partially 
 > >> working. 
 > >> What's not working is: 
 > >> - 3D-acceleration 
 > >> - multi-monitor support (only tried with hdmi), after loading the 
 > >> i915kms driver the output is duplicated, but there is no way of 
 > >> controlling the outputs independently (xfce also shows only one 
 > >> connected display) 
 > >> - Xorg refuses to start unless I kldload i915kms manually before 
 > >> trying 
 > >> to start Xorg 
 > >> - there are some rendering issues (pink lines, weird transparency 
 > >> where 
 > >> there should be no transparency), but I don't know if these are 
 > >> related 
 > >> to i915, the experimental xf86-video-intel driver or the software 
 > >> renderer 
 > >>  
 > >> On 2016-05-23 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. 
 > >>>  
 > >>> As of this moment the latest USB image is: 
 > >>> http://www.bsddesktop.com/images/cftdisk_2016052307.img.xz [2] 
 > >>>  
 > >>> The USB image now has sync disabled on var. This should improve 
 > >>> responsiveness for most people with slow USB pen drives. If 
 > >>> you're having issues that require retaining logs you'll need 
 > >>> to "zfs set sync=enabled zrootusb/var". 
 > >>>  
 > >>> The USB image now includes kde4 and xfce. It is also much larger, 
 > >> for 
 > >>> this iteration you will need a 16GB USB key. The next one will 
 > >> probably 
 > >>> not be quite so large. If size is a common problem let me know. 
 > >> It's 
 > >>> difficult to buy a USB key that is less than 16GB today. 
 > >>>  
 > >>> joeuser's .xinitrc is configured to start xfce with startx. To 
 > >> start 
 > >>> kde 
 > >>> run: service kdm4 onestart. 
 > >>>  
 > >>> Note that the image name has changed. The most recent should be 
 > >>> self-evident in: http://www.bsddesktop.com/images [3] 
 > >>>  
 > >>> Helpful hint: use a 1MB blocksize for dd and run gpart recover 
 > >>> to fix label warnings. Assuming your USB pen drive shows up as 
 > >>> /dev/da0 and cftdisk image is the one I just posted: 
 > >>>  
 > >>> unxz -f cftdisk_2016052307.img.xz; dd if=cftdisk_2016052307.img 
 > >>> of=/dev/da0 bs=1M; gpart recover da0 
 > >>>  
 > >>> And as a reminder, if you're having problems with X on the USB 
 > >>> key, try disabling it by moving /etc/X11/xorg.conf.d/20-intel.conf 
 > >>  
 > >>> somewhere else on your file system. 
 > >>>  
 > >>> If using the github repo, make sure you're using the drm-next-4.6 
 > >>> branch. 
 > >>>  
 > >>> Cheers. 
 > >>>  
 > >>> -M 
 > >>>  
 > >>> _______________________________________________ 
 > >>> freebsd-x11_at_freebsd.org mailing list 
 > >>> https://lists.freebsd.org/mailman/listinfo/freebsd-x11 [4] 
 > >>> To unsubscribe, send any mail to 
 > >> "freebsd-x11-unsubscribe_at_freebsd.org" 
 > >  
 > >  
 > > Links: 
 > > ------ 
 > > [1] 
 > > https://cgit.freedesktop.org/mesa/drm/commit/?id=e3623d34cad0ac3f181b0deee0931df202b8f909 
 > > [2] http://www.bsddesktop.com/images/cftdisk_2016052307.img.xz 
 > > [3] http://www.bsddesktop.com/images 
 > > [4] https://lists.freebsd.org/mailman/listinfo/freebsd-x11 
 > _______________________________________________ 
 > freebsd-current_at_freebsd.org mailing list 
 > https://lists.freebsd.org/mailman/listinfo/freebsd-current 
 > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" 
 >