similar to: 3DLabs Wildcat

Does anyone know (appoximately) the max loop length that the FXS module on a Wildcat TDM400 card will drive an analog phone(over standard - say cat3 or 26 gage twisted-pair wire). It's clearly not going to be 18kft, but perhaps 4000 feet? Thanks Elliot Eichen elliot.eichen@tbx25.tonebridge.com

Hello, The idea was to use the modesetting DDX instead of Nouveau’s one for Maxwell+ as EXA was [broken][1]. But you can give a try at Ilia’s [patches][2], which fix the Nouveau DDX for GM10x and GM20x (I don’t think it has been tested on a GM108 yet). Best regards, Pierre Moreau [1]: https://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=3e2e0faa2ee1cce9c1bb5c7ad80d0592460f3edc

hi, give the drm-next kernel tree a try. Sadly the reclocking improvements didn't land with 4.9, so 4.10 is required. Greetings. On 7 December 2016 10:26:44 a.m. GMT+01:00, "Sune Mølgaard" <smo at translucent.dk> wrote: >Hi again, > >It works :-) > >Reclocking, however, is another kettle of fish. > >Trying #echo 0f > /sys/kernel/debug/dri/0/pstate

also you can't change the clocks when there is nothing running on the GPU. I have some patches pending for this in another series, but maybe I may be able toe extract those fixes. Changing the clocks while something is running shouldn't cause any troubles. Alternatively if you don't care about power consumption, you can boot with nouveau.runpm=0 so that the gpu is always on.

you can boot with nouveau.config=NvBoost=2 to enable higher clocks, but that won't fill in the difference compared to Intel. For this there are some changes needed on the mesa side regarding scheduling. Also keep in mind, that PCIe is an important bottleneck here, because the GPU can't push frames fast enough through the bus, that's why any "high FPS" benchmark will be in

Adam Jackson (3): Remove mibstore.h Pass the pci device through to fbdevHWInit Adapt Block/WakeupHandler signature for ABI 23 Matt Turner (1): xf86-video-glint 1.2.9 Michael Lorenz (1): Fix I2C for DDC2. git tag: xf86-video-glint-1.2.9 https://xorg.freedesktop.org/archive/individual/driver/xf86-video-glint-1.2.9.tar.bz2 MD5: 3d166b7a97d96007272ffc153d5f81fd

Adam Jackson (2): Fix distcheck glint 1.2.0 Alan Hourihane (1): Fix --disable-dri for glint driver Brice Goglin (1): Define GLINT_*_VERSION* using PACKAGE_VERSION_* Dave Airlie (4): half attempt at pciaccess conversion for glint - doesn't build yet fix typos in dac code from last commit hey look a flying pig.... fix regression in tinderbox

Julien Cristau (2): Fix regression from pciaccess conversion (bug#16060) Bump to 1.2.1 git tag: xf86-video-glint-1.2.1 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-glint-1.2.1.tar.bz2 MD5: 6d7afdac0a26cf201c3f3b417c31c5e1 xf86-video-glint-1.2.1.tar.bz2 SHA1: 9e4959c2a39c22bf4a81b1eba4ec809f9c571bc8 xf86-video-glint-1.2.1.tar.bz2

Dear Telcotype Braniacs, I have tried doing a google search to find out what this switch looks like, what the physical interface is, but havn't been successful. I am quite new to the ISDN world so I'm not sure what to expect when I see this switch. Does anyone have any experience connecting to this switch? The following is basically all I have been given for info: 1) Ericsson, AXT121,

--- Hi, this is still WIP, but already passes piglit's s3tc-teximage, s3tc-texsubimage and fbo-generatemipmap-formats(s3tc tests) and even Wolfenstein:Enemy-Territory works on my nv25. It's based on Ben's newlib branch. I have few issues though: 1) So far it needs libtxc_dxtn, but I might expose the s3tc extensions even without encoder using driconf option - Is that desirable? 2)

I have recently been trying to build rgl on MacOS X 10.4 using R-2.1.1 with gcc-4.0 5026 and gfortran. The R binary I built without problems and it includes libpng and Tcl/ Tk on X11. Rcmdr works correctly. The rgl build produces a large number of warnings like: g++ -no-cpp-precomp -I/Library/Frameworks/R.framework/Resources/ include -I/System/Library/Frameworks/OpenGL.framework/Headers

Hi, I recently had a problem installing the rgl package on OS X and put together a simple patch. The patched package is available here: http://jinome.stanford.edu/files/rgl_0.66-patched_for_gcc4.tar.gz It can be installed with "R CMD INSTALL rgl_0.66-patched_for_gcc4.tar.gz" as normal at the command line. Also -- as of right now rgl is not in the repository of version 2.3 packages

Hi again, It works :-) Reclocking, however, is another kettle of fish. Trying #echo 0f > /sys/kernel/debug/dri/0/pstate hangs X. Trying the same with no X running reveals: Dec 7 10:08:42 dell-smo kernel: [ 728.831020] nouveau 0000:08:00.0: clk: unable to find matching pll values a number of time as then soft lockup. Very much akin to

Hi, With drm-next from http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-next/2016-12-08/ I don't get the error messages, but I still get a soft cpu lockup. What info would you need from me to get it working? Best regards, Sune Mølgaard On 2016-12-08 08:10, Karol Herbst wrote: > hi, > > give the drm-next kernel tree a try. Sadly the reclocking improvements didn't land with

Aha! That seems to do it. If I interpret correctly, it doesn't set it quite to full power, though, but it's certainly an improvement: 07: core 405 MHz memory 810 MHz 0a: core 270-1124 MHz memory 1600 MHz 0f: core 270-1124 MHz memory 2002 MHz AC DC * AC: core 1012 MHz memory 2002 MHz A short run of glmark2 shows aver 100% improvement to ~550 FPS. Interestingly, it's still nowhere

Ilia Mirkin <imirkin at alum.mit.edu> writes: > mesa_texstore expects pixel data, not compressed data. For compressed > textures, we want to just copy the bits in without any conversion. > Any reason we cannot use _mesa_store_compressed_*image for this instead of rolling our own? > Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> > --- >

On Sun, Sep 14, 2014 at 3:37 AM, Francisco Jerez <currojerez at riseup.net> wrote: > Ilia Mirkin <imirkin at alum.mit.edu> writes: > >> mesa_texstore expects pixel data, not compressed data. For compressed >> textures, we want to just copy the bits in without any conversion. >> > > Any reason we cannot use _mesa_store_compressed_*image for this instead

mesa_texstore expects pixel data, not compressed data. For compressed textures, we want to just copy the bits in without any conversion. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/mesa/drivers/dri/nouveau/nouveau_texture.c | 65 ++++++++++++++++++++------ 1 file changed, 52 insertions(+), 13 deletions(-) diff --git a/src/mesa/drivers/dri/nouveau/nouveau_texture.c

I am newbie in this topic and I have problems trying to bring x.org up on the hardware I have: IBM QS22 BladeServer (PowerPC64 architecture) with PCI-Express connected nVidia 6200 video card. OS: Fedora 10-ppc: Linux localhost.localdomain 2.6.27.5aik #1 SMP Tue Feb 10 14:55:56 EST 2009 ppc64 ppc64 ppc64 GNU/Linux I downloaded and compiled DRM driver (git clone

Running Debian Wheezy Hardware: Older P4 3.06 GHz video: Nvidia FX 5700LE Monitor is 25.5 asus LCD with 1900x1280 native resolution. (xrander sees it as 1400x900) (I've included the output of xrandr -q at the end, also following that output is Xorg.0.log) I recently made some effort to obtain a large pannable desktop like I have used for many years. And since on newer debian they expect to