On Mon, 2010-04-12 at 20:04 +0300, Pekka Paalanen wrote:
> On Mon, 12 Apr 2010 12:50:13 +0200
> Marcin Slusarz wrote:
>
> > I'm not aware of any trick to make both nv and nouveau working.
> > Maybe there should be a way to prevent nv (and vesa, but not
> > fbdev) from loading when KMS is in use?
https://bugs.freedesktop.org/show_bug.cgi?id=27603
--- Comment #8 from Alex Buell 2010-04-12 17:02:32
PDT ---
(In reply to comment #7)
> You can work around this by setting NOUVEAU_NO_SWIZZLE=1 in your env.
Yes, that got me past the crash, thanks for that one, most helpful.
Unfortunately, ce
https://bugs.freedesktop.org/show_bug.cgi?id=27603
--- Comment #7 from Younes Manton 2010-04-12 16:20:05 PDT
---
You can work around this by setting NOUVEAU_NO_SWIZZLE=1 in your env.
If you know your way around GDB maybe you can run your app under it and when it
asserts do something like:
'whe
https://bugs.freedesktop.org/show_bug.cgi?id=27603
--- Comment #6 from Xavier 2010-04-12 15:59:23 PDT ---
Just FYI, Luca made this repository before he got commit access to mesa. Since
he got access a while ago, he will progressively merge all of this work, and
that mesa-lb repo is pretty much dy
https://bugs.freedesktop.org/show_bug.cgi?id=27603
--- Comment #5 from Alex Buell 2010-04-12 15:37:14
PDT ---
(In reply to comment #4)
> You have to go to the main page to find the git and http URL :
> http://repo.or.cz/w/mesa/mesa-lb.git
> (you can find this link on the first line of each git p
>
> Ok, thanks for explanation. I'll drop this patch and rebase the others.
Cool,
>> You won't be able to make this work for vga16fb from what I can see
>> since it access 0xa000 directly, not via any of the defined apertures
>> that vesafb/offb use. vga16fb will need a different approach I suspe
It simplifies nouveau code by removal of detection which
region to pass to kick vesafb/efifb.
Signed-off-by: Marcin Slusarz
Cc: Eric Anholt
Cc: Ben Skeggs
Cc: Thomas Hellstrom
Cc: Dave Airlie
Cc: Peter Jones
Cc: Andrew Morton
Cc: Benjamin Herrenschmidt
---
v2 - rebase after drop of patch 1
Currently vesafb/efifb/... is kicked when hardware driver is registering
framebuffer. To do it hardware must be fully functional, so there's a short
window between start of initialisation and framebuffer registration when
two drivers touch the hardware. Unfortunately sometimes it breaks nouveau
ini
https://bugs.freedesktop.org/show_bug.cgi?id=27603
--- Comment #4 from Xavier 2010-04-12 14:59:07 PDT ---
You have to go to the main page to find the git and http URL :
http://repo.or.cz/w/mesa/mesa-lb.git
(you can find this link on the first line of each git page.
Then try the stable branch.
I
Andy Isaacson wrote:
What version of libdrm-nouveau and xserver-xorg-video-nouveau do I need
in order to run nouveau on 2.6.34-rc3 and later?
On Slackware 64-current using unmodified 2.6.34-rc3 with libdrm-2.4.19 and
xf86-video-nouveau pulled from git commit
2462b417fc550b71f021ca9736808f8f
Andy Isaacson wrote:
What version of libdrm-nouveau and xserver-xorg-video-nouveau do I need
in order to run nouveau on 2.6.34-rc3 and later?
On Slackware 64-current using unmodified 2.6.34-rc3 with libdrm-2.4.19 and
xf86-video-nouveau pulled from git commit
2462b417fc550b71f021ca9736808f8f
On Tue, Apr 13, 2010 at 06:28:21AM +1000, Dave Airlie wrote:
> On Mon, 2010-04-12 at 13:34 +0200, Marcin Slusarz wrote:
> > On Mon, Apr 12, 2010 at 09:54:28AM +1000, Dave Airlie wrote:
> > > On Sat, 2010-04-10 at 21:55 +0200, marcin.slus...@gmail.com wrote:
> > > > fb_do_apertures_overlap is return
On Thu, Mar 04, 2010 at 10:18:03AM -0800, Linus Torvalds wrote:
> (II) NOUVEAU(0): [drm] nouveau interface version: 0.0.16
> (EE) NOUVEAU(0): [drm] wrong version, expecting 0.0.15
> (EE) NOUVEAU(0): 879:
So I've tried reading the thread and haven't found the answer to this
questi
On Mon, 2010-04-12 at 13:34 +0200, Marcin Slusarz wrote:
> On Mon, Apr 12, 2010 at 09:54:28AM +1000, Dave Airlie wrote:
> > On Sat, 2010-04-10 at 21:55 +0200, marcin.slus...@gmail.com wrote:
> > > fb_do_apertures_overlap is returning wrong value when one aperture
> > > is completely whithin the oth
On Mon, 12 Apr 2010 12:50:13 +0200
Marcin Slusarz wrote:
> I'm not aware of any trick to make both nv and nouveau working.
> Maybe there should be a way to prevent nv (and vesa, but not
> fbdev) from loading when KMS is in use?
Yeah, there was a brief discussion about that recently:
http://peopl
Changes in v2:
- Unmap buffers we mapped, avoid assertion
- Silence warnings
This patch causes libdrm, when NOUVEAU_DUMP=1 is set, to write the
pushbuffer to stdout instead of submitting it to the card.
renouveau-parse can then be used to parse it and obtain a readable
trace.
This is very useful
This patch causes libdrm, when NOUVEAU_DUMP=1 is set, to write the
pushbuffer to stdout instead of submitting it to the card.
renouveau-parse can then be used to parse it and obtain a readable
trace.
This is very useful for debugging and optimizing the Gallium driver.
---
nouveau/nouveau_private
https://bugs.freedesktop.org/show_bug.cgi?id=27603
--- Comment #3 from Alex Buell 2010-04-12 08:26:00
PDT ---
(In reply to comment #2)
> I think it could work with that branch :
> http://repo.or.cz/w/mesa/mesa-lb.git/shortlog/refs/heads/stable%23new_2d
> which should be merged some day.
I'm hav
https://bugs.freedesktop.org/show_bug.cgi?id=27455
--- Comment #6 from Michael Schmitt 2010-04-12
07:54:32 PDT ---
Created an attachment (id=34912)
--> (https://bugs.freedesktop.org/attachment.cgi?id=34912)
dump in singleuser mode
Sorry it took me so long to report back.
As asked on IRC I did
https://bugs.freedesktop.org/show_bug.cgi?id=27603
--- Comment #2 from Xavier 2010-04-12 07:48:24 PDT ---
I think it could work with that branch :
http://repo.or.cz/w/mesa/mesa-lb.git/shortlog/refs/heads/stable%23new_2d
which should be merged some day.
--
Configure bugmail: https://bugs.freedes
https://bugs.freedesktop.org/show_bug.cgi?id=27398
--- Comment #4 from Pavel S. 2010-04-12 07:37:45 PDT ---
> In the meantime, it'd be very useful to grab a mmio-trace of the nvidia binary
> driver initialising your displays as another data point.
I sent a mmiotrace some weeks ago the the email
https://bugs.freedesktop.org/show_bug.cgi?id=27603
Alex Buell changed:
What|Removed |Added
CC||alex.bu...@munted.org.uk
--- Comment #1 fro
https://bugs.freedesktop.org/show_bug.cgi?id=27603
Summary: [nouveau] Celestia 1.6.0 crashes with
nv04_surface_copy_swizzle assertion
Product: Mesa
Version: unspecified
Platform: x86 (IA32)
OS/Version: Linux (All)
S
On Mon, Apr 12, 2010 at 09:54:28AM +1000, Dave Airlie wrote:
> On Sat, 2010-04-10 at 21:55 +0200, marcin.slus...@gmail.com wrote:
> > fb_do_apertures_overlap is returning wrong value when one aperture
> > is completely whithin the other. Add generic ranges_overlap macro
> > (probably kernel.h candi
Marcin Slusarz wrote:
Ok, let's CC nouveau list back.
On Mon, Apr 12, 2010 at 12:31:58PM +0200, Didier Spaier wrote:
One thing I didn't check before sending my last mail: can I go back
to console mode after having started X with say, the nv X module ?
Unfortunately this doesn't work: be it fro
Ok, let's CC nouveau list back.
On Mon, Apr 12, 2010 at 12:31:58PM +0200, Didier Spaier wrote:
> >> One thing I didn't check before sending my last mail: can I go back
> >> to console mode after having started X with say, the nv X module ?
> >>
> >> Unfortunately this doesn't work: be it from Flux
26 matches
Mail list logo
