Re: [Nouveau] [TEST REQUEST] NV50/NV8x/NV9x/NVAx ctxpro g and ctxvals generator
Hello, Sorry for not answering to the right message, I've just joined the mailing list. I've tried this patch on my Quadro NVS 140M and it fails to load KDM. It shows the background but fails to show the credential edit boxes. It seems like the computer is locked up though the mouse can still move (can't do any VT switches) and I still can ssh on it. Needless to say this works without the patch ;) Aiii... ok, I accidentally introduced a bug in pre-NVA0 branch during last- minute cleanups... I just uploaded a new version at the same address that should fix that issue. Btw, to anyone reporting success/failure with the generator: please include your chipset code number [NV50, NV96, NVA5, etc.]. If you don't know what it is, just report the hex number in Detected an NV50 generation card (0x086900a2) line Sorry for that screwup Marcin Kościelnicki ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] no start with latest modules from git
Hello, Using code from git a week is since I cannot start Xorg with nouveau on a Quatro NVS 290. Commits from git.freedesktop.org: xorg-server - db4f676f25c6d8e58263d5151942be730592d444 xf86-video-nouveau - 70d0a48b6c3f1a817bf850acd3bae48d063e56b9 libdrm - 3130f94c6ee32668cb9f0b96b6c8e308a7bb3b11 mesa - e16f0c14f353cc04ad6cbcf99e3b95ccb1d2c06b A similar problem for xf86-video-intel solved meanwhile by updates to the above. Thanks for any help, s. File /var/log/Xorg.log.0 content: [383234.171] X.Org X Server 1.7.99.901 (1.8.0 RC 1) Release Date: 2010-02-12 [383234.171] X Protocol Version 11, Revision 0 [383234.171] Build Operating System: Linux 2.6.33-rc8 x86_64 [383234.171] Current Operating System: Linux job 2.6.33-rc8 #2 SMP Sun Feb 14 14:30:15 EET 2010 x86_64 [383234.171] Build Date: 24 February 2010 10:51:55AM [383234.171] [383234.171] Current version of pixman: 0.17.7 [383234.178] (--) PCI:*(0:1:0:0) 10de:042f:10de:0492 nVidia Corporation G86 [Quadro NVS 290] rev 161, Mem @ 0xf200/16777216, 0xe000/268435456, 0xf000/33554432, I/O @ 0x2100/128 [383234.179] (II) Loading extension DRI2 [383234.179] (II) LoadModule: nouveau [383234.179] (II) Loading /usr/lib/xorg/modules/drivers/nouveau_drv.so [383234.180] (II) Module nouveau: vendor=X.Org Foundation [383234.180] compiled for 1.7.99.901, module version = 0.0.15 [383234.180] Module class: X.Org Video Driver [383234.180] ABI class: X.Org Video Driver, version 7.0 [383234.180] (II) NOUVEAU driver Date: Tue Feb 23 15:08:13 2010 +1000 [383234.180] (II) NOUVEAU driver for NVIDIA chipset families : [382273.712] (II) Primary Device is: PCI 0...@00:00:0 [382273.712] drmOpenDevice: node name is /dev/dri/card0 [382273.712] drmOpenDevice: open result is 8, (OK) [382273.712] drmOpenByBusid: Searching for BusID pci::01:00.0 [382273.712] drmOpenDevice: node name is /dev/dri/card0 [382273.712] drmOpenDevice: open result is 8, (OK) [382273.712] drmOpenByBusid: drmOpenMinor returns 8 [382273.712] drmOpenByBusid: drmGetBSection Device [382273.712] (EE) [drm] failed to open device [382273.712] (EE) No devices detected. [382273.712] Fatal server error: [382273.712] no screens found File /etc/X11/xorg.conf content: Section Screen IdentifierSingleView0 DeviceNVIDIA C. Quadro NVS 290 (SingleView) MonitorHP L1950 LCD DefaultDepth24 OptionTwinViewfalse SubSectionDisplay VisualTrueColor Depth24 Modes1024x1280 1280x1024 ViewPort0 0 Virtual2560 1280 EndSubSection EndSection Section ServerFlags OptionDefaultServerLayoutSV OptionUseDefaultFontPathfalse OptionAIGLXon EndSection Section ServerLayout IdentifierSV ScreenSingleView0Absolute 0 0 EndSection Section Device IdentifierNVIDIA C. Quadro NVS 290 (SingleView) VendorNameNVIDIA Corp BoardNameQuadro NVS 290 (Rev A1) Drivernouveau EndSection ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 15758] Invisible mouse pointer on NV4E (C51)
http://bugs.freedesktop.org/show_bug.cgi?id=15758 --- Comment #22 from Xavier shinin...@gmail.com 2010-02-24 03:38:05 PST --- (In reply to comment #20) Hi, I would like to confirm this bug still exists almost a year later on: kernel-2.6.31.12-174.2.22.fc12.i686.PAE It only happens on my laptop's external VGA display, never on the LVDS. We don't know which nouveau code fedora ships, you need to report on their bug tracker. Otherwise, make sure you have an up-to-date ddx : http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/ But you might need a specific git version of libdrm if you want ddx to compile and not having to upgrade nouveau drm (kernel module). -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 26733] Full-screen XV causes graphics lockup
http://bugs.freedesktop.org/show_bug.cgi?id=26733 --- Comment #1 from Tavian Barnes taviana...@gmail.com 2010-02-24 08:50:59 PST --- A drm module I compiled on the 21st works fine, so it looks to me like this commit caused it: 966a2b2e31b4d7fd72733ebb78a74bf0054a3f85. And sadly that commit fixes suspend for me, so I either get working full-screen XV or working suspend. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [TEST REQUEST] NV50/NV8x/NV9x/NVAx ctxprog and ctxvals generator
Le 24/02/2010 09:22, Marcin Kościelnicki a écrit : Aiii... ok, I accidentally introduced a bug in pre-NVA0 branch during last- minute cleanups... I just uploaded a new version at the same address that should fix that issue. Btw, to anyone reporting success/failure with the generator: please include your chipset code number [NV50, NV96, NVA5, etc.]. If you don't know what it is, just report the hex number in Detected an NV50 generation card (0x086900a2) line Sorry for that screwup Marcin Kościelnicki It works better now, I could not spot any regression. Thanks, Martin ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] Why report LVDS as disconnected when lid is closed?
What's the motivation behind commit 60821e0 (drm/nouveau: report LVDS as disconnected if lid closed)? The only noticeable effect I can see from it is that if I turn on my laptop and then close the lid, X fails to start as it can't find any screens. In fact, if I close the lid before nouveau initialises, I don't even get a framebuffer console. I know I can just use the ignorelid module param, but what's the benefit without it? -- Tavian Barnes ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Why report LVDS as disconnected when lid is closed?
On Wed, 2010-02-24 at 18:51 -0500, Tavian Barnes wrote: What's the motivation behind commit 60821e0 (drm/nouveau: report LVDS as disconnected if lid closed)? The only noticeable effect I can see from it is that if I turn on my laptop and then close the lid, X fails to start as it can't find any screens. In fact, if I close the lid before nouveau initialises, I don't even get a framebuffer console. I know I can just use the ignorelid module param, but what's the benefit without it? The benefit is people on laptops with docking stations can close the lid, and have two external outputs light up. Otherwise, LVDS (which isn't visible because the lid is closed) will likely be programmed and only one external display. Ben. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 3/3] drm/nouveau: Fix noaccel/nofbaccel option descriptions.
Signed-off-by: Marcin Kościelnicki koria...@0x04.net --- drivers/gpu/drm/nouveau/nouveau_drv.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.c b/drivers/gpu/drm/nouveau/nouveau_drv.c index da3b93b..874adf5 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drv.c +++ b/drivers/gpu/drm/nouveau/nouveau_drv.c @@ -75,11 +75,11 @@ MODULE_PARM_DESC(ignorelid, Ignore ACPI lid status); int nouveau_ignorelid = 0; module_param_named(ignorelid, nouveau_ignorelid, int, 0400); -MODULE_PARM_DESC(noagp, Disable all acceleration); +MODULE_PARM_DESC(noaccel, Disable all acceleration); int nouveau_noaccel = 0; module_param_named(noaccel, nouveau_noaccel, int, 0400); -MODULE_PARM_DESC(noagp, Disable fbcon acceleration); +MODULE_PARM_DESC(nofbaccel, Disable fbcon acceleration); int nouveau_nofbaccel = 0; module_param_named(nofbaccel, nouveau_nofbaccel, int, 0400); -- 1.6.4.1 ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [Mesa3d-dev] makedepend in Mesa
On Tue, Feb 23, 2010 at 1:29 PM, Xavier Chantry chantry.xav...@gmail.com wrote: While keeping up-to-date the nouveau mesa driver (either classic or gallium), or doing regression testing, the big majority of my rebuilds resulted in segfaults. I am not talking about autogen or configure detection. I believe this also works automatically in other projects and doesn't with mesa, but forgetting to do this usually causes a build failure. Then autogen/configure can be run and make can resume the build. What is more problematic is when an apparently successful build does not work. The reply I used to get is just to make clean or distclean/realclean. clean is usually works, but rebuilding everything takes time. And regression testing needs a lot of rebuilding :) Anyway I found this IRC discussion yesterday quite interesting : 20:30 * jbarnes curses the mesa build system 20:31 jbarnes change intel_fbo.h, nothing rebuilds 20:32 Dr_Jakob makedepend installed? 20:33 jbarnes yeah but it looks like we don't symlink intel_fbo.h into i915 and include it in the makefile 20:33 jbarnes so I guess the deps don't get picked up 20:34 Dr_Jakob Hmm 20:34 jbarnes oh no I guess I don't have makedepend 20:34 -!- jsgf [~jer...@adsl-69-107-81-54.dsl.pltn13.pacbell.net] has joined #dri-devel 20:34 * jbarnes tries again with that installed 20:35 jbarnes don't most projects just use gcc's dep tracking? 20:35 Dr_Jakob yes 20:36 Dr_Jakob I tried to add that but it mostly turned into fail. We could use gcc directly for depends (I have a patch to do it), but: 1. I don't think it would actually help much in terms of rebuilds since makedepend seems to do a perfectly adequate job of finding the needed headers. 2. gcc expects to output a single make target for a single source file. mesa just tosses all the source files at makedepend which generates a depend file with a bunch of targets. gcc is phenomenally slow doing the same. Changing the build to include one dep file per source file would be a ton of churn. 3. The fast way automake does gcc dep tracking is to do it as a step during the compile. Since gcc fully preprocesses the source file before generating the make target, you can get it for free during the compile. Doing as a separate step like mesa means you're throwing away the preprocessing and then doing it again immediately afterward. The time adds up. I guess what I'm saying is that I wouldn't bother with gcc dep tracking unless it's coming as part of automake. 20:37 jbarnes Dr_Jakob: you guys mostly build with scons these days right? 20:37 jbarnes and that has a separate set of files for tracking sources? 20:37 Dr_Jakob For windows yes, but I use make for linux. 20:37 Dr_Jakob Then again I'm pretty good at installing makedepend ;-) 20:37 jbarnes heh 20:39 Dr_Jakob I don't often have to do a make clean. 20:40 suokko I guess there is something broken in radeon makefiles because make clean is required quite often 20:40 suokko Luckily ccache is very fast 20:40 MostAwesomeDude Yeah, ccache is a much better friend than makedepend. 21:48 shining still not very clear to me, should everyone have makedepend installed for building mesa ? 21:49 Dr_Jakob it is higly recommended yes. 21:51 shining does it help with mesa build failures ? I have seen many many times in #nouveau weird mesa behavior because of build failure, and a make distclean/realclean fixed it 21:51 shining sorry its not build failure 21:51 Dr_Jakob yes 21:51 shining it *seems* to build fun but it doesnt work correctly, most of the time it simply segfaults 21:52 shining huh 21:52 shining s/fun/fine 21:54 suokko shining: Problem without makedepend is that in rebuild make doesn't build all files that should be rebuild because it doesn't know about included files. So if you link old and new object files and some memory layout changed you will get segfaults 22:49 shining then I would workaround it by requiring makedepend 22:51 zackr we don't have a configure step so you'll need to most likely rewrite the build system to do that I probably should look into ccache (and I probably will), but if makedepend improves the rebuild situation, I believe it should be better advertised. And unless I am mistaken, mesa does have a configure step, I even believed most people use that. So my simple suggestion would be to simply print a warning if makedepend is not detected. configure checks for makedepend, but doesn't error if it's not found. It probably should. Likewise, the commands running makedepend should probably not be silenced with stderr redirected to /dev/null. That would break builds for people using the static configs without makedepend. I saw a report saying make clean was still needed with makedepend installed, but maybe not every parts of mesa uses makedepend correctly, like the nouveau driver ? I think the problem is more that
Re: [Nouveau] [PATCH] drm/nouveau: use ALIGN instead of open coding it
On Wed, 2010-02-24 at 23:27 -0500, Matt Turner wrote: CC: Ben Skeggs bske...@redhat.com Signed-off-by: Matt Turner matts...@gmail.com --- drivers/gpu/drm/nouveau/nv04_fbcon.c |2 +- drivers/gpu/drm/nouveau/nv50_fbcon.c |2 +- drivers/gpu/drm/nouveau/nv50_instmem.c |2 +- 3 files changed, 3 insertions(+), 3 deletions(-) Thank you, in nouveau git. Ben. diff --git a/drivers/gpu/drm/nouveau/nv04_fbcon.c b/drivers/gpu/drm/nouveau/nv04_fbcon.c index fd01caa..3da90c2 100644 --- a/drivers/gpu/drm/nouveau/nv04_fbcon.c +++ b/drivers/gpu/drm/nouveau/nv04_fbcon.c @@ -118,7 +118,7 @@ nv04_fbcon_imageblit(struct fb_info *info, const struct fb_image *image) return; } - width = (image-width + 31) ~31; + width = ALIGN(image-width, 32); dsize = (width * image-height) 5; if (info-fix.visual == FB_VISUAL_TRUECOLOR || diff --git a/drivers/gpu/drm/nouveau/nv50_fbcon.c b/drivers/gpu/drm/nouveau/nv50_fbcon.c index 0f57cdf..993c712 100644 --- a/drivers/gpu/drm/nouveau/nv50_fbcon.c +++ b/drivers/gpu/drm/nouveau/nv50_fbcon.c @@ -109,7 +109,7 @@ nv50_fbcon_imageblit(struct fb_info *info, const struct fb_image *image) return; } - width = (image-width + 31) ~31; + width = ALIGN(image-width, 32); dwords = (width * image-height) 5; BEGIN_RING(chan, NvSub2D, 0x0814, 2); diff --git a/drivers/gpu/drm/nouveau/nv50_instmem.c b/drivers/gpu/drm/nouveau/nv50_instmem.c index 94400f7..a8a639e 100644 --- a/drivers/gpu/drm/nouveau/nv50_instmem.c +++ b/drivers/gpu/drm/nouveau/nv50_instmem.c @@ -373,7 +373,7 @@ nv50_instmem_populate(struct drm_device *dev, struct nouveau_gpuobj *gpuobj, if (gpuobj-im_backing) return -EINVAL; - *sz = (*sz + (NV50_INSTMEM_PAGE_SIZE-1)) ~(NV50_INSTMEM_PAGE_SIZE-1); + *sz = ALIGN(*sz, NV50_INSTMEM_PAGE_SIZE); if (*sz == 0) return -EINVAL; ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 26733] Full-screen XV causes graphics lockup
http://bugs.freedesktop.org/show_bug.cgi?id=26733 --- Comment #2 from Tavian Barnes taviana...@gmail.com 2010-02-24 20:48:12 PST --- Never mind, a proper bisect points out 21c684bc635f76c71741541eb10dfa86fd846cfa (drm/nv50: switch to indirect push buffer controls) as the offending commit. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 23198] nv50/NVS135M: video hangs/flickers when fullscreen
http://bugs.freedesktop.org/show_bug.cgi?id=23198 --- Comment #8 from Marcin Kościelnicki koria...@0x04.net 2010-02-24 21:27:53 PST --- Should be fixed in latest git. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
