On Mon, 2009-03-23 at 00:15 +0300, Anonymous wrote: > 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 Ok, this is good... > - 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? Let me switch back to the NV50 and look at that. > - Got these errors in dmesg > > error: [drm:pid1424:drm_alloc_resource] *ERROR* Couldn't find resource 0x2 This should be ok, it tries resource id 2, and if it can't find that it uses resource 3. It just means that resource 1 is a 64bit BAR. > 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? This I need to look at, it may be because I haven't fully implemented fencing. I thought it was ok like it was. I also just fixed an issue with allocating scatter / gather pages in -CURRENT, which may be related. > - 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. This may be related to compositing with git server. Text rendering is causing considerable load on the Xserver with compositing enabled. The composite manager is only needed for Xv, can you try without it. > - XVideo works fine Ok, cool. > - 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 I'll have to look at this, but I was able to enable/disable it ok, iirc. robert. -- Robert Noland <rnoland_at_FreeBSD.org> FreeBSD
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:44 UTC