CFT update day 2

[René Ladan]

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?

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é
>     >
>