damentz: gn8 noobs
x1250: is there any bug tracker?
arekm: bugs.freedesktop.org
x1250: thanks
x1250: is there any workaround for this bug? http://bugs.freedesktop.org/show_bug.cgi?id=10238
x1250: I wanto try vesa, since I'm having some problems and I want to know if it is the radeon driver.
x1250: I have a X1400, but when using vesa driver, Xorg dies with a "No screens found" message.
x1250: Maybe I asked in the wrong channel :), but anyway if someone knows, I'll be here :)
soreau: x1250: What problems are you having using the radeon driver?
x1250: soreau, I think it might be radeon, but I'm not sure. I have no other driver to test :(. Well, the problem is: I open a game or a movie, and the desktop framerate is fine. After some minutes the desktop becomes unusable, with very very low framerate. top shows nothing out of order though. I close the game (or the movie), and after some minutes, the desktop is usable again, with good 2D/3D acceleration. Odd issue.
x1250: movie->time->slow framerate->close movie->time->good framerate.
x1250: thats what happens
soreau: That does sound like a strange issue indeed. I don't know what might cause this exactly but out of curiosity, which vo driver are you using for the video player you're using?
x1250: the issue is not specific for video players, it happens also in 3D games.
soreau: Which distro?
x1250: I'm on ubuntu jaunty
x1250: I'll try to reproduce the bug to see if .xsession-errors has something
soreau: I wonder if there's any possibility it might be related to kms
x1250: whats that? is there any documentation on that somewhere?
soreau: Do you have direct rendering enabled?
x1250: soreau, yes, no problem with that, direct rendering with hardware accel
x1250: I'll try to gather more info when it happens, and I'll file a bug report.
soreau: kms is kernel mode setting, but it's probably not related. Someone else might have a clue as to what's going on here
etnoy: as far as I can see there is a problem with the radeon drivers in the latest xorg (6.9.0?) using the Radeon Mobility 7500
etnoy: I cannot use 16 bit mode anymore, and 24 bit is way to slow on my Thinkpad T30
etnoy: compiz and all opengl stuff worked flawlessly in Ubuntu Hardy, but in Intrepid everything fails
etnoy: I have documented it all here: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/290359
etnoy: if anybody would mind helping me out, I'd be very grateful.
etnoy: (open-source radeon driver)
x1250: etnoy, is there any new radeon driver on some launchpa PPA?
x1250: maybe you could search for one, and test it.
etnoy: hm
etnoy: x1250: I don't quite understand what you mean, where should I search for one?
etnoy: as you can see, the bug has been confirmed but noone has said anything about it yet, I believe it hasn't been fixed yet
juergbi: hi. i've tried the just released 6.10.0 driver with my r600 card, and i only get a white screen, no apparent error messages in the log
x1250: etnoy, PPA's on launchpad are personal repositories where people (developers) test new sofware versions.
juergbi: is this a known issue or should i file a bug?
x1250: etnoy, found this:
x1250: deb http://ppa.launchpad.net/fabio-pedretti/ubuntu intrepid main
x1250: deb-src http://ppa.launchpad.net/fabio-pedretti/ubuntu intrepid main
x1250: etnoy, this guy claims to have updated versions for the radeon drivers: https://launchpad.net/~fabio-pedretti/+archive
x1250: use them at your own risk :)
etnoy: alright!
juergbi: i'm using two monitors via with 1920x1200 each, the setup works with radeonhd drivers
etnoy: x1250: I'll try them and check back
etnoy: what annoys me is that everything works in an older version, and nobody seems to care about my relatively old hardware :)
x1250: etnoy, you could also use the old xorg and driver. I guess there should be info on how to do that in ubuntuforums.org
x1250: by old I mean hardy's
etnoy: ah
etnoy: I'll search for that, didn't even know that was possible
etnoy: am I supposed to file the bug somewhere else? fd.o?
x1250: if you want: bugs.freedesktop.org on xorg proyect.
boghog: does anyone know if it is possible to use opengl/glx with this driver, even if it is software (no acceleration) only? I need to see if some opengl apps I have compile and run
MrCooper: boghog: yep, it's possible
MrCooper: agd5f: maybe AGPMode should default to 1 for all mobility RV350s?
boghog: ah ok, I switched from fglrx to this driver today and am pretty happy with it, 2D seems much faster (my card is a radeonhd 4850)
MrCooper: thank your CPU then, as there's no hardware acceleration whatsoever yet for >= R600 :)
boghog: oh, heh
boghog: that's weird though, 2D really is faster than with the binary driver
boghog: should I be concerned if I see things like "mtrr: no MTRR for d0000000,10000000 found" on dmesg when I start X with the radeon driver? I got the same with fglrx, but as far as I can tell I have mtrrs enabled in my kernel (2.6.28)
MrCooper: doing stuff with the GPU doesn't automatically make it faster
boghog: ah
MrCooper: especially if only parts can be done with the GPU
boghog: yeah I noticed I could play HD fairly smooth too, but with a higher CPU usage
boghog: HD vidoe that is
boghog: video*
x1250: hey guys, is there any wiki or knowledge base out in the wild?
adamk_: x1250: http://www.x.org/wiki/radeon
x1250: adamk_, thanks
bigon: hi, when I have heavy IO X become almost unresponsible (cannot switch workspace, minimize a window..) does it comes from the radeon driver?
agd5f: MrCooper: I wonder if there have been some changes in the upstream agp code as all my agp r3xx cards generally worked fine with higher agp modes
etnoy: bigon: check your DMA settings for your harddrive
etnoy: make double sure it's turned on
bigon: etnoy: well It use the scsi subsystem (even it's an ide drive) so I cannot change that
bigon: UDMA/100 in dmesg so it's ok
etnoy: ok
etnoy: well at least I tried :)
bigon: ^^
ossman: is topic still correct? I thought there was a code drop on the 30th?
adamk: There is 2D acceleration, but it's really still geared at developers.
adamk: Actually... That's true for radeonhd.
adamk: I don't think the code has been incorporated into radeon yet.
bigon: mach64_drm.h has desapears?
bridgman: most of the google hits for missing mach64_drm.h say "you have to have drm source when building mesa". Does that fit your situation ?
rnoland: um, it should be installed from libdrm
bridgman: so drm needs to be built, not just have source (sorry for the dumb question)
bigon: bridgman: actually ubuntu remove these header form libdrm and use the one that are in the kernel
bigon: (pkg linux-libc-dev)
ndim: bigon: Oh. Ubunto do that as well?
ndim: I was only aware of F-10 so far. But it's good to see more than one system on that list.
oga: all should do that. fragmenting those headers all over the place is really quite dumb.
bigon: and mach64_drm.h is not in the kernel which make mesa to FTBFS
berniyh: hi, what is "libXinerama" used for these days?
berniyh: shouldn't it be deprecated?
berniyh: or did I get that wrong? ;)
jcristau: it gives you screen geometry
adamk: berniyh, The xinerama extension is still how window managers know to handle window placement with twinview/xrandr/etc.
berniyh: hm, ok
berniyh: so if one has only one monitor, it'll still make sense to install stuff without xinerama support?
jcristau: why would you disable xinerama support?
adamk: It really seems like more of a hassle.
jcristau: (other than "because i can")
berniyh: jcristau: no idea, I won't
berniyh: and I don't really know the reasons atm, but people are asking for keeping it optional
berniyh: hm, I think that option will have to go ;)
berniyh: thx anyway ;)
rmh3093: airlied: ping
MrCooper: agd5f: not sure, I just notice that a lot of reports recently seem to be about Mobility 9600s...
spreeuw: any news on h264 decoding acceleration?
gustaf1: any news on KMS/GEM? ;)
arekm: first doesn't exist, second doesn't work well
gustaf1: KMS/GEM for 2.6.29, or is that to hope for too much?
airlied: arekm: it works well, its just not nice code.
arekm: airlied: tried kms, black screen and oops (I still have it in logs probably)
airlied: arekm: I didn't say it the branches upstream were useable :)
airlied: arekm: the stuff we ship in F10 mostly seems to work for everyone, albeit a bit slower than I'd like..
arekm: so works well in someone private repo? geez :)
gustaf1: you hold a "gem" not yet commited airlied o_O!
gustaf1: oh ok
airlied: arekm: the code is all public, its not private at all.
spstarr: hullo
kdekorte: airlied, is the new boot screen in F10 supposed to work with r600?
spreeuw: is the new ati 670V northbridge video supported?
airlied: kdekorte: nope it'll be in F11, the code was mostly there I just didn't get it finished.
spreeuw: radeonhd?
arekm: airlied: I tried modesetting-gem mesa branch and radeon-gem-cs ati driver branch - ended with oops. Are these correct branches then?
kdekorte: airlied, just got the little bar on the bottom with r600 and was not sure if that was expected or if I should have the fancy boot screen
airlied: arekm: the kernel branch is in my kernel tree.
airlied: arekm: but there is no libdrm branch to go with it at the moment,
arekm: uhm
airlied: as glisse moved some stuff and I haven't moved it back yet.
airlied: its painful but I'd prefer to get mesa working properly than worry about maintaining branches.
airlied: goes back to bed :)
arekm: too bad, means less testing by others ;>
gustaf1: kdekorte: the dull little ascii bar at the bottom of F10 is there even for intel hw. i'm not sure it works as expected for anyone. now I don't use fedora, but saw one at work who installed it on a decently modern (one year old "high end") laptop with intel graphics..
kdekorte: gustaf1, my machine has an intel G35 in it, but since the drivers were so bad, I dropped in an r600 card. Been happier ever since. But am patiently waiting for 3d
gustaf1: my friends card is a 965 i think. you'd expect it to work, but no no. and dual head is a nightmare on that machine. resolutions gets messed up etc, while on ubuntu this works rather nice (i'm not an ubuntu user neither tho)
kdekorte: any idea when we should see xv support on r600?
kdekorte: I thought I read that MAD was working on it
bridgman: kdekorte; we pushed initial Xv code for r6xx/7xx into a radeonhd branch over the holidays; just trying to get the shader working properly
boghog: ooh
boghog: is feeling adventerous
bridgman: hopefully over the next couple of days; we found a few more things that *weren't* the problem today ;)
bridgman: there's only about six instructions in the shader, so we'll run out of things to look at soon
Terman: bridgman: is there a specific reason why this develpment is done in YABs (yet another branch)?
Terman: bridgman: why are there r600 branches for drm and radeonhd?
bridgman: just that we don't want to break master, and we would rather get it out sooner than do a bunch of testing ;)
Terman: well, git head may be broken, stability is what releases are for :)
bridgman: if you want to put something in master you need to do a bunch of testing, and we knew it wasn't fully working yet, but the main point of the release was to get sample code and register info into developers hands
Terman: and if some of the patches have side effects, it's nice to know about them earlier, rather than later
bridgman: definitely; we don't get as much coverage in a branch but I don't want to stick untested code into master either; again, the code in its current form is aimed at developers not end users
Terman: but that's probalby more a matter of taste then anything else
bridgman: absolutely, but when we're pushin' teh code our taste rules :0)
Terman: yep :-)
bridgman: seriously, if I were an end user I wouldn't want the code yet; Xv doesn't work, so the only benefit is from EXA, and EXA is slower than shadowfb right now
bridgman: if I had working Xv I would grab the code in a flash and live with the slower 2D
bridgman: as soon as it is "better than what we have now" for users I expect it will get merged
bridgman: and hopefully that will be days not weeks
Terman: that's true. but if i were (a mere) user, then I wouldn't use tools like git, vi and compilers :-)
bridgman: there's a lot of debate on that; I don't know the answer for sure; until we can shorten the average time between upstream and appearing in a distro I think building is going to be a necessary evil
bridgman: but I *really* want to get away from that as soon as possible
Terman: bridgman: I'm a (mostly) happy r5xx user ;) who is just following the progess (including commit logs)
bridgman: bleeding edge build/package systems like edgers are handy for that
bridgman: yep, 5xx is a nicer place to be right now; faster 3d will take a while but it is coming
bridgman: and everything else works pretty well; assuming git, vi and compilers are your friends ;)
Terman: bridgman: I'm more interested in more stability - don't care much about games or effects
Terman: which reminds me: I need to test whether I still have a problem with current drm/radeonhd head
bridgman: yeah, there seem to be a couple of clusters of problems recently; I suspect one might have something to do with both drivers making non-coherent tmds the default, but there seems to be something wierd happening with xserver 1.6 as well
Terman: ok, problem seems to be gone :-)
Terman: -> bed
bridgman: oh good ;)
rmh3093: lol
bridgman: I meant "oh good that the problem seems to be gone
bridgman: "
bridgman: just in case Terman reads the backlog ;)
rmh3093: :)
yangman: nothing wrong with dev'ing new features in a branch. that's why we have branching in the first place ;)
rmh3093: people that dont like branches just dont know how to use git
yangman: that's the impression I get
yangman: too
rmh3093: anything new on the radeon kms front
rmh3093: it all the work still hidden in airled repos?
bridgman: afaik most of it is in F10 and rawhide and those depots are visible
bridgman: someone on dri-devel summed up airlied's situation with one word...
bridgman: SIGBABY
bridgman: I think everyone is psyching themselves up to get ttm ready for going into the kernel
bridgman: I don't know the specifics but it seems like there is some non-trivial work to be done
bridgman: or maybe just a big heap of trivial, not sure
rmh3093: bridgman: i didnt mean literally hidden, i just meant not merged into master yet ;)
rmh3093: i need EEDID more than i need KMS right ow
rmh3093: now
rmh3093: too bad, kms was sweet when i had it working a month or so ago
bridgman: ah, got it; I imagine it will stay out of master until it is also pretty much ready for kernel
bridgman: plus or minus a bit of begging and a brief fistfight
rmh3093: its its not even in modesetting-gem
rmh3093: thats the the big disapointment
rmh3093: its been in rawhide for months
mjg59: The userspace API hadn't settled down
mjg59: Now that intel KMS is merged, I'm guessing that's less of an issue and it'll be handled once Dave's back with us
revx: ROFL
revx: mjg59: good luck on that
revx: my son is 3 months old now
bridgman: AFAIK it's only practical for the code to be "alive" in one place... so if Dave's trying to push it out in a distro it needs to be in Rawhide rather than an fdo repo
revx: what have I gotten done in the last 3 months? nothing...
mjg59: It's in his own fdo repo
mjg59: But yeah, when you're developing against a specific kernel release that you're going to ship, it's not really practical to keep it in the main tree
bridgman: when our engineers have new babies they normally stay home for a week, then come into work so they can get some sleep... then after a couple of weeks things frequently settle down
rmh3093: haha