Re: [PREVIEW] Nouveau on FreeBSD (Take 2)

From: Anonymous <swell.k_at_gmail.com>
Date: Mon, 23 Mar 2009 00:15:59 +0300
Robert Noland <rnoland_at_FreeBSD.org> writes:

> Ok, this patch should work on NV50 chips also.
>
> What you get is EXA and Xv.
>
> You still need:
>
> A recent -CURRENT or -STABLE.
>
> git master of libdrm and xf86-video-nouveau.
>
> This patch.
>
> Things I've figured out since the last patch...
>
> On NV50 class hardware you need to have a compositing manager running
> for Xv to work.  That means xcompmgr, metacity with composite enabled,
> xfce (rumored to work as well, haven't tried).  If your running Gnome
> with metacity, open gconf-editor and go to apps->metacity->general and
> check the composite box.
[...]
>
> http://people.freebsd.org/~rnoland/drm-nouveau-032109.patch
>
> robert.

Here is my Xorg.log - http://pastebin.com/m6fab6feb (Xserver is from git master)
and kernel messages logged via syslog DRM_DEBUG - http://pastebin.com/m263af8da
They are with successfull `xcompmgr -a' run

- Compared to previous patch now I get

_at__at_ -237,6 +237,7 _at__at_
 (II) NOUVEAU(0): nv50_output_detect is called.
 (II) NOUVEAU(0): NV50ConnectorDDCDetect is called.
 (II) NOUVEAU(0): I2C device "DVI-0:ddc2" registered at address 0xA0.
+(II) NOUVEAU(0): I2C device "DVI-0:DDC control interface" registered at address 0x6E.
 (II) NOUVEAU(0): Detected a Digital output on DVI-0
 (II) NOUVEAU(0): Found a suitable output, index 1
 (II) NOUVEAU(0): nv50_output_detect is called.
_at__at_ -382,8 +383,8 _at__at_
 	[4] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
 (==) NOUVEAU(0): Write-combining range (0xa0000,0x10000) was already clear
 (II) NOUVEAU(0): Allocated 128MiB VRAM for framebuffer + offscreen pixmaps, at offset 0x20000000
-(II) NOUVEAU(0): AGPGART: 512MiB available
-(EE) NOUVEAU(0): Unable to allocate GART memory
+(II) NOUVEAU(0): AGPGART: 32MiB available
+(II) NOUVEAU(0): GART: Allocated 16MiB as a scratch buffer
 (II) NOUVEAU(0): [drm] Using the DRM lock SAREA also for drawables.
 (II) NOUVEAU(0): [drm] framebuffer handle = 0xe0000000
 (II) NOUVEAU(0): [drm] added 1 reserved context for kernel

- This error in Xorg.log is still present

      (II) NOUVEAU(0): [DRI] installation complete
      (EE) NOUVEAU(0): [dri] unable to reference front buffer: -19

  Should I ignore it?

- Got these errors in dmesg

      error: [drm:pid1424:drm_alloc_resource] *ERROR* Couldn't find resource 0x2

and

      info: [drm] PGRAPH_ERROR - nSource:info: [drm] PROTECTION_ERRORinfo: [drm] DMA_R_PROTECTIONinfo: [drm] , nStatus:info: [drm] 
      info: [drm] PGRAPH_ERROR - Ch 2/2 Class 0x8297 Mthd 0x15e0 Data 0x00000000:0x00000000
      error: [drm:pid11:nv50_pgraph_irq_handler] *ERROR* magic set 1:
      error: [drm:pid11:nv50_pgraph_irq_handler] *ERROR* 	0x00408900: 0x80000000
      error: [drm:pid11:nv50_pgraph_irq_handler] *ERROR* 	0x00408904: 0xfdb76b7b

  Should I ignore them?

- Scrolling (shift+pgup/pgdn) in xterm is *slower* with DRM than
  without it but still faster than with NoAccel. I'm using xterm with
  TTF font (DejaVu Sans Mono). It's yet more noticeable when scrolling
  in less(1)/screen(1) when redrawing affects whole screen not half.
  Besides, there is more flickering with highly updating cli apps when
  using DRM. However, launching xcompmgr fixes this sluggishness.

- XVideo works fine

- EXAPixmaps uses DRI2 and works fine. I wasn't able to test with xcompmgr.

- Launching `xcompmgr -a' is tricky. Most of the time it just leaves
  screen in unusable state, it's not possible to switch to console or
  move pointer. I want to help debug this one. Here are logs:
  http://pastebin.com/m1ca3fc2f
  http://pastebin.com/m579d358e
Received on Sun Mar 22 2009 - 20:16:40 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:44 UTC