Home Phoronix Phoronix Forums X.Org Videos From FOSDEM 2008

Radeon IRC Logs For 2009-6-10

Search This Log:


stikonas: MostAwesomeDude: I disabled register 0x4010 in glisse's DDX and 0x4010, 0x4014, 0x4ea0, 0x4ea4 in gallium driver
stikonas: now ogl programs output some mismatch errors: http://pastebin.ca/1454980
stikonas: but I already see some rendering instead of black screen
agd5f: stikonas: you'll also have to adjust the command buffer counts to account for the removed regs
mcgreg: hi
mcgreg: hmm after I compiled mesa from git topday and ran "glxgears" just for fun - it ended with a not funny cold reboot
osiris_: airlied: any luck with this makeCurrent bug?
MostAwesomeDude: stikonas: Alrighty, I can fix that on my end.
MostAwesomeDude: Heh.
MostAwesomeDude: stikonas: Thanks for finding those regs. I'll comment 'em out for now.
MostAwesomeDude: MSPOS will be needed later; SRC_PIXEL_LTE_THRESHOLD, not so much.
mcgreg: is "/usr/lib/libglut.so" a library from mesa?
mcgreg: and /usr/lib/libGLw.so
dileX: mcgreg: depends on your build-options of mesa (--enable-xxx --disable-yyy) and your $prefix
mcgreg: getting surprisingly such a message :
mcgreg: ldconfig: /usr/lib/libglut.so is not an ELF file - it has the wrong magic bytes at the start.
mcgreg: ldconfig: /usr/lib/libGLw.so.1.0.0 is not an ELF file - it has the wrong magic bytes at the start.
dileX: mcgreg: what says 'file /path/to/$libname'?
mcgreg: /usr/lib/libGLw.so.1.0.0: data
mcgreg: /usr/lib/libglut.so.3.7.1: data
dileX: sounds weird
dileX: $ file /usr/lib/libGL.so.1.2
dileX: /usr/lib/libGL.so.1.2: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, for GNU/Linux 2.4.20, stripped
MostAwesomeDude: mcgreg: Something wrecked your glut.
mcgreg: I am doing a "git pull" on my mesa git tree everyday and it started today. well, I will reinstall it
mcgreg: ahhh -> /usr/lib/libglut.so.3.7.1: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped
mcgreg: better now
dileX: the winner of today is...
mcgreg: btw, what is the redbook demo and where is it installed by default?
mcgreg: it's not in my default path
stikonas: mcgreg: it is in mesa sources and is not installed (mesa/progs/redbook/)
mcgreg: so this "redbook" is a tool itself but a collection of tools?
dileX: mcgreg: here you find more info for testing (& benchmarking GL apps) .
mcgreg: so this "redbook" *isn't* a tool itself but a collection of tools? <-- corrected
MostAwesomeDude: Well, redbook is the collection of sample programs from the Red Book.
MostAwesomeDude: (The Red Book is a massive OpenGL guide.)
dileX: MostAwesomeDude: you mean a "paperweight" :-)?
nanonyme: glisse: Is KMS+ttm supposed to be available in your branch on a PowerPC target?
glisse: nanonyme: won't work
nanonyme: :/
nanonyme: I guess I don't bother compiling this kernel then. :)
glisse: we will fix it to work on ppc at some point
nanonyme: Yeah, my laptop which has an r300 just happens to be PPC. :P
nanonyme: Meaning I guess I won't get to try the KMS+ttm after all.
nanonyme: (At least for a while)
nanonyme: Desktop which is x86_64 has rv670. :) Bad combinations apparently driver-compatibility wise. ^^
MostAwesomeDude: glisse: I assume that you and Thomas are aiming for the merge window when it opens next week?
glisse: MostAwesomeDude: Thomas should post the ttm patch today
glisse: i will post the radeon patch right after
glisse: then Dave will prepare a tree for Linus to pull if no objections are formulated
MostAwesomeDude: Woot.
MostAwesomeDude: How much stuff remains for KMS+GEM r600?
glisse: not that much
MostAwesomeDude: Sweet.
glisse: but i have to do benchmarking with AMD for bo move
glisse: i think tomorrow i will work on getting r6xx/r7xx working with memcpy bo move
glisse: ie dead slow memory management
glisse: of course there is also the cs stuff
glisse: i am finishing up r3xx/r5xx cmd checking today
glisse: sadly now i refuse some quake3 rendering have to track down why
MostAwesomeDude: Alright. stikonas reports that I only need to disable MSPOS and the PIXEL_LTE_THRESHOLD to get your kernel working.
glisse: what is pixel_lte ?
MostAwesomeDude: Pixel clamps during blend, on r500.
MostAwesomeDude: We normally set the first one to 0x0, and the second one to 0xffffffff.
glisse: RB3D_BLENDCNTL ?
stikonas: MostAwesomeDude: but glxgears still doesn't work for me, though dmesg does not report any errors
MostAwesomeDude: stikonas: Which chipsets?
glisse: okay they are safe reg
MostAwesomeDude: glisse: 0x4ea0, 0x4ea4
stikonas: infamous Xpress 200m RS480
MostAwesomeDude: Safe, but really shouldn't be needed.
MostAwesomeDude: stikonas: Fragment shaders are broken on that chipset. I'll fix it at some point.
stikonas: ah, ok
MostAwesomeDude: ("Some point" isn't as far away if people will actually test. :3 )
nanonyme: MostAwesomeDude: I'd most def test if anyone gave me anything to test. ^^
MostAwesomeDude: nanonyme: Just wait a bit. :3
nanonyme: I know... I was just waiting towards checking out the new code with this r300. :)
nanonyme: But yeah, I'll wait.
MarcOChapeau: MostAwesomeDude: do you consider nexuiz to be a good base for tests ? it seems to make use of a lot of features for a native linux 3d app ...
MostAwesomeDude: MarcOChapeau: Yeah.
MarcOChapeau: MostAwesomeDude: do you know of a set of time demos out there to run on nexuiz that would be interesting to use ?
MostAwesomeDude: MarcOChapeau: Not really.
MarcOChapeau: ok I'll build some of my own :)
osiris: glisse: did you encounter any bugs with indexes being bigger then total vertex num or this patch is just in case?
glisse: osiris: future cs will reject cs if you don't set this reg properly
osiris: glisse: ok, why don't you use OUT_BATCH_REGVAL?
glisse: osiris: i copy pasted first i had :)
glisse: things
osiris: glisse: you could also enable it for non KMS, just in case
osiris: glisse: also the num_verts doesn't hold number of vertices in vertex buffer actually - it's the number of elements for this case
glisse: hhhhhmmm
osiris: glisse: rmesa->radeon.tcl.aos->count is holding the value you're looking for
osiris: glisse: or rmesa->radeon.tcl.aos[0].count for better understanding
osiris: glisse: shouldn't you also increase the dword count for rcommonEnsureCmdBufSpace call?
glisse: 64 should be more than enough already
glisse: how i get fps under quake ?
osiris: glisse: I don't think so. there could be maximum 16 vertex attributes so r300EmitAOS would use 93 dwords by itself
osiris: glisse: no idea
hifi: glisse: original?
hifi: something like cl_fps cl_showfps or similiar
glisse: cg_drawFPS here
hifi: ah
glisse: osiris: damm i trusted vbload desc which ended up at 11
osiris: glisse: vbload?
glisse: packet3
spstarr: DRM support for the Radeon R6xx/R7xx graphic cards
spstarr: 2.6.30
spstarr: glisse: get a Fedora account! :-)
glisse: spstarr: haven't pushed anythings in fedora yet :)
spstarr: Fedora 12 (rawhide) is open for business
spstarr: :)
glisse: i know, i need to learn how to push things
spstarr: airlied can help you and others too
glisse: so cmd checking doesn't seems to impact performance
glisse: well bigger bottleneck are likely hidding the cost
osiris: glisse: yeah, probably the instant flushes are the biggest perf hit
glisse: osiris: i think right now bottleneck isn't at all in gpu side
osiris: it isn't actually a GPU side, we force GPU to flush too often
glisse: my guess is we are submitting way too much way too small cs (especially the ddx), memory manager is moving in&out way too much things, we are waiting too much in userspace
glisse: osiris: for me this is GPU side as it lead to GPU slowdown
glisse: i am pretty sure our biggest bottleneck isn't gpu as we perform lot worse than dri1 and dri1 trigger as much gpu flush as we do today
osiris: oh, I thought you were talking about dri1
glisse: for dri1 biggest bottleneck is likely the amount of memory we move in & out
glisse: current memory manager politic is not very clever i think anyway soon it will be time to profile all this
osiris: glisse: I've just hit a hang that neither gpu reset or radeon drm module reload can fix
osiris: glisse: vbetool post helps
spstarr: glisse: http://www.phoronix.com/scan.php?page=news_item&px=NzMxOA
spstarr: this means _you_ :-)
glisse: spstarr: i posted radeon kms patch on lkml
spstarr: :)
glisse: depending on feedback it will enter or not 2.6.31 as a staging driver
spstarr: glisse: im ready to test this on r6xx for 2D
Zajecx: is this easy to explain why KMS needs MM?
Zajecx: i don't see relation...
spstarr: glisse: this will hopefully merge for Mesa 7.6 development?
glisse: spstarr: hopefully
spstarr: ya i see no comments on the patch yet
libv: Zajecx: this is another tradition in X. Logic relationships are inversed simply because of political agendas
glisse: Zajecx: in kms there can be several program using the gpu so they have to share memory and the easiest way to share memory in transparent fashion is memory manager
soreau: libv: Is there really that much politics in this specific community? bad politics, the kind that cause needless problems?
mjg59: soreau: No
libv: soreau: spend some time in it, and compare over a bit of time, and you'll get a very definite answer
soreau: how vague
mjg59: libv has beliefs about certain aspects of design that don't match up with most of the other developers. He sees this as being driven by politics rather than by technical disagreement.
libv: soreau: do you want me to spend ages of time explaining the ins and outs? i sadly don't have time for that today
mjg59: soreau: There's some backstory examples on libv.livejournal.com
libv: mjg59: technical disagreement which gets resolved in the direction i was talking about, behind my back, with me sitting there holding the joker.
soreau: libv: Sorry, I was only trying to better comprehend your statement. I understand logical things much better than politics
libv: soreau: so do i, sadly.
soreau: heh
soreau: As I understood it, a full fledged memory manager is required for several different tasks, namely kms and dri2
libv: soreau: just like acceleration is required for kms?
mjg59: soreau: You could implement kms without a memory manager, but it's rather less featureful
Wizzup: I am a bit puzzled, the 'internets' tells me radeon supports 3560, for 3d, but someone in here told me it didn't work for 3d. I'll just TIAS. :)
otaylor: mjg59: and rather more complex to deal with making sure that the frame buffer you are scanning out is where you think it is
libv: mjg59: name a feature that modesetting then would lack.
libv: otaylor: why do you need to know this if the only thing you are doing is just scanning out the framebuffer?
stikonas: Wizzup: it is *very experimental* and cannot render more OpenGL than a square. But 2D and XVideo is supported.
mjg59: libv: Framebuffer resizing on Intel springs to mind
Wizzup: stikonas: I see. Ok. Thanks :)
libv: mjg59: if modesetting only was needed, and nothing else is happening on the graphics hw except something writing into the fb from the cpu from time to time, why would that require a full featured memory manager?
spstarr: Wizzup: the 2D uses 3D engine
libv: mjg59: now, stop discounting everything i say with "paranoia" and "bullshit" before you listened or tried to understand any of it.
otaylor: libv: well, I guess I have trouble explaining why using a memory manager for the front buffer is a good idea, if you don't accept that using a memory manager for buffers in general is a good idea
mjg59: libv: Well, sure, if you're not interested in using the 3D engine at any point, you could manage that. Porting vesa to KMS wouldn't benefit from a memory manager.
Wizzup: spstarr: Okay. Thank you
libv: otaylor: i don't accept a singular dependency of modesetting on a memory manager.
otaylor: libv: the issues are largely the same for all buffers
libv: otaylor: when there are other users of the fb, then you need a memory manager
libv: and then, and only then, should modesetting depend on such a thing.
otaylor: libv: since when have we only had one user of the frame buffer?
libv: this is the proper logical relationship
libv: no mashing it all together
libv: otaylor: fb, shadowfb, no accel at all.
libv: otaylor: vt
MostAwesomeDude: libv: Shatter without memory management is incredibly impractical on any driver besides vesa.
libv: you know, useful things that actually can be depended upon more of the time
soreau: libv: So what about dri2? Could this be possible without the memory manager? Also, what about slightly more complex operations like compiz blur? it used to work with fglrx and now only on nvidia afaik
libv: soreau: does modesetting depend on dri2?
otaylor: libv: not understanding you - we shouldn't have a memory manager, because it's possible to configure a system in a way that only one entity touches the frame buffer, even though that's not remotely the normal case?
soreau: nfc
mjg59: If all you want is an unaccelerated framebuffer, then yes, KMS obviously doesn't need to care about memory management
soreau: libv: I thought if you're using dri2, you're using kms.
mjg59: But that's an uninteresting observation
otaylor: also thinks that it's pretty obvious that if you have a memory manager, then the kernel/kms should treat the scanout buffer as a buffer, not as a video ram address
libv: otaylor: let's turn this around: are you saying that anything less than a full compiz desktop is usless?
libv: otaylor: note the if that you put there.
libv: _if_ you have a memory manager.
libv: this is indeed the proper logical relationship
libv: which is what i have been saying for the last ten minutes
otaylor: libv: I certainly believe that we should make our architectural decisions for contemporary usage patterns
libv: there is no dependency
MostAwesomeDude: I recall Linus asking that no performance regressions should be suffered because of kernel-side MM. No EXA would probably be considered a performance regression.
otaylor: libv: and treat the simple cases as simple special cases
soreau: libv: From my user POV, I believe that every aspect or potential feature of any hw should be exploited by the driver
soreau: MostAwesomeDude: s/No/Now?
libv: soreau: well, depends on what you want to achieve and how stable and managable you want things to be
soreau: libv: I just want compiz blur to work on the open radeon driver.
soreau: (without falling back to sw rendering)
MostAwesomeDude: soreau: No, I mean that Linus agreed that KMS was necessary, but he didn't want to break backwards compat, or make things suck for users.
soreau: MostAwesomeDude: So your saying EXA is at the expense of kernel performance? forgive me if I'm way off :p
MostAwesomeDude: soreau: No, but if we introduced KMS without some way to do userspace acceleration, it would be bad.
MostAwesomeDude: And EXA requires pixmap management.
glisse: MostAwesomeDude: actually with kms you breakbackward compat
glisse: there is no way to fix old userspace into understanding that it shouldn't mess with the hw
glisse: well you could painfully catch mmio write from userspace and trick it into thinking that it does the op while you are doing it
glisse: but i allmost need a gpu emulator in kernel :)
glisse: it
gadnio: hi, folks. i have an ati r700 (radeon hd 4800) card and i'm interested in the open source driver progress. i'd like to join forces with you, if you like. the downside is, i don't have any driver development experience...
gadnio: so if you want help and are willing to mentor me, at least from the start, i'd be glad to join
agd5f: gadnio: decide what part you are interested in and start reading code and docs
gadnio: agd5f: something easy for a start?
gadnio: i'd like glsl, but it's a lot of reading
otaylor: gadnio: how experienced are you with gl?
simplexe: otaylor: >> gadnio say: i don't have any driver development experience...
gadnio: none :)
gadnio: but i'd like full 3d accel on my desktop, so i'd better learn it
otaylor: simplexe: that's different from not having any gl experience
gadnio: anyway, that's not an easy task for a beginner: i think besides the ati docs, i'd need the whole glsl spec read, and possibly llvm stuff
otaylor: gadnio: Hmm, then you have a long way to go. :-) But basically, you are going to have to get things built and running first in there current state, which will take a better part of a week.
phoenix64: wasn't glsl only planned on gallium3d? and quite far away for r700? :D
nanonyme: phoenix64: Can be done on classic Mesa too with KMS+mm as far as I've understood.
gadnio: otaylor: doh, that sounds encouraging :)
otaylor: gadnio: then, really, *nothing* works (except from very test programs) for r700 3d, so you won't have to go far to find something that you could fix
pkt: otaylor: did you write the agp suspend/resume fix?
gadnio: otaylor: let's start with sth easier then :)
gadnio: so i can actually learn how to do driver development, see what's permitted, styles, etc.
gadnio: let's say, kms for start
gadnio: it's marked as TODO on the http://www.x.org/wiki/RadeonFeature list
gadnio: i have a rhd card, so i could start (there were some things on the ati docs about modesetting)
nanonyme: I got the impression it was more stuck on the memory manager side.
nanonyme: KMS sorta works.
gadnio: okay, so it needs fixing more than starting from scratch then
gadnio: which is nice, 'cause i won't get stuck with garbage design issues
nanonyme: Not really. It mostly just means writing memory manager code instead of modesetting code...
nanonyme: glisse could probably give you a direction if you're interested in that area.
nanonyme: (Considering it's on his TODO list :)
gadnio: nanonyme: this sounds nicer than glsl, at least it's there :)
nanonyme: What is where? o.O
gadnio: at least most of the code is inside, that's my expectation
gadnio: and i don't have to do a design before the implementation
gadnio: which leads to disasters if one doesn't understand what he's designing :)
nanonyme: I didn't say most of the code was inside. :)
nanonyme: I don't know if r6xx/r7xx memory management has even been started, glisse would know.
gadnio: nanonyme: ok, is he here now? he's not responding personal messages
Quinton: I have a native resolution of 1680x1020 and the following links prove something is wrong. http://pastebin.com/m3fc26902
Quinton: http://pastebin.com/m51cbc975
nanonyme: gadnio: He's on the channel, other than that, no idea.
agd5f: Quinton: the driver isn't able to get an edid for your monitor, so it just adds the default modes
Quinton: agd5f, how exactly do I enable it to reach 1680x1050?
agd5f: Quinton: xrandr --newmode and xrandr --addmode
agd5f: Quinton: http://wiki.debian.org/XStrikeForce/HowToRandR12
agd5f: Quinton: xrandr --newmode "1680x1050" 146.25 1680 1784 1960 2240 1050 1053 1059 1089 -hsync +vsync
agd5f: xrandr --addmode DVI-1 "1680x1050"
agd5f: xrandr --output DVI-1 --mode "1680x1050"
agd5f: you may have to tweak the mode depending on what your monitor likes
Quinton: agd5f, so I just terminal that?
agd5f: yes
Quinton: agd5f, addmode command not found
agd5f: Quinton: xrandr --addmode
agd5f: Quinton: those are 3 separate commands
nanonyme: agd5f: Btw, which OS/distro do you use for driver development?
agd5f: nanonyme: mostly ubuntu
Quinton: agd5f, it says 1680x1050 exceeds my screen size limit
agd5f: Quinton: you'll need to add a virtual line to your config and restart X. see that link I posted
Quinton: agd5f, I will try =p
Quinton: agd5f, I need to place outputs in a virtual screen?
agd5f: Quinton: you just have to pre-allocate a larger front buffer
Quinton: agd5f, Your losing me.
nanonyme: Right, will keep that in mind while testing.
agd5f: Quinton: the driver has to pre-allocate enough framebuffer for the largest desktop you plan to use.
Quinton: agd5f, I have no idea how to do that, I would love to but the tutorials on x strike confuse me.
agd5f: it's sized based on the modes from your monitor. however, if you want to use a larger size, you'll need to tell it so using the virtual line
agd5f: Quinton: you're right. see section II.5.
agd5f: in your case it would be Virtual 1680 1050
Quinton: agd5f, all of them commands are not found
agd5f: Quinton: the virtual line goes in your xorg.conf
Quinton: agd5f, If I do this you realize I will mess something up. lol
nanonyme: Quinton: It's not like messing up xorg.conf has ever eaten anyone's kitten. :)
Quinton: ...
jcristau: hmm. kittens. yummy.
nanonyme: That is, it doesn't break anything and playing around with it is somewhat educative. ^^
nanonyme: (Break permanently anyway)
Quinton: I have never added a line or even been in xorg, I just got fedora and the only things I need to do is enable resolution and 5.1 surround
nanonyme: Make a backup of it and you're completely safe. :) At worst you just won't get X.
TCW: Quinton, sounds like an excuse :)
Quinton: I have never used Fedora before.
TCW: oh oh, another excuse :)
Quinton: I am a windows user, it makes this all very confusing.
TCW: oh damn it, the next excuse! *lol*
TCW: Quinton, what is so confusing?
nanonyme: Quinton: Mostly if you make a mistake, it gives you a non-graphical login that you can use to copy the backup in place. :p
nanonyme: It cannot go badly wrong.
Quinton: TCW, I do not even know how to access Xorg let alone add a line for resolution.
Quinton: I love the OS, I will just need a bit of help getting its basics working.
mcgreg: Quinton: well you will finally learn how an operating system works :)
TCW: Quinton, then ask the right questions... or better, learn how Linux works in general, and fedora specifically... join #fedora, as most stuff you may want to ask is off-topic here
Quinton: TCW, I was on topic, I wanted to know how to enable a larger resolution.
TCW: Quinton, that was a general statement from me, not in that paticular case
Quinton: TCW, and the only thing I need to do now is make my maximum resolution higher than 1680x1050 and I will be fine.
TCW: Quinton, fine... and you know noe how to do that? :)
TCW: s/noe/now/
Quinton: TCW, Well I have added 1680x1050 but my maximum y resolution is lower than 1050 its 1024
TCW: Quinton, huh? O_o What strange display has 1680x1024?
dileX: 16:10
nanonyme: Quinton: Btw, one good place to find "tutorials" is doing Google searches. Like googling for "xorg.conf virtual" yields actual xorg.conf's for people. :)
TCW: Quinton, in other words... I may got you wrong, rephrase please :)
TCW: dileX, that would be 1680x1050 and not 1024
nanonyme: 8/5, seems.
TCW: *scratches*
nanonyme: So yeah, should be 16:10.
nanonyme: Oh, wait a minute.
Quinton: TCW, Anybody can go to google and usually become confused. But people come to XCHAT help chat for help do they not?
nanonyme: TCW: You're right, I made a typo. :p
TCW: anyway... I am not in the mood to calculate :) let's say I have never seen ANY display with that native resolution :)
Quinton: TCW, I had said I need resolution 1680x1050 and the Y resolution can only max at 1024 and it needs to max at 1050
dileX: TCW: might be x1050, maybe 1600 (than 1680). not sure
TCW: Quinton, I did not ask you to use google, but I agree with that anyway. If you are confused, don't whine around, ask a specific question, give us a chance to help!
TCW: dileX, see... whatever ;)
nanonyme: Quinton: I didn't tell you to just Google, I merely told you that you can find neat working snippets for xorg.conf by using it.
nanonyme: Imo might be even better than the manuals.
dileX: (II) RADEON(0): Not using default mode "1680x1050" (width too large for virtual size)
nanonyme: (Since Google results are real-life situations)
Quinton: TCW, so far I have added the 1680x1050 resolution and I can choose it under (display preferences) HOWEVER It warns me that my maximum resolution can not go that high.
TCW: Quinton, don't use display preferences for the moment, use "xrandr" as you have been told
nanonyme: How about pastebinning your current xorg.conf so we'll see what exactly you've done thus far? :)
TCW: Quinton, xrandr is a command line tool to set display specific stuff
Quinton: TCW, xrandr added that to the preference list.
TCW: nonwhat a revolutionary idea! ;)
TCW: nanonyme, even
TCW: Quinton, so what?
Quinton: TCW, I was as specific as I could be...
Quinton: TCW, I simply need to make the Maximum resolution possible 2048x1152 so it will allow 1680x1024 as my size. i do not know how to do that
agd5f: Quinton: did you add the virtual line to your config?
TCW: Quinton, second try: Just use xrandr for now, nothing else, paste your xorg.conf file to a paste service (like http://paste.debian.net), and why the hell 2048x1152?
Quinton: agd5f, I never understood how.
TCW: Quinton, damn it! Then ASK!
nanonyme: agd5f: Hmm, another question: does the redbook hello work for you correctly with r6xx-rewrite?
Quinton: TCW, I guess I could set the max to 1680x1050 and as the default?
nanonyme: (If you've tested)
TCW: Quinton, I have no idea what you are talking about... why don't you just do what someone told you to do? Why don't you ask if something is noct clear enogh for you? Why do you insist on some strange assumptions?
Quinton: TCW, How do I access Xorg.conf
otaylor: pkt: I wrote *an* agp suspend-resume fix
agd5f: Quinton: open /etc/X11/xorg.conf in an editor and add a virtual line as per the page I posted
nanonyme: You do need to use sudo/su though since it's only writable by root.
agd5f: nanonyme: the clear code is disabled so it won't draw the background, just the white square
TCW: Quinton, not access, edit! Next, you need to be (or get) root to edit that file. Next, use whatever editor you are comfortable with. ANy questions regarding all this?
pkt: so you believe there are several problems in this area?
nanonyme: agd5f: It doesn't draw the square properly for me.
pkt: (there is at least one more since my resume still doesn't work)
Quinton: TCW, upon opening a selected file in the text editor /etc/X11/xorg.conf loads a blank pad, no typing
Emme_NK__: Quinton: could you run "grep -i virtual /etc/X11/xorg.conf" ?
TCW: Quinton, oh... and the file we are talking about has the path /etc/X11/xorg.conf
pkt: I 'm considering debugging the problem myself and I wondered if you have a list of places to look
nanonyme: agd5f: http://koti.kapsi.fi/nanonyme/hello.png there's random stuff on the square too always. Is that the expected result?
otaylor: pkt: there may be many issues in this area, dependent on particular hardware
Emme_NK__: and tell us the result
Quinton: Emme_NK__, it loads nothing
otaylor: pkt: the fix I contributed was was fairly general across hardware but was specifically about reenabling AGP after resume; if y our system doesn't resume at all, that's something different
Emme_NK__: ok, then there's not yet any "Virtual" value there...
agd5f: nanonyme: sometimes works sometimes not
pkt: oh, so the problem in your case was that agp was just not enabled on resume?
Quinton: Emme_NK__, so how would I access the config to add the value?
nanonyme: agd5f: Never on the first run for me. Only after it.
Emme_NK__: Quinton: do you have KDE or Gnome?
pkt: I guess hardware specific will mean each will get to fix their own :(
nanonyme: (Hmm, actually the last commit changed it. Now it works different on about every run)
otaylor: pkt: well, if it's something that the developers have access to, it's more likely to get fix
otaylor: ed
nanonyme: agd5f: I guess I'll keep away from testing until the clear code gets finished then.
Quinton: gnome I believe.
Emme_NK__: then try "gksudo gedit /etc/X11/xorg.conf"
Emme_NK__: it should ask for your password, then open an editor window
Quinton: Apparently I am KDE
Emme_NK__: then "kdesu kate /etc/X11/xorg.conf" (If I'm not mistaken)
Quinton: incorrect.
otaylor: pkt: I know there is some problem someone was having with an integrated chipset on here recently
pkt: I have IGP too (Mobility 9600)
Emme_NK__: Quinton: What's incorrect?
Quinton: Emme_NK__, the code did not gather confid
nanonyme: Emme_NK__: desu? :3
otaylor: pkt: if it's an IGP, it might be the same issue. does the display come back as garbled after resume?
Emme_NK__: Then I don't know the current KDE-get-root-privileges-graphically tool :(
pkt: it doesn't come back at all
Quinton: Emme_NK__, it's ok, you have been a lot of help either way.
Emme_NK__: Quinton: just "sudo kate /etc/X11/xorg.conf"?
pkt: it looks like the whole PCI bus freezes or something because not even ssh works
pkt: so it will have to be solved mostly via meditation
Quinton: Quinton is not in the sudoers file. This incident will be reported.
Emme_NK__: Quinton: what Distribution?
dileX: pkt: guru meditation (amiga) :-)?
Quinton: Fedora
Emme_NK__: Quinton: hmm, never used fedora. Sorry, but I won't be of much help fiddling with a distro I never used via IRC...
pkt: dileX: In my case that will be a bit difficult since I 'm as far from a guru as it gets ;)
otaylor: pkt: Ouch. I don't have a lot of advice. is it specifically an agp problem?
Quinton: Emme_nk__, does ubuntu have nearly as many problems?
Emme_NK__: Quinton: Ubuntu is cetainly not perfect, but it's getting there :) If you have broadband, just download a live CD and give it a try!
pkt: otaylor: https://bugzilla.redhat.com/show_bug.cgi?id=493626
Emme_NK__: Quinton: I'm using it for years now, I like it
Emme_NK__: BTW: Is someone around to help me debug my bleeding-edge-KMS system in an hour or so? The serial console cable is armed and ready :)
Quinton: Emme_nk__, the new version had major improvement didnt it?
dileX: pkt: not need to be a "guru"
otaylor: pkt: OK, not a agp problem then, since f11 doesn't default to turning agp on
Emme_NK__: Quinton: Every ubuntu release brings improvements, new hardware support, etc. If 8.10 didn't work for you, just give 9.04 a chance
Quinton: I will
Quinton: Uhm
Quinton: emme_nk__ how do you burn an iso on linux? lol
gadnio: Quinton: use k3b
Quinton: gadnio, thanks
Emme_NK__: yes. I have to go now, will be back later...
otaylor: pkt: I'll have to defer to glisse and airlied on this one. Looks like you have lots of good information on that bug report.
Quinton: thanks emme
agd5f: pkt: that's not an IGP chip
pkt: yes, you are right, I was confused
pkt: it is a discrete chip
nanonyme: Emme_NK__: Btw, Fedora doesn't like sudo, you use su there.
nanonyme: (You could technically set up sudo but since you need su for GUI stuff anyway, it's not worth the effort)
otaylor: nanonyme: why do y ou need su for GUI stuff?
nanonyme: otaylor: Well, I'm not sure if it uses su at all, really. Mostly you need root password in Fedora. It has no gksu or gksudo.
nanonyme: You use root password for about everything that requires elevated privileges.
otaylor: nanonyme: you need a root password to run arbitrary commands as root, yes. (Or you have to spend the 15 seconds to set up sudo.)
otaylor: nanonyme: But generally, things that other distros hack with gksudo are done with more appropriate mechanism in Fedora
otaylor: nanonyme: mostly policykit, though consolehelper is still used as well for some things.
nanonyme: Hmm?
nanonyme: takes a closer look at policykit
nanonyme: otaylor: Apparently I got a wrong impression from the Fedora-related newsletters I read about gksudo then.
otaylor: nanonyme: fedora related newsletters?
Emme_NK__: I just assumed fedora uses the sudo-approach, too
otaylor: Emme_NK__: generally, most developers and advanced users set up sudo. But we don't pretend it's an appropriate mechanism for end userse to configure their system
nanonyme: Emme_NK__: It can be made to.
Emme_NK__: yes, I thought it was default, my fault
nanonyme: otaylor: I don't remember exactly the url, it was a long time ago. It was mostly that I got the impression there wouldn't be another tool for the job from those posts... In case policykit can do the job, indeed worth it to set up sudo.
EruditeHermit: hey, how goes the gallium driver?
osiris: agd5f or bridgman: I'm trying to fix non-colored and non-textured primitives, I'm doing it exactly like the doc says to (9.2.2 R5xx accel guide) but it keeps hanging the GPU
airlied: osiris: not sure if my mails made it through, I found the crasher bug (bad linked list impl) but now glean fails with an X error
osiris: airlied: hmm. is it the same error as here http://hifi.iki.fi/autorp-nightly/2009-06-03_23_47/alltests/test_glean__makeCurrent.html ?
osiris: airlied: I think I found the reason of GPU hangs in ut2004 ^^^
airlied: libv: we already have modesetting without a memory manager its called fbdev
osiris: how do I create private repo on fdo?
Wizzup: spstarr: May I ask if ATI/AMD has released specifications of the card we talked about earlier?
jcristau: osiris: http://www.freedesktop.org/wiki/Infrastructure/git/RepositoryAdmin
nanonyme: Unless you were talking about cards very much in the legacy end, answer's probably yes.
spstarr: Wizzup: the HD 3650 yep
airlied: osiris: that error is X crashing
airlied: with my fix for the linked list in the X server we get a bad window error
nanonyme: would prefer X would just always die, never lockup
Wizzup: spstarr: Okay. So 3D supports might be coming in near future?
nanonyme: Wizzup: It's being written.
Wizzup: support*
Wizzup: nanonyme: :-) Nice
airlied: but that is also wrong, I asked krh to have a look and I'll see if I can spend more time today on it
nanonyme: Wizzup: No one knows when it's ready but it's very much a work in progress.
Wizzup: Okay, I'm patient. :)
agd5f: osiris: i dunno. probably some RS magic. maybe you should always set the count to 1 and ignore the values in the frag shader
osiris: agd5f: but I would have to generate a color in VS then (or send it with other vertex attributes for SW TCL path)
agd5f: osiris: or specify it as a fragment constanst
osiris: agd5f: that's what I'm trying to do, but the GPU hangs when RS doesn't get any color or texture (only position vector)
agd5f: osiris: Ah. ok
nanonyme: Hmm, is gltestperf a working benchmark?
nanonyme: (Actually seems there's quite a few benchmarks in the progrs/demos section of Mesa)
airlied: osiris: you have to supply a color or texture do the RS don't you?
nanonyme: I find it kinda odd that only glxgears out of the huge bunch of demos actually gest installed. :)
ajax: real distros package the mesa demos
nanonyme: Right.
ajax: cough, http://kojipkgs.fedoraproject.org/packages/mesa/7.5/0.15.fc11/i586/mesa-demos-7.5-0.15.fc11.i586.rpm
osiris: airlied: according to docs no. also we could render only to depth buffer so we wouldn't need any texture or colors
ajax: i should move those to /usr/lib/mesa or something though, they really don't make sense to keep in /usr/bin
nanonyme: Possibly, yes.
nanonyme: ajax: Maybe a wrapper for them in /usr/bin/ and the executables under /usr/lib/mesa?
airlied: ajax: then you'd have to worry about lib64 :)
nanonyme: Something like mesademos fbo_firecube
ajax: airlied: "worry"
ajax: %{_libdir}
ajax: it's an archful package anyway
airlied: I suppose its not really going toget multilib installed
ajax: people bitch about multilib far out of proportion to how difficult it actually is.
nanonyme: Don't parts of Mesa need to be multilib?
nanonyme: (As in, libGL and so)
agd5f: osiris: could just make sure to always export a color from the VS even if it's just garbage or 0/1/etc.
airlied: ajax: get /usr/demo added to the FHS :)
ajax: nanonyme: yes. and they are.
nanonyme: Right.
osiris: agd5f: yeah I could, but for SW TCL path it would mean bigger vertex size
osiris: and I'm trying to avoid it if possible
agd5f: osiris: could use point/line stuffing to stuff a tex coord
airlied: yeah use GA to stuff one seems like an answer
airlied: if you can get it to work
osiris: hmm
osiris: good idea
nanonyme: Hmm, wish I had a computer on which I could test what fbo_firecube actually does
MostAwesomeDude: osiris: I took that part of the doc to mean that you should specify a color count of 1 and tex count of 0, and then use a constant in the frag shader.
nanonyme: MostAwesomeDude: Btw, do FBO's work with your Gallium yet? :)
nanonyme: (Or are those not included in the stuff Gallium core gives?)
MostAwesomeDude: nanonyme: They *should* but they do not.
nanonyme: Right.
nanonyme: What do you test them with, Mesa demos?
MostAwesomeDude: progs/trivial/clear-fbo
nanonyme: Ah. :3
nanonyme: Lemme see.
nanonyme: is starting to slowly feel stupid: seems enum as return value is pretty normal practise, yet I only bumped into it a few weeks ago
chithead: real men make all functions return void* ;)
nanonyme: :P
nanonyme: I mostly just meant that it's puzzling how much neater enum'd return values are than simply returning a number or using macros. :)
nanonyme: Carry on. ;)
rah: 2 days radeon: introduce kernel modesetting for radeon hardwaredrm-next-merge Jerome Glisse 58 -29/+35269
rah: interesting
nanonyme: That's... big. :>
rah: indeed it is, both literally and metaphorically :)
rah: argh
rah: r6xx-r7xx-support branch of drm no longer compiles
rah: uname -a
rah: Linux myrtle 2.6.30-rah-5 #1 SMP PREEMPT Wed Jun 10 22:05:49 BST 2009 x86_64 GNU/Linux
rah: /usr/src/ati-free/git/drm/linux-core/drm_os_linux.h:36: error: conflicting types for ‘irqreturn_t’
rah: include/linux/irqreturn.h:16: error: previous declaration of ‘irqreturn_t’ was here
rah: kicks miscellaneous developers
rah: The driver is supported automatically in Linux kernel 2.6.30 and newer
rah: hmm
chithead: not the 3d part though
carldani: hi
[Enrico]: btw i've heard that there is a possibility to merge kms in .31 since ttm will be merged too
carldani: how well supported is the Radeon 2100 (onboard graphics of the RS740 chipset)?
rah: chithead: I didn't know there was a 3d part
chithead: carldani: works well, both 2d and 3d if you have at least kernel 2.6.28 and mesa 7.2
nanonyme: rah: Hmm, that irqreturn_t thing is a known issue iirc.
[Enrico]: rah: there is in mesa, but it is not usable really
nanonyme: (or rather, a known change in kernel)
rah: nanonyme: I know it's known
carldani: chithead: neat! thanks for the info.
nanonyme: rah: Also, you shouldn't be compiling r6xx-r7xx-support drm. It's badly out of date.
chithead: rah: if you need only 2d acceleration, then use the in-kernel drm. it supports r600 cards since 2.6.30
rah: nanonyme: I'm just saying: 'Know this! This is known! And you should know to do something about it!'
rah: chithead: does it really?
rah: [22:33] The driver is supported automatically in Linux kernel 2.6.30 and newer
chithead: rah: read any news article about kernel 2.6.30 and you will find it mentioned there
[Enrico]: is waiting gentoo devs to put gentoo-sources-2.6.30 to enjoy new radeon drm support
nanonyme: rah: Well, afaik r6xx-r7xx-support branch is mostly dead. Can't really expect it to compile anymore.
rah: nanonyme: wiki needs updating
nanonyme: (r6xx-r7xx-3d branch on the other paw...)
nanonyme: rah: Wiki always needs updating. :)
rah: good point :)
chithead: do not complain about a wiki that is wrong, fix it yourself instead
agd5f: rah: it's a wiki
carldani: chithead: do I need to compile a special branch of Mesa and x11-video-ati or are the mainline drivers OK?
chithead: this is the whole point of wikis
rah: chithead: who's complaining?
nanonyme: rah: Which kernel version was this again that you got the error with?
chithead: carldani: what is in ubuntu 9.04, fedora 11 or your distro of choice should be ok
rah: hmm
rah: r600_screen.c:176: error: ‘R600_SCRATCH_REG_OFFSET’ undeclared (first use in this function)
rah: nanonyme: 2.6.30
carldani: chithead: great, thanks.
nanonyme: Right.
rah: and I get that with master drm :/
chithead: rah: use in-kernel drm. do not use mesa/drm or whatever
nanonyme: rah: What are you trying to do, exactly?
rah: chithead: but I want a libdrm.so!
rah: nanonyme: run 2.6.30 without regressions :)
rah: ie, working Xv
nanonyme: Run what? :)
chithead: rah: ah. you mean libdrm. a compile fix for 2.6.30 is in master
nanonyme: Ah, right.
nanonyme: I wasn't aware it had regressions.
rah: chithead: that error is from master
nanonyme: I'd file bugs.
nanonyme: Or check bugtracker.
agd5f: rah: there's nothing in libdrm you need over what your distro ships
chithead: rah: you sure that this http://cgit.freedesktop.org/mesa/drm/commit/?id=651e3dc6dd58a79c90db7513ee2fb28360a4560d is included?
rah: agd5f: then why won't it compile?
nanonyme: Hmm, right.
rah: sorry
rah: PEBKAC
rah: it's mesa that won't compile
nanonyme: Heh, I see DRM devs have given up even attempting to keep compatibility hacks inside drm_compat.*. :p
airlied: we've mostly given up on compatibility hacks
agd5f: rah: requires radeon_drm.h from r6xx-r7xx-3d branch of drm in my fdo tree
agd5f: rah: or just define it locally
nanonyme: airlied: Well, yeah. Just noted since that commit added compatibility hacks inside drm_os_linux.h. :)
rah: agd5f: just out of curiousity, is there a reason the file wasn't merged along with the code that depends on it? :)
nanonyme: Soon probably every file in Mesa/drm's linux-core is full of compatibility hacks. :p
airlied: hopefully it dies then
nanonyme: I think it likely does. No wants to maintain such a mess.
agd5f: rah: what do you mean?
nanonyme: This is one single commit though.
agd5f: the file is provided by the drm and used by mesa
libv: airlied: now that is bullshit.
libv: but not that i expected anything else from you
nanonyme: libv: What was? The not using compatibility hacks? Isn't the point that devs do DRM kernel module development in ready kernel trees so compat isn't required?
rah: agd5f: mesa r6xx-r7xx-support depends on ~agd5f/drm r6xx-r7xx-3d?
libv: nanonyme: mashing it all together brainlessly is just bad software development anyway.
chithead: wonders what he has caused by simply pointing at the commit
libv: not that i expect anyone to acknowledge that.
rah: libv: did you make Robocop and Starship Troopers?
agd5f: rah: yes
rah: agd5f: he did?!
rah: cool!
rah: I loved Robocop
libv: nanonyme: and backportability isn't often hard to do when done at the right time (early on)
rah: libv: you da man
rah: agd5f: wiki needs updating :)
libv: nanonyme: but my reply was to something much much earlier
agd5f: rah: yes mesa r6xx-r7xx-support depends on ~agd5f/drm r6xx-r7xx-3
agd5f: d
nanonyme: libv: Right. *shrug*
rah: agd5f: I was joking :)
rah: it was Paul Verhoeven, IIRC, that did those films
nanonyme: Wouldn't know what you referred to then. Personally I think not doing backcompat is fine if it reduces developer effort. :)
nanonyme: Means we get working stuff faster.
libv: nanonyme: it never does mean that
libv: it never reduces developer
libv: effort even
libv: not when you admit to the average lifespan of any code.
rah: kick motherfucking ass
rah: rah@myrtle:~$ xvinfo | head -n 1
rah: X-Video Extension version 2.2
rah: I have Xv without any branches
rah: 'r7xx: Now with Xv as standard!'
rah: I so pleased, I may update the wiki as thanks!
rah: tomorrow..
radiomark: Can I build a more recent Radeon driver on my system, without having to build the whole of X?
nanonyme: You can, yes.
radiomark: So it is possible... I checked out the xf86-video-ati Git repo
nanonyme: What's the problem?
radiomark: can I build using just that? Or do I need some more... I'm getting errors:
radiomark: ./configure: line 23330: XORG_MANPAGE_SECTIONS: command not found
radiomark: and then it fails later on in the make
radiomark: with a, probably more useful error: atimodule.c:39: error: `PACKAGE_VERSION_MAJOR' undeclared here (not in a function)
nanonyme: Which distro is this?
radiomark: Sounds suspiciously like I need something more to build against
radiomark: It's Slackware-current
radiomark: The x server version is xorg-server-1.4.2-
radiomark: Unfortuntately there aren't more recent packages available, but I was hoping to get the Xinerama bugfix which has happened in the radeon driver since then
nanonyme: https://bugs.freedesktop.org/show_bug.cgi?id=9557
nanonyme: Hmm.
radiomark: Thanks, that looks good. I didn't find tha tin my searching
nanonyme: The package name is probably not identical but that seems related.
radiomark: No, that looks promising because that package is not installed
DanaG: oh hey, the radeon KMS PPA.... trying it on an R300 now.
DanaG: Is it supposed to be getting a libdrm version mismatch?
DanaG: says: no.
DanaG: =þ
rah: version mismatches are a good thing
DanaG: radeon.o kernel module version is 2.0.0 but version 1.17.0 or newer is needed.
nanonyme: DanaG: What does the PPA include?
rah: it's feature
nanonyme: libdrm and kernel?
radiomark: nanomyme: and it's built, excellent
radiomark: You guys have done a really great job with this -- the ability to build small portions of X has made things a lot more promising
rah: a few years ago, I used to watch the progress bar on a 30k file download zip across the screen
rah: I thought that was pretty cool
rah: if I wanted to download a CD image, I had to leave it running in the background for days or so
DanaG: libdrm2 2.4.11+git20090606.3d4bfe8c-0ubuntu0sarvatt
DanaG: linux-image-2.6.30-8-generic 2.6.30-8.9kms1
DanaG: gotta' love gpm.
rah: now, I watch the progress bar on a CD image download zip across the screen at the same speed as that old 30k file
rah: one day, compiling the whole of X will take a couple of seconds
rah: kick ass :)
DanaG: oh, and there's no libdrm-radeon.
DanaG: hmm, libdrm base is part of xorg core.... which is currently the xinput2 version.
nanonyme: That sounds like strange divisioning.
radiomark: Unfortunately I still get exactly the same crash with my updated driver :(
radiomark: This is a crash when trying to use Xinerama with a Radeon 7000, is this a no-go?
nanonyme: *shrug* Or maybe it actually isn't.
nanonyme: DanaG: https://launchpad.net/~xorg-edgers/+archive/radeon-kms seems to say drm-snapshot - 2.4.11+git20090604+libdrm-radeon.2cb4c64d-0ubuntu0tormod3
nanonyme: Are you using that or something different?
DanaG: hmm, since xinput2 doesn't fix my >255 keycodes, and doesn't seem to have working mouse in Xorg at all... I'll go back to xinput1.
DanaG: When I built that drm-modules-source, it doesn't even have a "modeset" parameter at all, oddly enough.
DanaG: Oh, I seem to have mixed thjaegar and sarvatt packages... I need to go muck out my packages a bit.
nanonyme: Right, so you are not obviously using stuff from radeon-kms PPA.
DanaG: The correct radeon driver is radeon-rewrite, correct?
agd5f: DanaG: that's mesa
DanaG: er, yeah, that's what I meant.
DanaG: odd... xinput2 isn't seeing the USB optical mouse. I guess I'll just ditch it and go to exclusively radeon-kms PPA.
radiomark: So I get a crash when I use Xinerama, but I get a stacktrace: http://pastebin.com/m5f5ef427
DanaG: hmm, it's giving me "no initial modes"
DanaG: http://pastebin.com/f2 3502ac
DanaG: arfgh
DanaG: stupid slashexec
DanaG: http://pastebin.com/f30f99b89
DanaG: fbset says: 1280x1024-0.
nanonyme: I assume you also have a KMS-aware X display driver.
DanaG: version is "radeon-gem-cs3"
DanaG: "no connectors definitely connected"
nanonyme: Should be the right branch anyway.
DanaG: odd.
osiris: yupi! ut2004 works
soreau: \o/
DanaG: Does it need agpmode?
DanaG: s/it/my radeon/
nanonyme: DanaG: Hmm, that reminds me. Didn't that tormod who just left package nearly all of the things in the PPA? ;)
DanaG: aah, DVI awas on DVI2, not DVI1.
nanonyme: Hmm.
airlied: osiris: nice.
airlied: osiris: btw you got your a/c if you didn't know
osiris: airlied: yeah, I've just started irssi proxy there :)
agd5f: osiris: cool
DanaG: hmm, would having the thing on DVI2 make it break?
DanaG: If I plug it into DVI1, the monitor BLINKS, even at the BIOS screen, until KMS initializes. And it still gets "no modes"
DanaG: dmesg: www.pastebin.com/f4fad9a45
rah: no fbcon :(
DanaG: hmm, now I get this:
DanaG: www.pastebin.com/f4b411828
DanaG: h, and removing "benchmark" is what made that change.
DanaG: Apparently the benchmark thingy... breaks stuff.
DanaG: that was dmesg; this is xorg log: www.pastebinit.com/f675d308e
osiris: airlied: I got one more bo is null error, here's the bt http://pastebin.com/m11138e1a
DanaG: grr, damnit, my home is RO again.
DanaG: http://pastebin.com/f1f77e8c2
DanaG: http://pastebin.com/f1e4cd13f
DanaG: oh, and glxinfo hangs until I SIGQUIT it.
DanaG: oh, and I have it set to EXA, by the way.
DanaG: Same happens with XAA, though.
agd5f: DanaG: XAA doesn't work with kms
DanaG: EXA didn't, either.
DanaG: It loops and spews those errors.
DanaG: Would dynclks be what causes that?
DanaG: srcversion: 31CF938123A91AA4B11D1E9
DanaG: that's from modinfo radeon
DanaG: Hmmm, I wonder what's up with that.
DanaG: anyway, I'm going to shut down in not very long.
DanaG: ... unless somebody has any tips.
agd5f: DanaG: try not setting the dynclks option
DanaG: Okay, just have to reboot.
spstarr: evening bridgman
bridgman: hi spstarr
spstarr: watches the last aircraft warning light switch to night mode (white led flashing to red beacon)
spstarr: as nightfall arrives
spstarr: now red
TCW: Xavier Bestel around?
TCW: airlied, my radeon / mesa crash / segfault issue, you remember? was this thread the one you heard from the problem before? http://lists.freedesktop.org/archives/xorg/2009-May/045640.html
airlied: TCW: it was most spstarr telling me about it crashing on his machine
spstarr: :)
TCW: spstarr, you have that same issue?
spstarr: TCW: newttm + kms has resolved all those issues with my r3xx also airlied's drm changes w/o newttm also resolved them
spstarr: im on a r6xx now but i was able to use the r3xx with compiz fine
TCW: spstarr, ehm... huh? :)
spstarr: which gpu do you have?
TCW: spstarr, I meant... I don't get you
TCW: spstarr, rv530
spstarr: the r3/4/5 are shared code
TCW: I know that... more or less :)
TCW: or at least... I got the impression they have $something in common :)
TCW: eventually brb... I want to try to start compiz again :)
TCW: nice... this time no crash :)
TCW: spstarr, do you know any details? newttm + kms are people?
spstarr: they are projects
TCW: re :)
TCW: crashed again :) normally it crashes and drops me back to gdm the moment compiz is loading, sometimes even not after hours, but this time it was the first time crashing after some minutes...
TCW: spstarr, did you say something after my X session was kicked away?
spstarr: they are projects
spstarr: TCW: what does kernel dmesg show?
TCW: spstarr, in general a segfault at xorg or compiz... this time interestingly nothing
spstarr: type dmesg in gnome-terminal/konsole
spstarr: any drm messages?
TCW: spstarr, I know how to get the kernel messages ;) and as said, this time no errors, but some drm messages... let me paste it
TCW: spstarr, http://paste.debian.net/38679/
TCW: nothing unusual though
spstarr: nothing wrong
TCW: 02:39:39 was the time I did wake the systum up, it was in standby mode for some hours. Roughly an hour later I did start compiz, Minutes later it did crash :)
TCW: spstarr, that's what normally happens http://paste.debian.net/38680/
spstarr: what is in your Xorg.log
airlied: osiris: you going to commit stuff soon :)
TCW: spstarr, I don't have a current one with that error... let me "generate" one :)
spstarr: airlied: glisse is itching to get a Fedora account and add stuff but needs help
TCW: brb :)
TCW: spstarr, pcrap... how long are you here available in the next hour? It does not want to crash right now :)
DanaG: oh yeah, after I disabled the dynclks... Xorg repeatedly started and crashed.
DanaG: This is not the drive that was on; I'll dig up the logs later.
spstarr: TCW: uh huh
airlied: spstarr: why should he bother?
airlied: spstarr: its all going upstream
TCW: spstarr, if you are about to leave soon, I can login / logout some times, I bet it will crash in within 1 minute then
spstarr: airlied: well, assuming he has some things that can't go upstream still?
airlied: he doesn't
TCW: DanaG, dynclks?
DanaG: I had been having command processor hangs ... not ready.... not ready.... spewed out to console.
TCW: DanaG, I c... sounds unrelated to my current issue :)
spstarr: airlied: so when do you plan to merge radeon-rewrite into master? (not that this impacts me anymore)
DanaG: biggest thing I'm waiting for: compiz on rR00.
spstarr: i should start testing r6xx once some more primitive drawing works
airlied: spstarr: when ymself and osiris fix a few more bugs
TCW: spstarr, did you miss my question?
spstarr: TCW: im not leaving
spstarr: airlied: the r6xx/r7xx drm bits are .30 (and now in Fedora rawhide whenever .30 final is built if it's not already done)
airlied: they were already in rawhide
spstarr: so then the only pieces now are r6xx-rewrite in mesa i need?
airlied: since forever
spstarr: oh
airlied: they don't do the 3D drm stuff
spstarr: KMS does not work on my desktop r6xx (it went blank and fails to boot)
airlied: they are only supporting the 2D driver
spstarr: i should test with new kernel however
spstarr: ya 2D works but i can't use 2D on my HD 3650 desktop card (i need to test with newer kernel however)
TCW: brb
spstarr: airlied: testing on the HD 3650 desktop now...
spstarr: hopefully, i just need a new kernel for it
terracon: airlied: just wondering. Is this slated to be fixed in f11 updates . http://rapture.dyndns.org/~greisky/doh.png
airlied: I expect thew new mesa will fix that.
TCW: re :)
spstarr: airlied: its ironic the r3xx laptop screen died just as the final pieces are fixed ;)
TCW: http://paste.debian.net/38682/ <- spstarr, in line 2333 starts the party
spstarr: wonders why his quad box isn't booting .. up
TCW: spstarr, would a xorg with debugging symbols help?
terracon: I guess that's mesa 7.6?
spstarr: TCW: yes
spstarr: that looks familiar
TCW: spstarr, what should I install? Just xserver-xorg-video-radeon-dbg or xserver-xorg-core-dbg too?
TCW: debian packages available with debugging symbols, related to xorg
spstarr: I dont know what version of drm + mesa your using or if they took patches from fedora.. you might be stuck
TCW: spstarr, stuck?! In what regard?
spstarr: as in it might be too old
TCW: too old for what?
TCW: spstarr, and for the version question, everything on 7.4.1
TCW: spstarr, I can have a look in the changelog, if you can give me a hint for what to look
spstarr: TCW: you'll likely have lots of problems you'll need to build from git
TCW: spstarr, lots of problems?
TCW: Always such vague pretenses ;)
spstarr: 2.6.30-1.fc12
TCW: huh?
TCW: I am on 2.6.29 right now, but I can install a 2.6.30 if it would help
spstarr: im testing r6xx KMS right now..
spstarr: airlied: KMS disabled on r6xx?
airlied: spstarr: by default yes
spstarr: oh, ok turning it on...
airlied: on f12 it probably isn't there
spstarr: wasn't sure if you enabled it in .30
airlied: we haven't done any work on f12 yet
airlied: spstarr: its not in .30
airlied: its not upstream at all yet
spstarr: oh
spstarr: ok thats why it doesnt work even if i force it on :)
TCW: xrandr: screen cannot be larger than 2960x1050 (desired size 3280x1050 <- weird... does someone know what that does mean? I have two displays and in the width it IS 2960 pixel
philipjfry: im following the user submitted tips on the wiki to get the radeon driver install and get errors. is there any further documentation for some one new or an alternate method of installation that i cant find?
TCW: soreau, I am here :)
soreau: Is this the correct link for the 'regular' radeon driver? git://anongit.freedesktop.org/git/xorg/driver/xf86-video-ati
TCW: soreau, I got an error, does not look like something is missing to me http://paste.debian.net/38686/
soreau: TCW: You need to install some x m4 package, can't recall the name right off hand..
TCW: but on the other hand... it may indicate I should install libtool :)
TCW: soreau, maybe xutils-dev?
soreau: yea
TCW: soreau, looks good
TCW: ./configure: line 11957: syntax error near unexpected token `XINERAMA,' <- oops?
TCW: ./configure: line 11957: `XORG_DRIVER_CHECK_EXT(XINERAMA, xineramaproto)'
yangman: you're still missing macros
TCW: lets see if "libxmu-headers libxmu-dev libxi-dev libdrm-dev libxfixes-dev libxdamage-dev mesa-common-dev" will help
TCW: and x11proto-xinerama-dev...
TCW: and x11proto-xf86dri-dev... it's a very nice game ;)
soreau: hehe
soreau: TCW: You're almost there but.. you need to make sure to run './autogen --prefix=/usr' after success once before running 'make; sudo make install'
TCW: soreau, last few lines... looks ok to me... sort of http://paste.debian.net/38687/
soreau: By default it will install to /usr/local and wont work
TCW: soreau, how about checkinstall?
soreau: nope
TCW: nope? Why not?
TCW: or dpkg-buildpackage?
soreau: Well if you want to, you can I guess
soreau: No guarantee except if it breaks..
soreau: you get to keep the pieces ;)
TCW: soreau, it is easier to remove that stuff, so I prefer deb packages
soreau: okay
TCW: but then again... I guess there is a make unisntall? :)
TCW: uninstall even
soreau: naturally
TCW: soreau, tha last paste did look ok?
spstarr: flashed all his bioses
soreau: yes, perfect
TCW: ok, make
spstarr: now i have latest ACPI tables and stuff
TCW: soreau, and lots of errors :)
yangman: I recommned letting it install into /usr/local and having X look there instead
soreau: yangman: How do you tell X to look for it there?
yangman: let the distro deal with the system installs. put your own compiles into a separate place
yangman: ModulePath option. cf: http://yangman.ca/xorg.conf
philipjfry: http://pastebin.com/d419a4db8 is where im at with installing the radeon driver
TCW: soreau, so all done, I guess a relogin / X restart is enough?
soreau: Sure
TCW: brb
soreau: philipjfry: The command you're using is looking on your desktop for all folders and trying to .. anyway, that's wrong.
soreau: What are you trying to do exactly?
soreau: Compile dri2proto and drm?
philipjfry: install the radeon driver per the instructions at http://www.x.org/wiki/radeon
soreau: You should really create a directory such as ~/src and then clone everything in there
TCW_: how do I make sure the correct libs / drivers were used? I did follow yangmans suggestion with adding the module path option in the files section
soreau: TCW_: What prefix are the drivers installed to?
TCW_: soreau, /usr/local
soreau: The X log should say which it's using
TCW_: ok
TCW_: (II) Loading /usr/local/lib/xorg/modules/drivers//radeon_drv.so <- ah, fine :)
soreau: TCW_: And is everything working? dri, etc?
philipjfry: ok so i create the src directory, point the terminal to that directory the paste in the code?
TCW_: soreau, dri yes... let me prepare a cigarette first, and then try compiz and... stuff :)
soreau: philipjfry: It's not quite that simple as copy/paste
philipjfry: nuts.
soreau: philipjfry: You would have to change into that dir with 'cd ~/src' then run all the git clone commends
soreau: commands too
philipjfry: yeah, thats what i meant
soreau: All the information is there, but you should have some preliminary understanding of what you're doing
TCW_: soreau, so... compiz is running
soreau: philipjfry: Why are you doing this anyway?
TCW_: no to the slightly harder part... trying to convince the box to crash :)
soreau: TCW_: That's good news, let's see how long it takes to lock up again
TCW_: njow even
soreau: TCW_: Put it through the test!
TCW_: now even better
philipjfry: i have a neuros link and a user said video is tear free with the open source ati driver, http://forums.neurostechnology.com/index.php?topic=10046.0
philipjfry: the proprietary driver sucks
soreau: philipjfry: Which distro?
philipjfry: ubuntu, jaunty
soreau: The radeon driver is already installed by default on most all linux distros
soreau: Jaunty definitely being one of them..
soreau: Which card is this?
philipjfry: radeon 3200
soreau: If you get the open driver working with that card, it would only be for 2D
philipjfry: that would be good enough for flash and video play back though right?
philipjfry: problem is with the link and proprietary driver theres lots of tearing
philipjfry: and the display doesnt fill entirely at 1080p
TCW: soreau, crashed
soreau: philipjfry: Just know you must have everything fglrx related uninstalled before using the open driver
philipjfry: Onboard Video Chipset: ATI Radeon HD 3200
soreau: TCW: Aw man :P
TCW: soreau, I did change to metacity instead of xfwm4... but I think xfce should run with metacity as well... so no change
TCW: soreau, so I guess the same for mesa and dri?
philipjfry: i did, $ sudo apt-get remove --purge xorg-driver-fglrx
soreau: TCW: I wonder what versions of components ubuntu packages uses.. ubuntu is known for patching packages to make them work together better
philipjfry: and said it was not installed
TCW: soreau, you are thinking of installing ubuntu packages here?
soreau: TCW: Nah, but anyway I have to go now
philipjfry: thanks soreau!
soreau: nite
TCW: I think I will play the git-uar game for mesa and dri
TCW: soreau, thx so far
TCW: "The clean Mesa source tree takes about 32MB of disk space. " <- a little bit outdated, isn't it? :)
TCW: $ du -sh mesa/
TCW: 123M mesa/
TCW: one with write access to http://dri.freedesktop.org/wiki/Building here? There is a type (apart from beeing a bit outdated)
TCW: oh... maybe not