Update 2 the state of drm-next-4.6 and next steps

[Alexander Mishurov]

I'm experiencing the same issue. The keyboard works only in the terminal 
where a kldload was launched from, if I try to log in to another 
terminal, Alt+F(x), it doesn't respond on a typing.

My hardware is Bay Trail, ValleyView.

Output is:
May 22 18:05:12 fbsd kernel: [drm] Initialized drm 1.1.0 20060810
May 22 18:05:12 fbsd kernel: bus_register unimplemented!!!
May 22 18:05:12 fbsd kernel:
May 22 18:05:12 fbsd kernel: [drm:drm_pci_init]
May 22 18:05:12 fbsd kernel: drmn0: <drmn> on vgapci0
May 22 18:05:12 fbsd kernel: [drm:drm_get_pci_dev]
May 22 18:05:12 fbsd kernel: simple_pin_fs is dodgy -- see your local 
kernel hacker
May 22 18:05:12 fbsd kernel: vgapci0: child drmn0 requested pci_enable_io
May 22 18:05:12 fbsd kernel: vgapci0: child drmn0 requested pci_enable_io
May 22 18:05:12 fbsd kernel: [drm:drm_minor_register]
May 22 18:05:12 fbsd kernel: [drm:drm_minor_register] new minor 
registered 64
May 22 18:05:12 fbsd kernel: [drm:drm_minor_register]
May 22 18:05:12 fbsd kernel: [drm:drm_minor_register] new minor 
registered 128
May 22 18:05:12 fbsd kernel: [drm:drm_minor_register]
May 22 18:05:12 fbsd kernel: [drm:drm_minor_register] new minor registered 0
May 22 18:05:12 fbsd kernel: __pm_runtime_resume not implemented -- see 
your local kernel hacker
May 22 18:05:12 fbsd kernel: [drm:i915_dump_device_info] i915 device 
info: gen=7, pciid=0x0f31 rev=0x00 
flags=is_mobile,need_gfx_hws,is_valleyview,has_hotplug,
May 22 18:05:24 fbsd kernel: ath0: ath_edma_rxbuf_alloc: 
bf=0xfffffe00010dfbc8, rxbuf alloc failed! error=55
May 22 18:05:24 fbsd kernel: ath0: ath_edma_rxfifo_alloc: Q1: alloc 
failed: i=0, nbufs=128?
May 22 18:05:24 fbsd kernel: ath0: ath_edma_rxbuf_alloc: 
bf=0xfffffe00010dfef8, rxbuf alloc failed! error=55
May 22 18:05:24 fbsd kernel: ath0: ath_edma_rxfifo_alloc: Q1: alloc 
failed: i=0, nbufs=128?

On 23/05/16 23:28, Lundberg, Johannes wrote:
>> happily running my broadwell laptop
> That's interesting. On my Cherry View dev board which is also Broadwell
> graphics (I think) I get some output from kldload i915kms but then it
> halts. USB keyboard still works (as in I can press enter and console
> scrolls up) but no response from OS.
>
> I do get some message about bus_register something missing..
>
> Maybe not ready for testing?
>
>
> On Sat, May 21, 2016 at 4:17 PM, Baptiste Daroussin <bapt at freebsd.org>
> wrote:
>
>> On Wed, May 11, 2016 at 02:29:36AM -0700, Matthew Macy wrote:
>>>
>>> At least to some degree hw accelerated 3d works on the 4.6 i915 driver
>> (which in principle supports up through Kaby lake - I don't yet have
>> anything newer than Haswell).
>>> https://plus.google.com/114029301710423058970/posts/485LyZegC9B
>>>
>>> I anticipate maintaining all the pieces: linuxkpi, drm, i915, amdgpu,
>> amdkfd as ports for the foreseeable future to make maintenance and
>> continued development simpler.
>>> I hope to post a call for testers this weekend or early next week.
>>>
>>> Cheers.
>>>
>>> -M
>>>
>>>
>>>   ---- On Sun, 24 Apr 2016 13:18:14 -0700 Matthew Macy <mmacy at nextbsd.org>
>> wrote ----
>>>   >
>>>   >
>>>   >
>>>   >  ---- On Tue, 12 Apr 2016 12:57:34 -0700 Matthew Macy <
>> mmacy at nextbsd.org> wrote ----
>>>   >  > There seems to be some confusion about the state of drm-next-3.9.
>> All the work is currently going on in jmd's fork of freebsd-base-graphics:
>>>   >  >
>>>   >  > https://github.com/iotamudelta/freebsd-base-graphics
>>>   >  >
>>>   >  > The emphasis has been on bringing i915 and the drm code  in
>> dev/drm2 closer to upstream as opposed to a simple driver refresh. I'm
>> currently implementing missing linuxkpi bits and hope to actually be
>> testing in the next week or so.
>>>   >  >
>>>   >  > As of this moment there is nothing available for general
>> consumption. I very much hope to have this phase done before code freeze. I
>> will update the list as soon as there is anything to test. Until then, hold
>> your horses.
>>>   >  >
>>>   >
>>>   > X now runs i915kms accelerated on the 3.9 driver update. Currently
>> *only* SNA works.
>>>   > Known issues:
>>>   >   -  UXA will fail with: "(EE) failed to create screen resources(EE)".
>>>   >        If someone has pointer on how to diagnose other than the usual
>> trawling
>>>   >       through Xorg sources let me know.
>>>   >   - The module currently leaks memory on unload.
>>>   >
>>>   >
>>>   > My general feeling is that unless you have one of the half-dozen
>> Haswell PCIIDS that aren't support by 3.8 it probably isn't worth testing
>> yet. I'm only sending this out to let users track its progress.
>>>   >
>>>   >
>>>   > Cheers.
>>>   > -M
>>>
>> as a follow-up I want to share that I cherry-picked the code from the
>> drm-next-4.6 branch on the current source tree and I am now happily
>> running my
>> broadwell laptop with the i915 driver (lenovo x250) so far no problem for
>> normal
>> usage. I have a few glitches with xrandr but nothing that makes it
>> unusable.
>>
>> I will test with the next version of xorg server and latest xorg intel
>> driver to
>> see if that fixes the glitches.
>>
>> Thnak you all for you work!
>>
>> Bapt
>>