EruditeHermit: hey, does the kms driver need any quirks for restoring from suspend?
EruditeHermit: as of now, it is not turning the backlight on
mikkoc: now that xorg-server 1.6.2 is out can someone please fix: radeon_dri2.c:171: error: 'struct
glisse: airlied: is their r1xx,r2xx,r3xx igp system ?
glisse: i thought first igp was rs400
EruditeHermit: glisse: http://en.wikipedia.org/wiki/Radeon_R100
EruditeHermit: search for IGP on that page
airlied: glisse: yes rs100, rs200
airlied: and rs340
airlied: hopefully can find some testers for those old IGPs
EruditeHermit: nice commit time airlied
airlied: at least my rc410 can start X and run compiz
EruditeHermit: -487 min.
airlied: yeah I forget to reset clocks on machines I boot from USB
MrCooper: NTP ftw
MrCooper: airlied: shave is nice but not really necessary with -Werror :)
airlied: MrCooper: you do know -Werror is impossible?
airlied: in general case
airlied: you can fix it for one gcc version
MrCooper: it was possible until recently, right now I'm using some hackish workarounds (the ones I accidentally pushed recently)
airlied: I always get a warning on some gcc 4.4 box that wasn't there on some gcc 4.2 and vice-cersa
MrCooper: for the same piece of code?
airlied: so far I've got 2 DGA, one radeon_driver.c, one radeon_dri.c, atombios_crtc.c
airlied: has about 15
airlied: if we set -Werror shit will stop building on some distro build
airlied: its a real pain.
MrCooper: I'm not suggesting that
MrCooper: just for developers
MrCooper: to avoid horror shows like kms-support
airlied: kms-support though was a stopgap, if I wanted to put time into fixing it, it was better put into making the master tree work
airlied: at the moment do you see any warnings like I mentioned above?
MrCooper: sure, my point is it's easier not to add warnings in the first place than to fix them after the fact
MrCooper: airlied: I'm hacking around the ones in dga.c and dri.c, not seeing the others
Crazy_: where can I get latest opensource radeon drivers?
Guest51310: I am not satisfied with the one provided in ubuntu jauntyy
MostAwesomeDude: Well, what isn't satisfactory?
Guest51310: Problems playing videos
MostAwesomeDude: Which video card?
Guest51310: screen flashes all the time because I am using compiz
Guest51310: it is nightmare
Guest51310: radeon x1200
Guest51310: I am on HP Compaq 6715b laptop
MostAwesomeDude: Hm. I don't remember if there's an overlay on there...
Guest51310: ATI drivers no longer work
MostAwesomeDude: Yeah, a video overlay. It wouldn't work right with compiz.
MrCooper: actually it should, so long as the window it's in isn't translucent
Guest51310: so what should I do?
MrCooper: or transformed
MostAwesomeDude: MrCooper: Do you remember if that's an rr400 or r500?
Guest51310: It is impossible to use ubuntu un this laptop if there is no normal video drivers
MostAwesomeDude: Guest51310: Chill a second, it's possible to get things working.
MrCooper: nope, I lost to the marketing guys long ago
airlied: no overlay on rs690
MostAwesomeDude: Ah, so it's GL output that's causing the flicker, then.
MrCooper: why is it using GL output, not textured Xv?
MostAwesomeDude: Guest51310: Your movie player has an option to switch between Xvideo and OpenGL output, probably. You should try using Xvideo.
Guest51310: ok one moment
Guest51310: I disabled accelerated video output in vlc
Guest51310: and set to x11
MostAwesomeDude: That'll work, but be slow. You really want Xv, not X11.
Guest51310: xvideo extension video output ?
Guest51310: and still without accelerated video output?
MostAwesomeDude: Xvideo *is* accelerated.
Guest51310: I am testing with 720p video
Guest51310: works better or same as on windows 7
Guest51310: and what should I do about screen flickering?
MostAwesomeDude: It shouldn't be flickering. :T
Guest51310: When there is some action in terminal
Guest51310: or I am scrolling text file
Guest51310: screen flickers
MostAwesomeDude: Hm. Maybe this requires the EXA vsync? Can't remember how to enable it though.
Guest51310: So it is possible to fix it?
Guest51310: please help me about this
MostAwesomeDude: There's an option that can vsync everything 2D, assuming that you're seeing vsync tearing and not something else.
MostAwesomeDude: But I can't remember what it is.
Guest51310: Please try to. :D
Guest51310: Maybe it would be visible on video. What software can you suggest to make screen video capture?
MostAwesomeDude: It wouldn't be.
MostAwesomeDude: Okay, the option is for your xorg.conf, it's called EXAVSync.
Guest51310: in what section do I have t o put it?
MrCooper: Guest51310: does 'flicker' mean parts of the screen intermittently showing wrong colours?
Guest51310: Any examples?
MostAwesomeDude: It goes with your video driver.
MostAwesomeDude: This is for tearing, right?
Guest51310: it goes in device section, right?
Guest51310: seems like I don't have xorg.conf at all :D
Guest51310: I deleted it because I couldn't start up X one time. Well.... How can I generate it>
Julia: MostAwesomeDude, I can't add it to xorg.conf
Julia: I don't have any
Julia: if I make on with X -configure ti fails to start x
Julia: so. I am like wtf.
Julia: Any other way to add those parameters to x?
Guest84409: Please help http://ubuntuforums.org/showthread.php?p=7586566#post7586566
chainsawbike: Guest84409, pastebin the xorg.conf and xorg log
nanonyme: glisse: Has there been some changes between CHIP_(chipset) and UCODE_(chipset) in radeon_state.c?
Guest84409: one moment
Guest84409: chainsawbike, I added config and log files: http://ubuntuforums.org/showthread.php?p=7586566#post7586566
Julia: any ideas chainsawbike
nanonyme: agd5f: Apparently there's some style differences between what was in r6xx-r7xx-3d radeon_state.c and 2.6.31 equivalent for older chipsets so the r6xx-r7xx-3d code should need a bit of porting and a bit of thinking instead of just copying over, me thinks.
chainsawbike: Julia, i need the xorg.log of a failed run :)
Julia: it doesn't fail back to console. It fails like... I can; t see anything
Julia: I start x
chainsawbike: (==) Using default built-in configuration (39 lines)
chainsawbike: (==) --- Start of built-in configuration ---
chainsawbike: that is in the log you posted :P
Julia: Ok. wait
nanonyme: agd5f: Ooh, I was wrong. It's pretty and all as is. :o
Crazy: let me see
nanonyme: Seems only one thing essentially was missing.
Julia: chainsawbike, http://paste.php.lv/a69ea8699017e128fb531971e0b79728/nonum
nanonyme: Now just have to figure out how to get this to compile.
chainsawbike: Julia, here is a "minimal" config - http://pastebin.com/d7fe17315
Guest23439: OK I will try
chainsawbike: Julia, i assume its a laptop with no external displays?
Guest23439: yes it is laptop
Crazy_: chainsawbike, didn't work with minimal config
Crazy_: started with blank screen
chainsawbike: can i have that log?
Guest20377: ok wait
nanonyme: agd5f: Mostly just interested to see whether r6xx-rewrite experience on a ported set of DRM for 2.6.31 is same or different as experience on r6xx-r7xx-3d with compat for 2.6.31. :)
Guest20377: chainsawbike, http://paste.php.lv/7009684ff712182b486616a7104d679c/nonum
Guest20377: chainsawbike, any ideas?
chainsawbike: Guest20377, so its a black screen on X startup? is compiz enabled?
Guest20377: compiz is enabled
Guest20377: oh, so I have to disable it?
chainsawbike: try disabled
Guest20377: one moment
Crazy: chainsawbike, didn't work anyway
chainsawbike: diddnt think so...
chainsawbike: but worth a try
Guest97460: any other ideas?>
chainsawbike: continues reading the logs
nanonyme: grumbles at the staticness of radeon_cp_discard_buffer breaking r600_cp_do_cmdbuf
chainsawbike: Julia, try " DISPLAY=:0 xset -q " in a vt when a black X session is running
Julia: type this in console?
nanonyme: (not that it wouldn't otherwise, apparently an API change)
Crazy: chainsawbike, "unable to open display 0:"
Guest29904: or access... somthing like that
chainsawbike: try :1
glisse: nanonyme: only ioctl matter you can change anything inside the module
nanonyme: glisse: Well, just noticed the API change means r600_cmdbuf.c needs more params (drm_master) for its radeon_cp_discard_buffer call anyway so I thought of rather eating than banging my head at this further
Crazy: chainsawbike, ok, cool
Crazy: after :1 it displayed X cursor
Crazy: but nothing else
Guest52926: but cursor at least is something :D
chainsawbike: oh... i should explain myself better - i want the output of that command :P
chainsawbike: DISPLAY=:1 xset -q |pastebin
chainsawbike: will pastebin it for you
Guest52926: one sec
nanonyme: glisse: Seems that in r300 it's been done by implementing r300_discard_buffer inside r300_cmdbuf.c. Probably have to do the same for r600_cmdbuf.c.
nanonyme: (as in, if radeon_cp_discard_buffer isn't supposed to be used)
Guest34077: chainsawbike, xorg log http://paste.php.lv/4e55d9946bbe3eca35248b302df20457/nonum
glisse: nanonyme: what are you trying to do ?
nanonyme: glisse: Seeing if the r6xx/r7xx 3D code would work better ported on 2.6.31 than just compatting the DRM stuff (which I already did).
Guest4724: chainsawbike, log file any good?
nanonyme: Given there might be differences in other places of the DRM irrelated to the r6xx/r7xx 3D stuff that cause issues with the kernel.
nanonyme: glisse: This mostly because I'm still being puzzled at the code working different on different kernel versions. :p
chainsawbike: Guest4724, i want the outut of the "DISPLAY=:1 xset -q | pastebin " command - the random charactars at the end of the url will do
Guest62875: pastebinit didn't work for that command :/
RandomSearch: Hello all. I have a problem. Anyone care to help?
chainsawbike: pastebin-it wont work - http://rafb.net/paste/
RandomSearch: ok, I guess not.
chainsawbike: RandomSearch, ask - it helps if we know the problem :P
RandomSearch: I have a Radeon 9500, Ubuntu 9.04, and I have screen corruption on loading the Radeon driver
RandomSearch: The screen is recognisable, but corrupted
RandomSearch: Any ideas?
Guest51949: chainsawbike, http://paste.php.lv/166d12534122061178d4dd04d9d99acc/nonum
RandomSearch: (beyond buying NVidia... :-D)
biotube: Look through /var/log/Xorg.0.log for any lines beginning with '(EE)' or '(WW)'
chainsawbike: RandomSearch, my honest opinion - dont use ubuntu :P
RandomSearch: Why not Ubuntu? It seems to be a driver problem...
biotube: Ubuntu always has tons of problems due to the blind devotion to release dates
RandomSearch: I gathered that - particularly with Intel chipsets this time round, right?
RandomSearch: ...but as far as I can see, I shouldn't be having this problem
RandomSearch: It's like a certain percentage of pixels are the wrong colour, so I can see bits and pieces of the gnome desktop
chainsawbike: Guest51949, see if xrandr has any useful info and maybe try hooking up an external display see if it goes
RandomSearch: Would turning DRI off help?
chainsawbike: Guest51949, other than that im outa ideas
RandomSearch: If only ATI hadn't dropped support for older cards...
chainsawbike: RandomSearch, ubuntu is fine till you try customise it / need really new versions of stuff / etc
RandomSearch: Yes, I know it's not as flexible as other distros, but (generally) it "just works" and allows me to get on with things
RandomSearch: This being an exception, and sadly a case in point
RandomSearch: Everything is working as it should - the card is detected, radeon driver loads, X starts
RandomSearch: Everything looks fine until I type into the login box, then some pixels look corrupted
RandomSearch: then when I'm in GNOME, the screen is generally messed up
RandomSearch: You don't have any ideas about driver options that might help do you?
biotube: Ubuntu might have "fixed" the driver or X itself.
RandomSearch: I guess they might. I haven't found anything on their forums that sounds like this problem.
RandomSearch: It's possible that some previous configuration of xorg.conf that was done by Ubuntu in the past has been removed, relying on autodetect instead
Guest51949: ok shx chainsawbike
Guest51949: So I will have to live with it
chainsawbike: RandomSearch, do you have a xorg.conf ?
RandomSearch: Thanks for your help guys, I'm going to try a few driver options and then I'm going to buy an NVidia card if it still doesn't work
RandomSearch: chainsawbike - now, I don't.
Guest51949: but how is it possible that it can start without xorg.conf and can't with one generated by x
RandomSearch: I can't find an example for 9500
chainsawbike: Guest51949, ubuntu mess with things :P
RandomSearch: and besides, it's loading the right driver
Guest51949: chainsawbike, I used debian on this laptop before
RandomSearch: Thanks for your help
Guest51949: used fglrx and it worked fine
Guest51949: but had problems with apci
RandomSearch: I suspect I'll be using NVidia by the end of the week
Guest51949: and fresh ubuntu jaunty didn't work either
Guest51949: Had to install hardy and then upgrade to jaunty\
chainsawbike: RandomSearch, http://pastebin.com/d5202c45
chainsawbike: my xorg.conf
Guest51949: seems like ubuntu is made by fools...
chainsawbike: RandomSearch seems in a great hurry...
chainsawbike: Guest51949, is there a .xinitrc in your home dir?
Guest51949: there isn't
Guest51949: what is that file?
chainsawbike: see if twm + xterm are installed
Guest51949: one sec
rnoland: agd5f: RV740? It looks like your tree has at least the beginnings of support for this chip?
chainsawbike: Guest51949, its a custom xsession file
Guest51949: I don't have twm
Guest51949: have xterm
Guest51949: what is that twm>
chainsawbike: a horrible window manager
Guest51949: do I need it?
chainsawbike: metacity will do i suppose :P
chainsawbike: put "xterm & metacity" in .xinitrc
rnoland: agd5f: ah, yes... I see it all now.
Guest51949: Is it passible to use that EXAVSync command without xorg.conf?
chainsawbike: dont think so
Guest51949: like omg it is lame...
nanonyme: agd5f: Hmm, seems some stuff need to get into libdrm too still... Eg RADEON_CHUNK_ID_OLD and some others. They're not in current master anyway.
chainsawbike: Guest51949, once you have done that kill gdm + X then type startx in a vt
nanonyme: (or then the macros need to get ported to some other header file in the kernel)
nanonyme: The r600 radeon_cs.h is currently relying on some userspace libdrm bits to exists, otherwise it refuses to compile.
nanonyme: Erm, radeon_cs.c even.
agd5f: nanonyme: you don't need r600_cmdbuf at all
chainsawbike: Guest51949, bbs
nanonyme: agd5f: There was one call to a function in r600_cmdbuf in radeon_state.c.
agd5f: nanonyme: yeah, you don't need that code
nanonyme: Oh. :P
agd5f: like I said, all you need is radeon_cs.c and the CS ioctl
nanonyme: Well, the radeon_cs.c was a more tricky thing though anyway.
nanonyme: The r600 radeon.cs.c includes drm_radeon.h which is part of libdrm which implies you need more bits than is in newest libdrm master to compile it.
agd5f: rnoland: th rv740 stuff is upstream as well
agd5f: in linus kernel
rnoland: agd5f: hrm.... i missed that patch....
Guest51949: chainsawbike, put xterm and metacity in that file?
rnoland: it's hard to keep track of stuff these days....
Guest51949: like 2 lines?
nanonyme: (but yeah, taking back that cmdbuf stuff, shouldn't be hard)
agd5f: nanonyme: drm_radeon.h is part of the kernel code, it just happens that installing libdrm installs it as well. you'll need the changes from there as well
agd5f: er radeon_drm.h
nanonyme: Yeah, that. Sorry.
nanonyme: agd5f: One complication: there's no radeon_drm.h in Linus tree.
nanonyme: Stupid me, it's probably in includes lower, just have to change the path...
nanonyme: (or not?)
nanonyme: Yes, it is.
agd5f: it's probably in include/drm or somesuch
nanonyme: Yeah, just needs path change to the include then, no worries.
Crazy: ok I guess I simply had to move it to xorg.conf in X11 in etc
nanonyme: agd5f: Right, should be fine then as soon as I get this drm_alloc porting sorted out.
agd5f: nanonyme: the CS stuff should already be in place for kms
agd5f: the structs and such
nanonyme: agd5f: Well, the slight problem I had was that r600 radeon_cs.h isn't compatible with 2.6.31 because drm_alloc/drm_free get dropped. If you mean that's waste of effort too, I'm glad. Finding out the replacements is taking quite a bit of effort.
chainsawbike: Guest57253, no literally xterm & metacity
chainsawbike: Guest57253, no literally xterm & metacity
adamk_: Any idea why I don't see the ball in neverball? :-)
adamk_: I get the shadow, though. It make for an interesting game.
adamk_: Correction... I get the ball in neverball 1.4.0 but not neverball 1.5.1
MrCooper: adamk_: I get the ball with mesa master. Are you using DRI2? What card?
adamk_: x1900, Fedora, mesa-dri-drivers and mesa-libGL 7.6-0.1.fc11
adamk_: DRI2 is enabled, there is no compositing manager running.
adamk_: Oh, I think this is a neverball configuration issue.
adamk_: I copied over a .neverball directory from a FreeBSD machine so I wouldn't have to replay all the levels I completed... If I remove that directory, it works just fine.
MrCooper: disable the 'invisible ball' option ;)
rnoland: agd5f: the patch to use switch for microcode load doesn't appear to be in drm-linus?
adamk_: MrCooper: Huh... The ball_file option in neverball
adamk_: In .neverballrc doesn't like ^M at the end of the line in Fedora... No complaints in FreeBSD, though.
adamk_: Odd, but at least that problem is solved.
agd5f: rnoland: I dropped the ball on that one
rnoland: agd5f: i thought i remembered you making a patch... it just looks like it never got merged
agd5f: rnoland: could be. I'll have to check my patches
rah: is rv280 supported by KMS in 2.6.31-rc2?
rah: I just want to play video with my KMS-enabled rv280
rah: what branches of xf86-video-ati/mesa/drm should I use?
biotube: rv280 - that should be covered in mainline, shouldn't it? I've yet to play with KMS.
agd5f: rah: master
nanonyme: And libdrm with --enable-radeon-experimental-api. :)
biotube: how experimental is it, anyway?
nanonyme: Mostly I'd assume it means "subject to change".
nanonyme: (which might be pretty bad when you're talking of an API on a production machine ;)
nanonyme: Not that fun if you notice and update got half of the functions renamed. (not likely but theoretically goes under "experimental api")
nanonyme: My causality sucks.
aliverius: hello guys
aliverius: where could i find docs about KMS?
rah: agd5f: k
aliverius: internals, API and such
agd5f: aliverius: the source code
biotube: Yes - it is an intriguing dot :)
nanonyme: Mostly noticed I'm getting incorrect rendering out of Software Rasterizer.
biotube: that is strange
peterz: I seem to be getting stuck in an drm ioctl from copy to vram on R600 a lot
agd5f: peterz: probably an engine hang
EvilRoey: hey, #ati is sort of dead at the moment. Can anyone still help me with fglrx here? 9.4 and 9.6 seem to freeze my X with a black screen.
rnoland: agd5f: rs690 docs are released?
peterz: agd5f: joy, it didn't used to happen, could it be my current kernel's drm is funny or should I have better luck upgrading userspace?
EvilRoey: (radeon 3450 here)
agd5f: rnoland: have been for a while: http://www.x.org/docs/AMD/
rnoland: hrm, ok... maybe this is the entire chipset docs then...
aliverius: agd5f: if it's the only way...
agd5f: rnoland: you mean non-grpahics?
rnoland: agd5f: yeah
rnoland: [Fwd: AMD SB700/SB710/SB750 docs have been released!]
agd5f: rnoland: I don't know. chipset group handles that stuff
rnoland: it mentions rs690/rs780 in the message
nanonyme: aliverius: Hey, it's opensource coding, can't expect it to be so organized and documented. ;)
EvilRoey: for the opensource driver--is it accelerated??
nanonyme: Is what accelerated?
EvilRoey: I just installed Ubuntu here on this radeon 3450
EvilRoey: my aging.
EvilRoey: nanonyme: the graphics.
nanonyme: EvilRoey: If you mean OpenGL, no.
EvilRoey: nanonyme: graphics seem very slow here; I'm w
EvilRoey: well it's not that--it's that /nothing/ here seems accelerated.
EvilRoey: I'm not sure which driver I'm using, one moment
agd5f: rnoland: I'd imagine it's pretty similar
nanonyme: Eg movie playback with Xv should be plenty accelerated.
rnoland: agd5f: yeah, i'll look it over and see if it is interesting...
agd5f: peterz: hard to say
EvilRoey: how do I find out the current driver?
nanonyme: Could check from xorg log, I guess.
EvilRoey: ah, point
peterz: agd5f: ok, I'll start by updating the ati driver, after that I'll prod airlied if 30-rc2-tip from a day or two ago is missing drm patches ;-)
peterz: 31-rc2-tip that is
EvilRoey: Module radeon: vendor="X.Org Foundation"
adamk_: EvilRoey: That just means that it's trying to load the radeon driver... That doesn't necessarily mean that's the driver being used.
EvilRoey: oh hey adamk_
adamk_: Check toward the bottom and should see lots of lines starting "(II) RADEON" if you are using the radeon driver.
EvilRoey: adamk_: btw, 9.4 and 9.6 give me black screen freezes in X (I have re-installed since this morning and now only use dpkg -i to install the drivers)
agd5f: rnoland: it appears teh rs690/sb600 docs are already released: http://www.coreboot.org/AMD_Public_Documents
adamk_: EvilRoey: Well if you want to install the fglrx drivers, you should now be using the restricted driver manager, especially since you can get into X. If you have problems, you'll have to ask on #ubuntu or #ati.
EvilRoey: adamk_: I do see (II) RADEON
EvilRoey: adamk_: right, I went here because #ati was dead
rnoland: agd5f: yeah, i haven't really done much cpu/chipset work on amd so far, so i haven't gone through all of those docs...
EvilRoey: anyway, I'll use restricted-drvier-manager but I don't see how it'll give me any different a response
EvilRoey: adamk_: I cannot find the package name for restricted-driver-manager (running Kubuntu Jaunty here)
adamk_: EvilRoey: You should ask in #ubuntu, then... I don't use the ubuntu's and that's really outside the topic for this channel.
EvilRoey: thank you
Guest5889: ok, so. what should I do about screen flickering?
bridgman: Guest5889; what are you doing when the screen flickers, and what kind of flickering is it (brightness variation, things move or jump etc..)
bridgman: if you're not running a KMS stack then you will get flicker during 3D if you are running with a compositor
EvilRoey: hey bridgman
Guest5889: bridgman, wait. I made a video. will upload in a sec
Guest5889: what is kms?
bridgman: I'm on 21Kbps dial-up, I won't be watching your video any time soon ;)
bridgman: Kernel ModeSetting
bridgman: next generation stack; in development but getting near completion
bridgman: F11 has it all assembled for you
jcristau: 21k dialup? sounds like 1995.
Guest5889: I have 100mbit connection
Guest5889: 15 upload
bridgman: nah, it's 2009 out in the sticks with 70' trees all around to block satellite access
Guest5889: so how can I fix that screen flickering problem?
bridgman: describe it with words, not a video ;)
bridgman: and answer my questions from above ;)
Guest5889: Have you seen how computer works with broken video card?
Guest5889: not as bad but close :D
Guest5889: when I move windows around
Guest5889: or there is some activity going on in any window
Guest5889: I get like white stripes over the screen
Guest5889: and everything around shakes
nanonyme: has seen how some computers work with badly enough broken video cards: they go beep on power on and never boot ;>
Guest5889: :D not so broken :D
Guest5889: anyway my video card is not broken. :D Drivers make some random lines appear on screen
bridgman: ok, what GPU ?
Guest5889: and flash whole screen
Guest5889: Radeon x1200 (using compaq 6715b laptop)
bridgman: and what version of radeon driver ?
Guest5889: one moment
rnoland: agd5f: btw, the current radeon drivers don't fallback correctly with AIGLX enabled.
Guest5889: latest with ubuntu jaunty. I'l check
rnoland: they try to load r600_dri and when that fails... it just locks up or crashes X
bridgman: ok, I don't think that has the "watermark fixes" (display fifo); agd5f do you remember ?
Guest5889: xserver-xorg-video-radeon 1:6.12.1-0ubuntu2
bridgman: the other possible problem is that the laptop is downclocking your CPU enough that the memory controller isn't keeping the display fed with data
bridgman: do you have an easy way to check & adjust CPU speed ?
Guest5889: I can adjust it from gnome panel applet
bridgman: make it scream
Guest5889: intel 2.1ghz dual core
Guest5889: done. set @ 100%
bridgman: any effect on the display ?
Guest5889: seems like there is less flickering :O
Guest5889: allmost none
Guest5889: but I can't keep it @ 2.1 ghz. it is laptop! :D
agd5f: bridgman: yeah the watermark fixes are git master only
agd5f: I don't think I ported them to the 6.12-branch
agd5f: rnoland: hmmm... worked ok here
Guest5889: bridgman, so what can I do to make it work with any cpu speed?
rnoland: agd5f: with AIGLX on and no r600_dri.so
agd5f: rnoland: yeah
bridgman: pick up the latest radeon driver; either build from source or you should be able to get an edgers package
rnoland: it doesn't appear to fallback to swrast
agd5f: shows can't find r600_dri.do and falls back to swrast
rnoland: wonders if it needs libdrm_radeon for that...
agd5f: actually, the watermark code is incomplete for rs600 since the intel interface is different
bridgman: good point - intel cpu => rs600, not rs690, sorry
Guest5889: bridgman, any ideas where can I get nightly packages?
agd5f: rnoland: shouldn't
rnoland: agd5f: I saw this on my 3650 the other day... and the guy with the RV740 that i just sent the patch to, also ran into it...
Guest5889: I couldn't find any place
agd5f: rnoland: there was a xserver bug like that a while ago
agd5f: in the glx code iirc
bridgman: Guest5889; do a google search for "edgers crack"
rnoland: agd5f: hrm, ok... we are on 1.6.1 right now... i need to get us up to 1.6.2
agd5f: rnoland: it was older than that. 1.6 should be fine
agd5f: like 1.4 time frame IIRC
agd5f: maybe something re-broke
bridgman: looks like there's a warning to hold off for now until the xserver 1.6.2 breakage gets resolved (guessing)
Guest5889: so should I or should I not use it?
rnoland: hrm... hadn't seen 1.6.2 warnings yet.
bridgman: I think the warning went up yesterday; I'm only guessing it's related to the 1.6.2 dri2 format thing
Guest5889: What is that live cd?
Guest5889: Is it ubuntu live cd with latest radeon drivers?
d4ta_: Are there someone who can help me.. I have a ATI readon x700 graphics card and I don't know how to setup a driver for it in Ubuntu ?? :)
Guest5889: open synaptics
Guest5889: System > Administration > Synaptics package manager
d4ta_: yes :).
Guest5889: and search for radeon
Guest5889: there should be xserver-xorg-video-radeon
d4ta_: ar... thanks.. and then i just have to install it like all other packages?
bridgman: which version of ubuntu are you using
bridgman: it should install radeon automatically
d4ta_: the newest version... can't remember.. 2 sec
d4ta_: but it looks like this driver is already installed... i can only select reinstall...
MrCooper: rnoland: anything in the log file after the failure? If not it may die due to an unresolved symbol, check the X stderr output
rnoland: MrCooper: I'll have to reproduce it again... but it was without r600_dri.so
MrCooper: swrast_dri.so is there?
bridgman: d4ta_; I would just leave it alone
d4ta_: sorry.. but how to I open the log? :)
bridgman: administration=>system log viewer
rnoland: MrCooper: yes
bridgman: or look in /var/log/X11 or something; just start in /var and look for what makes sense
agd5f: Guest5889: the watermark code won't fix your chip as it hasn't been implemented yet
Guest5889: so what should I do?
bridgman: yeah, that was my mistake; I was thinking you had an rs690 not an rs600
d4ta_: the path /var/log/X11 dont even exist... wirred??
Guest5889: bridgman, ATI Technologies Inc RS690M [Radeon X1200 Series]
Guest5889: I have rs690
agd5f: Guest5889: if your cpu is intel, you have an rs600
nanonyme: Well, Xorg.0.log or similar are usually under /var/log/
agd5f: d4ta_: /var/log/Xorg.0.log most likely
Guest5889: maybe it is not intel
Guest5889: I am not sure about that :D
Guest5889: maybe it is AMD
agd5f: Guest5889: well if it is AMD, then trying a git snapshot should help
Guest5889: so I have to install mesa, radeon, core and what else?
Guest5889: doing it from synaptics is not easy :D
agd5f: Guest5889: just radeon
Guest5889: have to force every package manualy
Guest5889: oh ok
d4ta_: maybe i should try restart?? I have looked thow the logfile, and it looks like it have done it all right?
bridgman: is there a problem you are trying to solve by updating the driver ?
d4ta_: yeah.. it's just that my screen resolution is very low and i can only use screen resolutions in 4:3 - and i have a wide screen, which makes it look very bad
Crazy: IT WORKS!
Crazy: Woohoo! :D
Guest98787: Thank you all! :)
Guest98787: no lag anymore
bridgman: oh good ;)
Guest98787: Only thing left is fingerprint reader (I can live without it) and make my laptop silent
Guest98787: it is too loud. :|
agd5f: d4ta_: can you change the mode with xrandr or the display gui tool?
d4ta_: how does the xrandr works?.. sorry i'm asking this much.. Linux is very new for me :)
d4ta_: doh.. I just found out that i had a checkbox in "clone screens"... because my LCD TV are connected too.. thats why i could not setup my screen resolution.. :).. Thank you for your help :)
Guest98787: how can I change totem video output to xv?
nanonyme: Probably some gstreamer config too.
Guest98787: VLC is set to XV. It doesn't lag as totem does, but video is teared when there is movement
Guest98787: Something in xorg.conf?>
Guest98787: bridgman, what about video tearing? I set vlc to Xv, it isn't slow but it gets teared when there is some movement in video
Guest98787: Interesting that .mkv videos (720p) are fine.
Guest98787: Even better then it was on windows
agd5f: Guest98787: gstreamer-properties or something like that
Sarvatt: so would it be ok to change all references to DRI2BufferPtr to DRI2Buffer2Ptr in src/radeon_dri2.c so it will compile against xserver 1.6.2 as a temporary kludge?
marvin24: what is the correct drm tree for current 6xx_rewrite branch
marvin24: stops at radeon_common.c:972: Error: too many arguments in function »radeon_cs_space_check«
marvin24: I have the drm tree from alex (r6xx-r7xx-3d' of git://anongit.freedesktop.org/~agd5f/drm
agd5f: marvin24: r6xx-r7xx-3d branch of git://anongit.freedesktop.org/~agd5f/drm
marvin24: yeah - using it already ;-)
marvin24: still the error
agd5f: marvin24: libdrm radeon changes in master are too new
nanonyme: agd5f: Depends on which changes, I guess, worked fine for me with the experimental API enabled from drm master a few days ago.
nanonyme: Sarvatt: Should be fine.
nanonyme: I couldn't find it being used anywhere else in radeon driver except radeon_dri2.c anyway. :)
agd5f: marvin24: you need the r6xx-rewrite branch of mesa
marvin24: found the problem
marvin24: I hate these rests of old drm installations
marvin24: the where some headers from drm/master installed
marvin24: sorry for the noise
nanonyme: As said, worked fine for me with headers from drm master...
marvin24: any chance for igp support in the near future?
marvin24: I have a rs780
agd5f: marvin24: it's supported about as well as any other chip
marvin24: last info I had, that it is crashing on these chips because devs don't use them to test
marvin24: but you should know better ...
agd5f: marvin24: rv7xx cards are working best at the moment, but it's all pretty relative since there's not much working yet in general
agd5f: other than basic redbook demos
marvin24: even hello.c crashes here :-(
marvin24: what's the meaning of "drmRadeonCmdBuffer: -22
marvin24: output of ./hello
biotube: unless I'm mistaken, it means bug
agd5f: marvin24: error. most likely a bad packet
agd5f: marvin24: are you sure you are using the kernel modules from r6xx-r7xx-3d branch of my drm tree?
marvin24: no - from kernel/master
agd5f: marvin24: that's your problem
marvin24: agd5f: I have copied the modules from your tree to /lib/modules/.../updates
marvin24: agd5f: is there a way to tell if the kernel is using these?
agd5f: marvin24: try moving the old ones just in case
marvin24: agd5f: ok - just needs to restart X
woden: How do I tell what driver I'm using?
biotube: look in /var/log/Xorg.0.log
woden: biotube: What am I looking for? I see a bunch of lines that start with RADEON. Most of it seems to have to do with my monitor
biotube: that's it: if you were using radeonhd, those lines would start with RADEONHD.
woden: So what is the radeon driver?
woden: What can I do with it?
biotube: it depends: for r300 and early chips, you get full 3d and 2d accelleration
biotube: for r600 and later, you get 2d
biotube: I'm not sure about in between
MostAwesomeDude: r100-r500 have 3D, r600+ does not.
woden: biotube: I just got a new Radeon 4850 will that work with 3D?
MostAwesomeDude: X1950 and earlier have 3D, 2000 HD and newer do not.
woden: When will 3D come to my card?
agd5f: woden: it's in progress now
biotube: if you need 3D before fall or so, you'll have to go with fglrx(ati.amd.com)
woden: I already checked apparently fglrx doesn't suppor my kernel
agd5f: marvin24: restarting X isn't enough, you have to unload the drm module after stopping X (modprobe -r radeon; modprobe -r drm)
MostAwesomeDude: biotube: Please don't promise dates, especially if you don't contribute code. :3
woden: Woah this is weird, I'm actually able to play my game but the frame rate seems very slow
MostAwesomeDude: woden: Yeah, that's the software rasterizer. It's slow but effective.
biotube: MostAwesomeDude: I'm just repeating what I've heard here
biotube: hence the "or so"
marvin24: agd5f: I also did this
marvin24: agd5f: but I also had to recompile the radeon driver, because of libdrm_radeon missing
Julia: funny but I get less video tearing if I set vlc to use OpenG:
Julia: opengl *
marvin24: agd5f: now hello.c locks Xorg
Julia: but then video is always on top :D
marvin24: agd5f: but I used a patches version of you drm tree to let it compile on master kernel
agd5f: marvin24: i's likely a soft lock. you can probably stop and restart X
marvin24: agd5f: yes, killing X works
marvin24: agd5f: I have a backtrace if you are interessted
marvin24: agd5f: (via remote gdb)
agd5f: the xserver hangs waiting to get the hw lock back. so we are apparently holding it in mesa somewhere
agd5f: marvin24: yeah
marvin24: from there it goes to DRIDoWakeupHandler->DRILock->drmgetlock->drmIoctl
marvin24: locks ...
nanonyme: biotube: Rule of thumb: give more pessimistic estimates than developers unless you are a) quoting b) contributing. ;) (most developers probably know not to give too optimistic ETA's anyway)
biotube: okay then
biotube: I did try to read AMD's r6xx programming manual once, but got lost six pages in
MostAwesomeDude: Most people have to ask questions about the programming guide. Don't feel bad about it.
nanonyme: Hmm, the r5xx acceleration guide?
MostAwesomeDude: Or the r6xx one.
nanonyme: Oh, true, I didn't even remember it was pushed out already too.
nanonyme: notices he starts bumping into not being a native English speaker with the r6xx/r7xx guide
nanonyme: "Theoretically the driver just needs to do cache flush for the last HW rendering. In practice, the driver is unable to know which rendering action is the last one. The solution is to do a cache flush after each HW rendering". :(
nanonyme: Sucks if that's the only working solution, doesn't sound very optimal performance-wise.
agd5f: nanonyme: take that with a grain of salt
agd5f: all it's saying is that you have to expicitly flush the caches when you want to make sure something hits memory
nanonyme: Yeah, well, that's a good thing to remind of.
nanonyme: agd5f: Hmm, how come SURFACE_BASE_UPDATE is required by RV6xx but not R600 and R7xx? :) Sounds weird implementing... Some idea that was introduced in the middle of the series and then scrapped?
agd5f: nanonyme: hw bug workaround
nanonyme: Hmm, right.
nanonyme: hopes there's not too many that kind of bugs in the chipset range since he has RV670 himself
koolfy: Isn't it a little soon to drop xpress200m support on fglrx driver ?
koolfy: Am I so old school ?
koolfy: It's not so old…
koolfy: Got it with my under two years old laptop :(
nanonyme: koolfy: I suspect opensource community's opinion doesn't matter much on the matter.
muep: koolfy: the free driver seems to work with it, though
koolfy: "work", well I still have issues and KP's with some aps only affecting the 200M
koolfy: (OS driver)
koolfy: I should fill a bug
muep: probably yes
osiris_: koolfy: what mesa version do you have?
muep: or comment on existing ones if you find some that match your problem
koolfy: 7.4.2 (mesa)
koolfy: I should upgrade mesa too.
koolfy: to 7.5_rc4
osiris_: thats very old. there have been many fixes for radeon since then.
koolfy: but my point was : is the 200M SO obsolète right now ?
osiris_: try current master
koolfy: thanks :)
nanonyme: koolfy: Hardware is pretty much never obsolete for opensource drivers.
koolfy: Yeah, that is great :)
nanonyme: (well, r100 and r200 are pretty close but meh)
osiris_: nha: did you have a chance to look at my shaders_cleanup branch already?
nha: osiris_: actually, I was about to take it for a test drive
nha: except that I got some build troubles because of the recent libdrm changes
nha: do you think you could rebase your patches on recent master?
nha: the automatic merge seems to work though
nha: and I'm still lacking a visual diff tool for easily reviewing patches :/
nanonyme: Some GUI for git?
agd5f: nha: gitk?
dileX: nanonyme: tig (ncurses)
nanonyme: dileX: I wasn't asking to find one, I was replying nha.
nanonyme: I'm fine with git and Emacs.
nanonyme: (Emacs is git-aware)
dileX: nanonyme: sry, replying with a question? hehe
rah: how do I get autogen.sh to pay attention to my install xorg-macros.m4?
nanonyme: dileX: Indeed.
rah: I've exported ACLOCAL="aclocal -I
rah: but there are still unexpanded macros in my configure script
nha: agd5f: does it do an actual compare though? I'm thinking of a view like in kdiff3 or kompare, but without the need to have two repositories checked out at the same time
rah: ./configure: line 12339: syntax error near unexpected token `XINERAMA,'
rah: ./configure: line 12339: `XORG_DRIVER_CHECK_EXT(XINERAMA, xineramaproto)'
agd5f: nha: not really
nanonyme: Got new enough a version of xorg macros?
rah: yes, from git
agd5f: rah: PKG_CONFIG_PATH maybe
rah: I've set that as well
nanonyme: Btw, you want to edit autogen.sh a bit if you re-run it. It doesn't do full bootstrapping except on the first run.
nanonyme: Putting --force after autoreconf makes it do full bootstrapping on every run.
_Groo_: hi/2 all
nanonyme: It caches stuff otherwise.
nanonyme: Probably doesn't matter in this situation, just a note.
rah: well, no, it probably does matter
rah: considering running autogen.sh hasn't brought the macro in
rah: although, perhaps not
rah: it's still not getting the macro
rah: probably because it's in xorg-server.m4, not xorg-macros.m4 :/
nanonyme: But yeah, what agd5f said.
rah: is it wise to configure with --prefix=/usr ?
rah: or rather, is it unwise? :-)
nanonyme: I wouldn't do it for boot-essential stuff.
rah: what would you do?
nanonyme: Or rather, wouldn't over-write anything that's boot-essential.
nanonyme: If it's just X components, probably plenty safe.
rah: I see
nanonyme: Can always boot in single-user mode and sort things out.
nanonyme: (or multi-user non-X, whichever)
nanonyme: rah: Always ask yourself "can I undo this". If the answer is yes, it's probably safe. ;)
rah: is there a way to get X to pay attention to drivers in a different path?
rah: eg, /usr/local/whatever?
_Groo_: rah: easy way would be symlinks
mcgreg: nanonyme: hmm then life would be less exciting, though
rah: _Groo_: that sounds like a "no"
nanonyme: rah: What kind of libraries?
rah: nanonyme: err.. drivers
nanonyme: You can always set ModulePath.
rah: what is that? :)
nha: osiris_: testing is looking good; I will go over the code in more detail
nanonyme: Check your xorg log. It defines where stuff like X display driver are looked in.
nanonyme: It defaults to some value, you can override it in xorg.conf.
rah: it would, then, seem unwise to install in /usr if you can add /usr/local to the server's search path just by editing the configuration file
nanonyme: Whichever works the best. ;)
nanonyme: currently has distro libdrm, X server, radeon driver and Mesa overwritten
nanonyme: agd5f: Btw, does r7xx seriously have less hardware bugs than rv6xx or is it just that rv6xx hardware bugs tend to have a relevance on issues the r6xx/r7xx accel guide was about?
rah: wonders why libdrm wants xf86driproto if it's configured for radeon KMS
agd5f: nanonyme: probably less
rah: (which is DRI 2)
MostAwesomeDude: nanonyme: r300 has a register called GA_ENHANCE that can be used to disable errata on r400 and r500. There's probably something similar on r700.
nanonyme: MostAwesomeDude: Just wondering how likely it is these "local problems" of mine with r6xx-rewrite might have to do with hardware bugs.
MostAwesomeDude: nanonyme: Probably not errata, just HW differences not in the code.
rah: agd5f: are you sure mesa master is what's needed for KMS xf86-video-ati?
agd5f: nanonyme: right now there's a locking bug I'm trying to track down which youa re probably hitting
MostAwesomeDude: rah: Yeah, it is.
nanonyme: rah: Libdrm needs to support DRI1 even with with KMS support enabled, I think.
rah: ok :/
agd5f: nanonyme: I wouldn't worry about hw bugs at this point
MostAwesomeDude: IME the HW bugs tend to be very rare and well-documented.
nanonyme: Well, yeah. The well-documentatedness was just why I read about them in the first place. ;) Found two or three in the manual.
MostAwesomeDude: But they're seriously tiny, tiny things.
MostAwesomeDude: r300 has errata like "this one multisample register needs to be set to 7, not 8" or "if you don't set GA_ENHANCE then you might get a deadlock if you reuse four verts several hundred times."
MostAwesomeDude: Really rare and mostly harmless stuff.
nanonyme: That "Shader GPR Indexing may return incorrect results" sounds interesting to me. (not applicable for my own chipset)
koolfy: aaawww, even with newer mesa pSX (playstation emulator) still produces KP on xpress 200m
koolfy: I'll have to fill the bug :(
koolfy: on vacations :'(
nanonyme: What, some people do vacations? :o
koolfy: sure :p
koolfy: malaga inside :)
nanonyme: I wanted to, noticed I don't have time. Maybe next Summer.
MostAwesomeDude: koolfy: Use the software rasterize with PSX emulators.
koolfy: what's that ??
MostAwesomeDude: Unless you've got a Pentium Pro with a Radeon X1950, the CPU can do it faster than the GPU.
koolfy: oh yeah, great idea
MostAwesomeDude: The software graphics plugin for your PSX emulator.
nanonyme: MostAwesomeDude: Should it be alarming I experience buggy behaviour from Mesa's software rasterizer, btw? :3
koolfy: well each time I launch it I get an instant kernel panic
MostAwesomeDude: (I found that Chrono Cross doesn't go fast enough under fglrx with my X1900, but it played find on the Core 2 Duo.)
MostAwesomeDude: *fine, even.
muep: what's KP?
koolfy: kernel Panic
muep: ah, ok
MostAwesomeDude: nanonyme: Yes. If you get any kind of rendering bug in Mesa's softpipe/softraster, file a bug.
nanonyme: MostAwesomeDude: glxgears window is transparent. >.<
koolfy: MostAwesomeDude: I can't find that video driver
MostAwesomeDude: nanonyme: Colored gears, but the background is transparent?
MostAwesomeDude: koolfy: Are you using epsxe, or something else? There's definitely a software plugin for epsxe out there...
koolfy: I use pSX-bin emulator, you are talking about epsxe, aren't you ?
koolfy: yeah, not psxe
MostAwesomeDude: nanonyme: Turn off your compositor and it'll work. :3 It's just because of ARGB visuals.
koolfy: I don't know if it can be done witf the pSX-bin emulator
nanonyme: MostAwesomeDude: I'm not aware I have one.
MostAwesomeDude: glxgears should really be clearing with solid black, not transparent black. :3
nanonyme: Gods. :D
nanonyme: Apparently I do.
MostAwesomeDude: If you feel adventurous, you could modify your progs/xdemos/gears to use solid black and submit a patch. :3
nanonyme: I've probably tried xcompmgr at some point and forgot it on autostart.
nanonyme: I might try that modification at some point later, first I'll go check whether removing this stupidity affects r6xx-rewrite rendering.
_Groo_: any news on the garbled screen bug?
_Groo_: suspend is useless for rs485 :(
rah: what mesa driver should I select for rv280?
rah: (with KMS :)
agd5f: rah: e200 same
agd5f: r200 same as non-kms
rah: what's the "radeon" driver about?
biotube: it's the subdriver for radeon chipsets
agd5f: rah: that's the x driver. handles 2d, video and modesetting
airlied: _Groo_: I fixed some rs4xx bugs yesterday
rah: should I add that?
rah: in addition to r200?
airlied: _Groo_: the patches are queued in my git tree drm-radeon-kms branch
_Groo_: airlied: i just need to branch from drm master to drm-radeon-kms branch?
rah: possibly some misunderstand
nanonyme: agd5f: What's the radeon directory in src/mesa/drivers/dri though? Is it just shared stuff or r100?
rah: agd5f: I mean the mesa driver named "radeon"
agd5f: rah: r1xx chips
airlied: _Groo_: its a kernel tree
airlied: you can just pull it into whatever kernel tree you have
airlied: nanonyme: both
_Groo_: airlied: argh... need to wait you to push it to linus tree?
airlied: nanonyme: its got shared code + r100 specific code
_Groo_: airlied: im using linus, whats the exact command?
airlied: _Groo_: yes I'm going to ask Linus to take it.
_Groo_: airlied: and can i compile just the drm modules? compiling the entire kernel is a pain :(
airlied: not really
airlied: you can take th epatches any apply them to Linus if you want
_Groo_: airlied: can you send me the patches?
airlied: _Groo_: http://git.kernel.org/?p=linux/http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff_plain;h=eda5f4f373625cd065a90b278438af19ca4a73d0kernel/git/airlied/drm-2.6.git;a=commitdiff_plain;h=eda5f4f373625cd065a90b278438af19ca4a73d0
airlied: those two
airlied: oops the first URL is messed up
airlied: ends at a73d0
_Groo_: airlied: could you paste the correct url please
_Groo_: for the 1
_Groo_: no such project
airlied: jeez I suck at cut-n-paste
evocallaghan: :) Hey lads.
nanonyme: You're not the only one.
nanonyme: evocallaghan: Hey.
evocallaghan: nanonyme: Good day,
evocallaghan: I'm just going out to eat now, however when I get back I wanted to talk about porting ATi drivers, dri etc.. framework to AuroraUX (solaris based kernel)
evocallaghan: Not sure where to start for docs and hardware registers etc.. quite new to GPU stuff.
nanonyme: evocallaghan: There's some Solaris developers writing the DRM, would probably have more luck asking them.
evocallaghan: Hmm, Its all closed doors at Sun.
nanonyme: Afaik OpenSolaris but not sure.
evocallaghan: We have a fork called AuroraUX
evocallaghan: Sun normally do source drops for this sort of thing and just reply with to emails as "its comming", or "wrong department"
nanonyme: That's said to be changing.
rah: here goes..
nanonyme: Anyway, the docs available are here www.x.org/docs/AMD/
_Groo_: airlied: first cut please?
nanonyme: evocallaghan: I heard the devs aren't just simply porting code but rather re-designing the whole DRM kernel modules in a way which will work nicely with Solaris kernel.
nanonyme: Takes its time.
evocallaghan: I guess, but should do it in public ..
nanonyme: (Userland stuff are pretty mostly irrelevant there anyway)
MostAwesomeDude: Hey, if they wanna do it so that only libdrm is managed by us, I don't think there would be many objections here.
evocallaghan: Any way, *really* need food, like major O_o
_Groo_: airlied: ah, the second worked, thanks.. gonna patch and ill let you know
_Groo_: airlied: anyone could take a look at kde4 3d pleeeeease!!!
nanonyme: MostAwesomeDude: I've got the impression it's heading that way.
_Groo_: ill give an extra cookie!
evocallaghan: I'll carry this one when I get back, hopefuly you lads will still be around. Cheers for the URL btw, I had that one though :)
rah: big screen
nanonyme: MostAwesomeDude: There's a lot of interaction going on between AMD and Sun related to the graphics drivers, I'm sure they'll work something out. Hopefully something that does libdrm and Gallium3D.
nanonyme: Would be lots of synergy benefits there.
airlied: Sun don't have any experience with GPUs.
MostAwesomeDude: More libdrm users is good because it makes stuff unified, but bad because interfaces have to be maintained longer. :T
nanonyme: airlied: Well, if the other alternative is that AMD starts using resources in writing them closed drivers?
airlied: Sun have had plenty of time to get involvde with drm
airlied: they seem to have ported it all in private and not talked to anyone
airlied: the OSOL patches to libdrm were a bit of anightmare
nanonyme: airlied: Do you seriously think it's a better alternative there would be more paid AMD coders writing closed source than opensource though in the past to rest?
nanonyme: hates ctrl+j
nanonyme: Ignore everything after though. :p
airlied: nanonyme: wherever AMd can make money I'll go with that :)
nanonyme: Not my call anyway so it'd be absolutely senseless to argue. :)
MostAwesomeDude: Sun will do its own thing anyway; can't really do much about it.
MostAwesomeDude: Well, we can always refuse their libdrm patches. :3
rah: [ 2.614843] [drm] radeon default to kernel modesetting.
rah: [ 2.614928] [drm] radeon kernel modesetting enabled.
rah: rah@orchid:~$ ls /dev/dri/card0
rah: ls: cannot access /dev/dri/card0: No such file or directory
rah: am I missing something?
nanonyme: glisse: Is nomodeset no longer possible with the Linus tree stuff?
rah: DRM is compiled into the kernel
rah: must it be compiled as a module?
rah: or must I use git drm modules?
biotube: which card?
nanonyme: glisse: Can't seem to be able to disable it in Grub if I enable it in staging.
rah: waits on another kernel compile :/
nanonyme: Yeah, still same incorrect rendering with r6xx-rewrite as before even with ExA compositing killed.
nanonyme: Somewhat comforting.
Sarvatt: have to use modules rah :(
Sarvatt: should see the failed to load radeon kernel module error in Xorg.0.log
rah: Sarvatt: just because there's no kernel module to load, doesn't mean there's no DRI
nanonyme: It doesn't, true.
Sarvatt: it wont use dri without it being a module for me, i had to recompile
nanonyme: rah: What does dmesg say for DRM?
nanonyme: (of course there might be a bug related to creation of the device node with inbuilt DRM, who knows)
evocallaghan: has returned.
rah: [ 2.614759] [drm] Initialized drm 1.1.0 20060810
rah: [ 2.614843] [drm] radeon default to kernel modesetting.
rah: [ 2.614928] [drm] radeon kernel modesetting enabled.
nanonyme: rah: Nothing more?
Sarvatt: here's what that situation looked like in my logs
rah: nanonyme: nope
Sarvatt: with radeon built in
nanonyme: I could give a few guesses on it but it wouldn't make a difference. Might as well use it as a module.
rah: I've removed DRM completely
rah: I'll compile DRM git modules
nanonyme: Eh, if you want KMS, don't. ;)
nanonyme: Use Linus tree DRM but have it modular.
Sarvatt: rah: that wont work
evocallaghan: nanonyme: Good day, OK, So Do the lads and ladies working on the Solaris DRM module stick around here?
rah: Sarvatt: why not?
nanonyme: Most people here are in either userland or Linux kernel with the exception of maybe two who work on FreeBSD.
evocallaghan: Also, Not sure where to start, Is there any open docs for the Stream Computing stuff as well?
evocallaghan: That is, the GP-GPU things ATi sell
rah: kernel compiles take an age on this old machine :/
evocallaghan: feels all alone :)
nanonyme: evocallaghan: I think you're supposed to read the GPU docs and write OpenCL with those.
nanonyme: No Stream docs.
evocallaghan: Ah I see.
evocallaghan: I don't me on the app level though.
airlied: evocallaghan: does Solaris have a drm worth talking about yet?
evocallaghan: Does the radeon driver support these SC boards then?
evocallaghan: airlied: They have a working one for Intel
nanonyme: evocallaghan: Doesn't count.
evocallaghan: Depending how you define Intel and Working ;)
nanonyme: ATi cards need a separate DRM.
evocallaghan: I know I know.
airlied: evocallaghan: I think if you define Intel to be one GPU maybe
airlied: they have a Linux drm from about 7 years ago :)
evocallaghan: airlied: I define it as a bunch of SSE thingy that I would like to kick out my window right now :/
agd5f: evocallaghan: there are lots of stream docs on the AMD website
evocallaghan: I know there is lots of docs but where to start :/
agd5f: THe stream folks are the ons that wrote the r6xx and r7xx ISA guides
nanonyme: admits being wrong then; don't you still have to implement something that talks with the GPU based on those though?
evocallaghan: Ah, that's good. So its a unified hardware ISA then?
agd5f: evocallaghan: yeah, changes a bit with each generation however
evocallaghan: OK right.
adamk_: There is the occasional appearance of a NetBSD/OpenBSD DRM maintainer.
evocallaghan: Also, Look, I have not really been in the ATi game and things have shifted around some over the last two odd years.
adamk_: oga, I believe.
evocallaghan: What's the deal now, Do you lads program for the AtomBIOS HV-type layer
airlied: evocallaghan: for card init we use the atombios
airlied: and modesetting
agd5f: evocallaghan: http://developer.amd.com/Pages/default.aspx
evocallaghan: Right, Would anyone mind taking a min to bootstrap me on what is what please. I am totally not in the game but really would like to get involved
agd5f: evocallaghan: stream stuff: http://developer.amd.com/GPU/ATISTREAMSDK/Pages/default.aspx
evocallaghan: Ah, yes. I found these links already.
agd5f: evocallaghan: also: http://www.x.org/docs/AMD/
evocallaghan: Sure sure, these SDK's are for Linux though
agd5f: evocallaghan: the stream sdk runs on the proprietary driver
evocallaghan: reforms question from before.
airlied: we have no open source stream sdk yet :(
agd5f: the docs are out there for an open implementation, but nothing's been written yet
evocallaghan: I would like to provide something that works with the opensource driver and the Ada lang you see.
evocallaghan: *This* is what I wanted to get involved in
biotube: Isn't OpenCL defined as a modified C?
evocallaghan: Sorry, I was not very clear as I really don't know my head from tail at the moment :)
evocallaghan: Yes, OpenCL is C, Looking into drafting a Ada spec that does the same thing.
evocallaghan: open hardware specs can really aid in this and the understanding of it. Hence me here..
airlied: well the current gpgpu open source plans are sorta up in the air, most people seem to think it'll involve Gallium3D drivers + LLVM
biotube: that makes sense - without the driver's involvement, it could screw X up royally
evocallaghan: Well we plan to replace X any way but that is a fair while off considering our mind share. Although we are very dedicated
evocallaghan: In don't think the SC stuff has much to do with X does it?
airlied: for gpgpu type stuff you really need some sort of KMS drm code
airlied: since you really want the kernel setting up the hw
airlied: not X
airlied: once the hw is setup then you need some sort of userspace driver to do the gpgpu work
airlied: OpenCL->LLVM->TGSI->GPU shader lang
airlied: seems to be the current horse people want to back
airlied: I have heard other people would really like to get the GPU acting more like a coprocessor
airlied: with actual compiled libraries that can use it.
evocallaghan: Thing is, *I* am already working on llvm stuff.
biotube: do we need two levels of bytecode, though?
evocallaghan: I'm currently learning the IR with the intent to port GNAT (Ada frontend) to llvm IR.
airlied: in the precompiled case, you'd have precompiled libs for each GPU
biotube: that would be fairly hairy
airlied: that would be more in line with the using it from gcc use case.
airlied: and a lot more like how we do CPUs today
airlied: think SSE etc
biotube: but there's a lot less variety in CPUs that most people care about
airlied: yeah as I said there are two groups thinking about it, one group comes from GPUs, one from CPUs :)
biotube: I was mainly thinking about eliminating the LLVM layer
airlied: biotube: LLVM does the optimising
airlied: biotube: otherwise you end up writing another optimising compiler
airlied: which again some people think might be a good diea
airlied: but they clearly have never written an optimising compiler
airlied: generally I think there'll be two levels of optimisation
airlied: one generic CL->TGSI compiler, one specific TGSI->GPU ocmpiler
airlied: my main worry with LLVM is I haven't seen anyone demonstrate yet that it can produce GPU code
airlied: I've seen lots of people speculating it was possible, but nothing actually running
evocallaghan: ponds around AMD's site :/
biotube: either way, once the sequence is decided on, expanding the language repetoire shouldn't be much harder than writing a new compiler
airlied: biotube: exactly, a new CL spec for a new language and a frontend to the compiler
evocallaghan: Are you guys using any of these neat tools from this site that lets you look at all the registers, see what's going on and such??
airlied: don't think they have any neat tools that run on Linux + open source driver
evocallaghan: How are you guys working? Just reading the docs and writing lines of C ?
evocallaghan: Do you have JTAGS for bringups or?
airlied: just C
airlied: and docs
airlied: for a long time just C
evocallaghan: No other tools, just vi :) ?
airlied: well $EDITOR
airlied: we have register dumpers and stuff
airlied: for debugging modesetting
airlied: but we wrote all of them as well
evocallaghan: Ah, ah
evocallaghan: and they are for Linux
evocallaghan: + I am going to need to get hardware as well
nanonyme: airlied: Possibly quite a lot of that stuff from the time before there were sufficient docs? :)
airlied: well docs are never sufficient :)
nanonyme: That's true but I'd just make an ass of myself if I went on trying to remind you they used to be a lot more scarce.
evocallaghan: Anyone know a retailer in the UK for these SC boards?
airlied: nanonyme: the big problem wasn't so much the docs as having someone you could ask questions :)
nanonyme: Ah, right.
nanonyme: That'd be Cooperation with capital c, me thinks.
airlied: like docs are great but really without someone inside the firewall they are a real pain.
evocallaghan: feels he is asking prob too many pointless questions :(
airlied: I've no idea what an SC board is :)
evocallaghan: Oh sorry, Stream Computing
airlied: thats a marketing name though
evocallaghan: I know that :~
airlied: though if bridgman is around he can probably tell you what they are really called
oga: adamk_: yes, i'm OpenBSD.
evocallaghan: FireStream 9250?
nanonyme: "According to TGDaily, the 9250 features ATI's upcoming RV770 GPU at its core"
nanonyme: Not a guaranteed fact though, coming from an arbitrary magazine.
agd5f: evocallaghan: any recent gpu should be fine
agd5f: the sc boards are just headless
biotube: r6xx recent enough?
evocallaghan: agd5f: i see ok, because the nvidia stuff is very different from the normal boards.
airlied: evocallaghan: it probably isn't, they just want you to believe it is :)
agd5f: evocallaghan: the sdks will work on both
agd5f: well, the sc cards are headless and have multiple gpus on them
agd5f: so they are a bit different
evocallaghan: According to one of my clients that are indeed very different. However, I can't confirm this first hand
evocallaghan: http://www.x.org/docs/AMD/ Umm, which one do I start with?
agd5f: evocallaghan: depends what board you buy
evocallaghan: Whatever is easies to start with.
agd5f: evocallaghan: I'd start with R5xx_Acceleration_v1.3.pdf and R6xx_R7xx_3D.pdf
evocallaghan: pick your fav :)
agd5f: those are the programming manuals for r3xx-r5xx (more or less) and r6xx-r7xx
evocallaghan: OK, I only really want a introduction
agd5f: evocallaghan: still your best bet
airlied: evocallaghan: depends on what bits you want an intro to :)
agd5f: the others are register guides
agd5f: evocallaghan: the ISA docs on http://developer.amd.com/GPU/ATISTREAMSDK/Pages/default.aspx
agd5f: are also a good place to start
evocallaghan: Well a general overview would be best however if its a particular card so be it.
airlied: evocallaghan: like if the goal is an OSOL + OpenADAL gpgpu framework
airlied: I don't think those docs will help you get far :)
airlied: you'd probably be better trying to get Linux + OpenCL system going first
agd5f: evocallaghan: if you are interested in the instruction set, definitely read the ISA docs
airlied: and working the OSOL and ADA bits afeterwards
evocallaghan: These SDK's are useless to me, I am looking for the low level stuff like in http://www.x.org/docs/AMD/
biotube: The ISA doc seems to be the closest there is to a programming guide
airlied: but yeah LLVM GPU stuff to talk to the AMD ISA would probably be interesting
evocallaghan: There is more then one of us working on this Ada stuff.
agd5f: http://developer.amd.com/gpu_assets/R600_Instruction_Set_Architecture.pdf and http://developer.amd.com/gpu_assets/R700-Family_Instruction_Set_Architecture.pdf
evocallaghan: I'm going to handle the stuff 'in the kernel'
airlied: so who's doing the bit between the ADA frontend and the kernel :)
evocallaghan: This looks good => http://developer.amd.com/gpu_assets/R700-Family_Instruction_Set_Architecture.pdf
airlied: since thats the bit that isn't done at all
airlied: the kernel bit for OSOL would mostly be porting kernel modesetting drivers and drm
EruditeHermit: Sarvatt: hi are you using auto-xorg-git?
evocallaghan: me and someone called charlie in our IRC room
agd5f: R6xx_R7xx_3D.pdf explains the pipeline and how to set up the card to render/compute/etc.
evocallaghan: I will read both http://developer.amd.com/gpu_assets/R700-Family_Instruction_Set_Architecture.pdf and http://www.x.org/docs/AMD/R6xx_R7xx_3D.pdf then
agd5f: evocallaghan: good choices
evocallaghan: :) Thanks for the guidance :)
evocallaghan: agd5f: I want to get a firm understanding of both the low level and the high level stuff you see. charlie will be doing mostly high level stuff, I'm working on GNAT -> llvm layer and such. Let Sun do all that free work for us in regards to the DRI port
nanonyme: Hmm, seems (by newsletters and forums) be that the latest on Solaris was someone was interested in doing the actual porting towards the beginning of this year, noticed it took enormous amount of man hours, thought there's probably tons of more experienced guys working in Sun on the thing and quit. (when in reality there's one or at best two Sun engineers working on the DRM)
nanonyme: Not very convincing.
evocallaghan: But I *also* wish to help out with the driver you see. So will need to understand the hardware.
airlied: you still don't really have the LLVM->GPU bit covered, which is the bit that'll screw you :)
evocallaghan: gets confused with all these TLA :/
evocallaghan: Sure, however this is already a years worth of work ahead of us so..
airlied: I'd reckon about 5 man years :)
agd5f: evocallaghan: start reading the source too. RIchard wrote a basic compiler for the GPU for supporting GL
evocallaghan: I'll speak to the gf
nanonyme: airlied: Better get at least five men working on it then. ;)
evocallaghan: Isn't it more a matter of adding an LLVM GP-GPU backend for the radeon ISA?
evocallaghan: Do you guys pass the driver source though lint checks ?
evocallaghan: I was outraged with the Q of the Intel driver btw.
airlied: evocallaghan: if you had an llvm gpgpu end
airlied: evocallaghan: llvm need a bit of work I think to target a GPU
evocallaghan: At some points they did not even check return values of malloc() nor ioctl() O_o !?
airlied: hehe lint
agd5f: evocallaghan: patches welcome :)
airlied: malloc can't fail in the modern world
airlied: more is the pity.
airlied: overcommit ftw.
evocallaghan: lol, it sure can :D
evocallaghan: agd5f: def, I look forward to !
evocallaghan: I done some very small patches to the intel one already :/ http://cgit.freedesktop.org/mesa/drm/commit/?id=cea2d29ee49f23d560f0088a1a3dd01932a1eaf4
evocallaghan: feels bitter about remotely helping them
nanonyme: Looks like an interesting mistake. Wonder if that's a leftover from an API change.
evocallaghan: Who knows
airlied: not exactly end of the earth
nanonyme: No, not really.
airlied: I actually think the compiler should handle that
evocallaghan: there code is a mess. Looks like its just for protyping if you ask me
evocallaghan: oh, that;s a bad example of the 'bad stuff'
nanonyme: airlied: Exactly why I chose the word interesting.
airlied: evocallaghan: but that isn't really bad.
evocallaghan: No, that's no big deal I know..
evocallaghan: Its the unchecked malloc's and ioctl that got my worried
airlied: I can show you much worse code that passes lint :)
evocallaghan: Any way..
evocallaghan: http://cgit.freedesktop.org/~glisse/radeondump/ Is this the dumping tool you where talking about?
airlied: one of them
airlied: also ~airlied/radeontool
nanonyme: Oh, oops. Missed the last few lines. Off to sleep. ->
evocallaghan: I find the xorg git respo a bit messy and confusing
evocallaghan: do I fetch the master from here? http://cgit.freedesktop.org/xorg/driver/xf86-video-radeonhd/
airlied: no http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/
airlied: yup for radeontool
evocallaghan: what's the diff between all these drivers
airlied: all which drivers? ati and radeonhd?
airlied: some would say politics, others would say politics
airlied: we generally just take the fifth, point people at phoronix.com
evocallaghan: I know there was a little war on a while ago about atombios bla bla bla..
airlied: well then you know the difference
airlied: really with the move to kernel modesetting
airlied: the major differences are moot
evocallaghan: I just want me damm hw to work, not really interested in 'ultra' free people that cut off there own noses
evocallaghan: Acturally I forget which one is which and what the status of both are now?
airlied: the thing is you are using Solaris you are pretty much going to have to start from scratch :)
airlied: since you need kernel modesetting most likely to get useful hw access
airlied: basically -ati is the one we discuss in here
airlied: but really the DDX doesn't impact what oyu want really
evocallaghan: Well I would like to know the diff in a unbias way
airlied: you won't have to touch the DDX
nanonyme: Hmm, still decided to try that latest commit of r6xx-rewrite. Seems the lockups related to resizing redbook hello window are gone.
evocallaghan: Sure but I will want to know
evocallaghan: Is this the correct website to be on to find out http://www.radeonhd.org/ ?
nanonyme: Even sometimes manage to get it look like it should by resizing, it seems to sometimes redraw properly, sometimes improperly.
airlied: there is no difference unbiased :)
airlied: they both do very similiar things
airlied: the major functionality difference at present is radeonhd has HDMI audio support, -ati hasn't yet, -ati has KMS support and older GPUs, -radeonhd doesn't
nanonyme: agd5f: There's a funky phenomenon in redbook hello with newest r6xx-rewrite that if I reduce the size of the window, background turns black like it should. If I increase it, it turns blue. Originally it's grey. ^^
airlied: the other difference is radeonhd avoids using atombios to set modes on a couple of chip generations
evocallaghan: which one is the atombios one?
airlied: -ati doesn't aviod atombios
evocallaghan: ah, we here are the atombios version then ?
biotube: hmm... is there some equivilent to assembly for TGSL or is it just the byetcode?
airlied: evocallaghan: they both use atombios, just -radeonhd tries to use it less
airlied: TGSI is an intermediate representation
biotube: I know, but even Java's bytcode has an assembly
evocallaghan: OK, because I believe programming for the atombios is the right way about attack the problem at hand.
airlied: as I said we've moved all that code into the kernel on Linux going forward
airlied: and the kernel users atombios
evocallaghan: Not to start off any indeepth about it at 1am in the moring
evocallaghan: Ah right.
evocallaghan: is starting to get a picture now.
evocallaghan: Do I need this as well? git://people.freedesktop.org/~mhopf/AtomDis.
airlied: thats handy if you are fixing modesetting
airlied: not so much use for accel
evocallaghan: Can you give me a short and sweet desc of:
evocallaghan: * radeondump
evocallaghan: * radeontool
evocallaghan: * AtomDis
evocallaghan: Just so I am completely clear on them
airlied: they are all mainly modesetting debugging stuff
airlied: also helpful for gpu hangs sometimes.
MostAwesomeDude: - Debugging modesetting
MostAwesomeDude: - Debugging modesetting and some accel
MostAwesomeDude: - Dumping atom tables IIRC
evocallaghan: Great thanks
MostAwesomeDude: Hm, readin' scrollback. Which series card are you wanting to work on?
evocallaghan: airlied: Sure, I am just drawing up a picture how and what everything is. All just looked like a jungle to me before
MostAwesomeDude: (TBH I think that a lot of things in intel/i915/i965 classic are kind of poorly set up, but that's their call.)
evocallaghan: 'A' Stream Processing capable one.
MostAwesomeDude: Stream processing? I have no idea what that is. To Google!
MostAwesomeDude: Ooh, okay.
evocallaghan: Really does not matter which card exactly. I can go out and buy any I like.
MostAwesomeDude: So you're looking to get some of that GPGPU stuff going.
evocallaghan: That's the idea.
biotube: r6xx and r7xx should both be capable
evocallaghan: I guess I will buy the latest hardware, no point in buying old stuff.
MostAwesomeDude: Well, the fun part is that *all* Gallium cards should be able to do at least some of it.
MostAwesomeDude: Actually, I just realized that you can have lots of sanity tests with softpipe.
evocallaghan: Err, what are the license terms of this driver btw?
airlied: all MIT
evocallaghan: Just checking it was not GPL or something funny like that.
evocallaghan: feels safe again :)
DanaG: what's MIT?
airlied: BSD like
biotube: except more so
DanaG: What I mean is, what driver are you discussing, that's MIT licensed?
DanaG: Guess I should've quantified the "what"
adamk: Aren't all the DRI drivers MIT licensed?
airlied: all of the X.org code
adamk: All the Xorg ones, anyway.
airlied: well most of it
evocallaghan: "The stream processing hardware comes with a hardware interface called THIN (Thin Hardware INterface), or Close to Metal (CTM, previously named Data Parallel Virtual Machine), to open the GPU architecture in addition to native instruction sets to program developers. This allows to direct control of the stream processors/ALUs and the memory controllers, and permits bypassing of the 3D API layer."
evocallaghan: 1:30 am here, Good night all. Thanks for all the help and info and answer all my questions.
King_InuYasha: yo bridgman
King_InuYasha: finally did the upgrade
King_InuYasha: now I'm restoring the home directory
King_InuYasha: no more crazy flickers!
King_InuYasha: Fedora 11 is so much better than Fedora 10...
bridgman: oh good; it's nice having all the bits work together at last
bridgman: evocallaghan; couple of things if you read the backlog :
bridgman: if you want to try double precision, you'll need 3850/70 or 4850/70; the lower chips don't support the double precision instructions AFAIK
bridgman: second, CTM was deprecated a couple of years ago and replaced with CAL (Compute Abstraction Layer); all the other tools run on top of CAL
bridgman: CAL ships with the Catalyst driver
spstarr: hello bridgman
bridgman: hi spstarr
spstarr: is waiting to test the r6xx but, it seems its not ready for major testing yet?
biotube: still just hello world things, it seems
biotube: not even glxgears :(
spstarr: it will be nice to use the 512MB GPU for some fancy graphics later on
biotube: I think so too, but it's going to be at least fall
biotube: and even then it might not be stable
spstarr: im content waiting, but I will dive in once a blog says to begin testing
DanaG: I'm sticking with 2.6.30 for now... 2.6.31 has broken rfkill in hp-wmi.
biotube: DanaG: that's why I wait until the official release
biotube: less horrible bugs
spstarr: DanaG: I haven't tried AMT yet :)
dmb: for some reason, whenever I have kms enabled, it effects my wireless
spstarr: i turned it off in bios for now
spstarr: but! I will need it come GPU testing :D
spstarr: when i have to do a reboot from another box
DanaG: Last time I tried the wireless, even the "now works with AMT" wireless still doesn't work.
spstarr: did you configure it from lan?
spstarr: it just didnt connect the network?
DanaG: It still locked up, as if some interrupt handler was eating CPU massively.
spstarr: maybe depends on vendor?
DanaG: It only recovered when I hit "rfkill"
spstarr: i didnt try it on my lenovo yet
dmb: whats rfkill?
spstarr: radio frequency kill
DanaG: the wireless-toggle hotkey.
spstarr: i have physical switch to kill wifi
DanaG: or rather, the hotkey triggers rfkill.
DanaG: In my case, it's done in firmware.
DanaG: Hardware button works, but software can manipulate the thing via hp-wmi.
spstarr: I got seriously burned from rawhide
spstarr: rawhide is so much worse than debian unstable, its not even funny its more experimental
spstarr: given though
biotube: unstable's stable
biotube: it's just new
terracon: the beginning of a rawhide cycle is scary town!
DanaG: I remember Fedora touting their EFI support as far back as Fedora 9... but it actually didn't support EFI in Fedora 9. =þ
spstarr: terracon: well from f9-f10 i didnt have as much 'pain'
spstarr: but when rawhide totally breaks gdb, and random crashes with compiled code...
spstarr: you know something is *bad*
spstarr: i had to wipe out laptop and my build box
spstarr: so testing r6xx i hope i can reduce exposure to rawhide
spstarr: if its selective enough im fine
spstarr: kernel + libdrm + mesa + ddx bits
spstarr: then that should be ok to work with
dmb: i'm unfortunately going to have to use debian stable, as I need to use fglrx for my r5xx card
dmb: EXA is just unusable for my radeon x1400 on the open source driver
dmb: if it takes more then five seconds to maximize a window, its painful
bridgman: that doesn't sound like EXA is running
dmb: bridgman, doesn't help my resolution is 1920x1200 :P
dmb: its weird, it usually works all right at first, but after leaving it on for a day or 2, its unusably slow
bridgman: ahh, that's different ;)
fcami: dmb: what distribution / driver revision are you using ?
dmb: also, the mouse pointer tends to freeze at like 5 seconds at a time at various times, regardless of how long my display has been up
dmb: fcami, ubuntu jaunty
dmb: with latest bits of everything
dmb: including KMS
fcami: let me check what they use
dmb: with and without kms
spstarr: bridgman: does the r6xx support DisplayPort?
fcami: but that sounds very much like a bug dave fixed during F11 development - in late April IIRC
spstarr: the laptop has a DP port and my other r6xx has a HDMI port
dmb: fcami, would that be in drm, mesa or the ddx?
fcami: I think it's ddx
dmb: i might be using the modesetting fork of it
dmb: maybe that didn't get the fix?
fcami: that's the idea
bridgman: spstarr; hardware does, driver is being worked on
Sarvatt: do you get the same problem using the livecd on edgers dmb? because kms isnt supported at all on jaunty from the packages there so you're mixing and matching things and in a way that probably doesnt work right
spstarr: bridgman: ok, wouldn't make sense if this dual gpu laptop only supported displayport on one gpu
spstarr: bridgman: now, if I had a DP connector I could test that too :)
spstarr: my LCD screen doesn't have DP but you can convert DP i believe
dmb: Sarvatt, it was the same without modesetting
dmb: with the default stuff
dmb: Sarvatt, i will try the livecd edgers
dmb: and report it
dmb: but at a later date, i have to wake up at 630am :(
Sarvatt: if you're still using the packages from karmic the point still stands even without KMS, would be interested in if it works differently on the livecd
fcami: dmb: it's only 51 minutes away :)
dmb: Sarvatt, could be very possibly, i am using very very many packages from karmic including a kernel
dmb: before i compiled everything from scratch though
Sarvatt: did you alter libdrm to replace linux-libc-dev so you would have the newer drm headers available first like you need to do on jaunty?
Sarvatt: and remove the header deletion from libdrm debian/rules as well
dmb: nope, maybe i should try the livecd
dmb: i'll definitely try the livecd later, for now sleep
Sarvatt: you would have to grab karmics libdrm, make those changes, compile and install it, then mesa, then xserver then karmic's ati ddx to do it the right way on jaunty
EruditeHermit: Sarvatt: do you use the build scripts on edgers?
Sarvatt: yep, havent seen the changelogs for the scripts? :D
EruditeHermit: I tried it and the patching fails
EruditeHermit: it fails on the first patch
Sarvatt: i dont even know what package you're referring to
EruditeHermit: oh for radeon
EruditeHermit: if I do the ati switch
EruditeHermit: ./auto-xorg-git ati
Sarvatt: ./auto-xorg-git -H hooks-karmic -e 1 -g -d origin/debian-unstable -a 0ubuntu0sarvatt ati
Sarvatt: thats what i use for ati
EruditeHermit: let me try that
EruditeHermit: that seems to work
Sarvatt: its probably failing to merge debian-experimental which is older than debian-unstable
Sarvatt: -g makes it not merge and just add debian/ instead
Sarvatt: debuild -uc -us -b from the xserver-xorg-video-ati directory if you just want to build the debs
EruditeHermit: I was trying fakeroot debian/rules binary
EruditeHermit: but that failed
EruditeHermit: it failed in radeon_kms
Sarvatt: let me guess, you're trying to use this on jaunty too...
EruditeHermit: well I am building it on jaunty
EruditeHermit: I didn't use the karmic hooks
EruditeHermit: I used the jaunty hooks
EruditeHermit: I am building for a non kms purpose
Sarvatt: do you have karmics libdrm installed or something?
EruditeHermit: yes I do
EruditeHermit: is it not backwards compatible?
Sarvatt: thats what i mean, you cant use that as is on jaunty
Sarvatt: your drm headers are from linux 2.6.28 because of linux-libc-dev
EruditeHermit: the kms works on jaunty as is
Sarvatt: yes because you have the precompiled stuff
EruditeHermit: so I have to downgrade everything back to jaunty
Sarvatt: you're using jaunty.. you're breaking things by using karmic packages on jaunty
EruditeHermit: in subtle ways
EruditeHermit: I am impressed with how it has worked so far
EruditeHermit: only when the ABI changes will it stop working
EruditeHermit: but it does break my ability to compile stuff