Please try patching. The new xf86-intel barely works at all for
bapt on his broadwell. Believe it or not, I have not had time to test the new X
bits myself. It should all work "eventually" but there is a lot to cover and
I'm not at all familiar with the user side bits.Sorry for top posting. Zoho's
iOS client is kind of broken.-M---- On Mon, 23 May 2016 14:30:51 -0700
Matthias Haas<freebsd-...@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. 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-...@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 fixe
s: >>> - 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'r
e 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-...@freebsd.org
mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-x11 [4] >>>
To unsubscribe, send any mail to >> "freebsd-x11-unsubscr...@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@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
