udovdh: any ideas?
udovdh: I just updated the bug
egbert: udovdh: your link doesn't seem to point to a bug.
udovdh: that is the right link
udovdh: I just copied the link after submitting my info
udovdh: the response I got points towards a config error (i.e.: my fault) but testing the suggestion yields no progress
udovdh: could I attach extra info to make things more clear?
udovdh: if so: what?
egbert: udovdh: maybe emmes can help here.
udovdh: emmes is a developer?
egbert: udovdh: yes.
udovdh: emmes: ping...
egbert: udovdh: you will meet him on fosdem.
udovdh: ah, ok
udovdh: the bug currently is not a big problem
udovdh: but it would be nice(tm) if the static xorg config can work as described in the manual page
udovdh: which is the expected behaviour if you read the feedback I got
TGEN: RightOf works like that here
udovdh: in the config?
udovdh: not on the commandline?
udovdh: the cli is OK for me; xrandr works
udovdh: but via xorg.conf is the issue
udovdh: TGEN, can you show your config? or attach to the bug please? I could compare
udovdh: pastebin is OK as well
udovdh: it is not complex but I am puzzled about the RightOf warning
udovdh: my config is in the bug
udovdh: TGEN, thanks!
TGEN: udovdh: perhaps it's something to do with your Virtual space not being big enough or something?
udovdh: 2560x1024, just OK
udovdh: and it works from the cli?
TGEN: oh, right
udovdh: 1280x1024 times two
emmes: udovdh: can you run the Xserver with -logverbose 7 and attach a logfile?
TGEN: tgen@virgo$ pkg_info | egrep 'xorg-server|radeonhd'
TGEN: modular-xorg-server-18.104.22.168nb3 Xorg X11 Server from modular X.org X11
TGEN: xf86-video-radeonhd-1.1.0 Modular X.org driver for Radeon HD series
emmes: in fact the config looks good - and it does work here
udovdh: I spot some small differences
udovdh: will try again
emmes: maybe you want to remove the two monitor references in the screen section
emmes: i don't think they are correct
emmes: at least two are not supported there
emmes: and with randr there shouldn't be any
udovdh: emmes, did remove them
udovdh: (WW) No monitor specified for screen "Screen0".
emmes: that's ok
udovdh: still two times the gdm login screen
udovdh: instead of one
udovdh: when I used the matrox g550 with mergedFB
TGEN: perhaps if you remove your section serverlayout altogether?
udovdh: will try
emmes: i need the logfile, otherwise i cannot see what's going on in your case
udovdh: no change
udovdh: plain xorg.0.log?
udovdh: or better?
udovdh: triedwithout serverlayout, no effect
udovdh: do you wnat xor.0.log of with or without serverlayout?
emmes: without won't work, because the monitor sections won't be found
udovdh: it does give me a picture...
udovdh: with serverlayout...
emmes: yes, but it won't find the options to set one monitor next to the other, even if it would work with serverlayout...
emmes: -logverbose 7, please
emmes: ah, moment
emmes: (WW) RADEONHD(0): RandR: While switching off TV_7PIN_DIN: output DAC B is also used by DVI-I_1/analog - ignoring
udovdh: that is there all the time
udovdh: cant comment any more on that
emmes: no, looks good. this is only TV. but we have several issues with some board layouts.
udovdh: does not give that error on this pc (same board) with single DVi-D connected lcd
emmes: i still need -logverbose 7
udovdh: ok, will do
emmes: RRCrtc #0 [rhd CRTC 1]: active 1  mode 1280x1024 (1280x1024) +0+0
emmes: RRCrtc #1 [rhd CRTC 2]: active 1  mode 1280x1024 (1280x1024) +0+0
emmes: so different crtcs are used, but both at +0+0
udovdh: that's why I tried to use the Position keywords as in the config for the bug
udovdh: so how can I avoid this?
emmes: did you try with Position 0 0 in one monitor section, and position 1280 0 in another?
udovdh: clearly RightOf is not clear
emmes: (and no RightOf)
emmes: also, did you try LeftOf instead of RightOf? Maybe also in the other monitor section? I assume we're hitting some general randr problem here...
udovdh: no leftof, only combined with rightof I guess
emmes: no, just one leftof in on of the monitor sections.
udovdh: (II) RADEONHD(0): State at POST-OutputDpms:
udovdh: RRCrtc #0 [rhd CRTC 1]: active 1  mode 1280x1024 (1280x1024) +0+0
udovdh: RRCrtc #1 [rhd CRTC 2]: active 1  mode 1280x1024 (1280x1024) +0+0
udovdh: for using position 0 0 and 1280 0 together
emmes: hm. i thought so :-(
emmes: did you try putting the rightof / leftof in the other monitor section (and pointing to the first one)?
udovdh: trying now
emmes: what version of the xserver are you using anyway?
udovdh: no change for leftOf
udovdh: current Fedora 8
udovdh: Build ID: xorg-x11-server 22.214.171.124-40.fc8
emmes: should be recent enough.
udovdh: guess so
udovdh: I do yum check-update almost every day
emmes: sorry, no clue ATM. maybe on fosdem, if you're coming
emmes: be sure to have some debuginfo packages installed (or however they are called on fedora ;)
udovdh: I won't be carrying my PC with me
udovdh: but we could log in into it with soem effort
udovdh: I am not afraid of debuginfo
udovdh: how could I find the cause?
udovdh: or rather: how cna I use gdb efficiently for this?
udovdh: does `grep rhdRRCrtcModeSet: /var/log/Xorg.0.log ` give me the right info?
emmes: i would need to single-step or at least set breakpoints deep in the randr code.
udovdh: too deep for me?
udovdh: I know the breakbpoint idea
udovdh: just don't use them very rarely
udovdh: even in gdb
udovdh: so it appears to be some logic problem?
udovdh: config is parsed (no warnings about that) but not really used
emmes: probably a bug, but you never know
udovdh: latest log at http://pindarots.xs4all.nl/Xorg.0.log
udovdh: I also added some info to the bugzilla item
emmes: this is truly nontrivial - maybe you want to try a more recent xserver, but I won't tell you that this *will* fix your problem...
udovdh: so check the fedora-testing/updates section?
emmes: probably. i never installed or used fedora so far.
udovdh: 1.4.99 is in f9 testing
udovdh: 126.96.36.199.42 is in testing-updates
udovdh: # yum --enablerepo=updates-testing update xorg-x11-server-Xorg
TGEN: I've ran RedHat 5 and 5.2 for a couple of hours once ;)
udovdh: no change
udovdh: taht mus have been 10+ years ago?
TGEN: a long time ago for sure
udovdh: thanks for the assistance
Temujin_: hey folks, does anyone have more detailed info on the practical effects of the recent changes made to the driver (updated atombios, ObjectID, etc.)?
Temujin_: i read through today's irc log and didn't see anything
airlied: Temujin_: its just an update to the latest AMD codebase..
airlied: some of it might be needed for newer chips, but mainly AMD just want to keep it all in sync
Temujin_: airlied, thanks
Temujin_: btw, i'm building the new radeon 6.8 driver now, going to try that
libv: Temujin_: it was much overdue information necessary for rv620/635 ;)
Temujin_: ok, not applicable to me, gotcha
libv: significant parts of the interface changed significantly, and we still aren't entirely certain how some things are supposed to fit together
michaellarabel: libv: Any idea when you'd expect basic RV620/635 support?
libv: but at least the basic modesetting and the dacs are working, and plls should be good too, as soon as i write up the actual code... but i'm currently trying to dig out the Xorg logo again to print some nametags
libv: michaellarabel: fosdem is preempting everything atm :)
libv: michaellarabel: we could push this out once i convert the userland tool to a pllset routine, write up the save/restores... but then there's nobody over the weekend to help fix issues :(
Temujin_: you guys take weekends off? how dare you! you're not allowed to have presonal lives. now get back at that computer, code monkey!
michaellarabel: I don't have access to my test hardware until next week again, but was just curious its status.
libv: Temujin_: this weekend is not for personal stuff
libv: Temujin_: it's FOSDEM
Temujin_: heh heh, i was jk
libv: Temujin_: i spent all day traipsing around nurnberg getting the few things i still need :)
libv: we will at least provide half the seats in our devroom with their own powerplug :) with some users providing their own power strip, i guess this will be pretty good :)
libv: last year we managed with 20 plugs for 58seats or something :)
Temujin_: is busy googling fosdem
michaellarabel: Seating for the devroom is at 100 this year, right?
Temujin_: wow, that looks awesome
marcheu: libv: your "mother of all power rails" helped a lot for sure :)
libv: marcheu: this year i have 4... and i will pull 2 sixers from the office here too
libv: egbert doesn't need those pcs on friday anyway ;p
libv: plus some other extension cords, as i don't know the layout of this new devroom
marcheu: I see the layout, but don't know where the plugs are
marcheu: it's a room like mozilla had last hear
libv: right, but mozilla also has 100 iirc
marcheu: yes, just saying it's the same kind of room
aneas: sorry to ask a question that i could probably answer myself, but advice is sometimes better than constant trial&error. i have a ATI Mobility x1700 (wikipedia says RV530) in my asus-notebook and an external 22" monitor connected by dvi (two different resolutions). right now i am using radeonhd 1.1.0 and it works, kind of. video is awful and because of the different resolutions i have an invisible area
aneas: considering the latest changes to the radeon driver, would it be better to switch to it?
marcheu: use fakexinerama
aneas: will this trap the curser into the visible area?
libv: aneas: we are just a few days coding away from providing the surrounding infrastructure for scaling correctly
libv: the lowlevel code is slowly bitrotting on my very machine here :)
libv: it's going to bite egbert on saturday too, but he can freely blame me for that :)
marcheu: libv: doesn't fakexinerama solve the invisible area issue ?
libv: marcheu: no idea :)
aneas: what does scaling mean?
libv: what it even is supposed to be... one big framebuffer?
libv: aneas: radeonhd hw can scale up and down whatever you like, quite nicely
marcheu: it fakes old xinerama from a single big mergedfb/randr1.2 display
libv: aneas: so one of your two monitors could run at the "resolution" of the other
libv: while being actually driven at its native resolution
aneas: sounds like your fooling either the user or the card ^^
libv: the testing i've done with this were very nice... it makes what unichrome allows for scaling absolutely laughable :)
libv: aneas: hardware allows it, so we are not fooling that :)
libv: and our log will quite verbosely tell what the driver is doing :)
aneas: so basicly with this i could have a 1280x800+1650x1050 desktop just as one would suppose it should be?
libv: well, what really should be possible is to have a those sitting side by side without the cursor going into the dead area
aneas: ok, great. i can wait for that :)
libv: i have no idea how or if RandR handles this (not that NoRandR does it better, it's things that aren't being looked at yet in that context)
aneas: will be checking git frequently
marcheu: your WM has to handle it, or use fakexinerama
marcheu: randr12 is not going to do that itself,
libv: aneas: but with scaling you could get 1280x800 shown on both or 1680x1050 shown on both (first one will be the better option)
aneas: my wm handles everything pretty well, its just the mouse cursor that bothers me. i already wrote a mouse blocker window, but thats not the right way ;)
libv: aneas: in 10h or so, emmes will be around, and he might be able to explain what is going on here :)
aneas: emmes, ok, thx :)
danceifyoucannot: what do you do when people are slamming the doors to piss you off?
aneas: remove the doors
aneas: use windows
marcheu: danceifyoucannot: hi, bot
libv: ah, figured out the order of keywords in that command :)
rx__: what was that?
libv: a bot apparently
rx__: and bots are bad?
marcheu: rx__: /msg him for deep conversation :)
marcheu: rx__: well we had on on #nouveau, he'd spew stupid sentences at random times and disturb the chan
marcheu: not sure what's the point
libv: marcheu: ah, so you lured him in here...
marcheu: libv: I think he picks the populated channels...
libv: well... ;p
danceifyoucannot: what would you do if someone bigger than beat you up? and made tons of doom doom sounds on the floor and made it shake etc?
libv: ah, urgh, i thought n= was something irssi was pulling :(
aneas: Published on February 22, 2008.
aneas: 22 Feb?
rx__: uh oh ;)
rx__: article leak!
marcheu: yup :)
aneas: looks like a preeeety interesting article
rx__: although the ident can very easily be changed ;/
aneas: the promised tcore source code is not on the amd page :/
aneas: but i guess it will be day after tomorrow :)
rx__: shakes fist
libv: rx__: what do you think this will change for you?
rx__: what will change?
rx__: for radeonhd?
rx__: or what?
rx__: i was just saying that it would be easy to evade the *!*death@* ban :)
dmb: the tcore examples have been released??
dmb: does that mean closer to 2d/3d on r500!!??
rx__: uh.. 2d is already there
dmb: rx__: well, i meant dri
rx__: i meant dri
dmb: rx__: dri is all ready here?
dmb: since when?
rx__: it's been here
dmb: i was always told there wasn't
aneas: i dont have no dri :(
osiris_: drm (not dri) is already there, and drm != 3d
rx__: i see this hasn't been advertised very well
Obscene_CNN: you heard the news here first :D
dmb: eww cnn :D
aneas: well, then ... advertise it please :D
rx__: sec.. let me grab appropriate git urls and such
rx__: git clone git://anongit.freedesktop.org/git/mesa/drm
rx__: cd git/linux-core
dmb: doesn't drm mean compiz crap, which doesn't work yet (and i don't care for it much anyway)?
rx__: make radeon.o drm.o
rx__: cp radeon.ko /lib/modules/
rx__: cp drm.ko /lib/modules/
Obscene_CNN: posted the news leak on 3 channels
rx__: like osiris_ just said drm not equal to 3d
aneas: so is there any benefit with drm?
dmb: that articles seems to say that ati may opensource there drivers
aneas: or do we still need that *im a noob* other part of dri to use those kernel modules?
osiris_: aneas: yup, we can make exa
dmb: would that get rid of the radeonhd effort?
aneas: ah, exa support was git'ed 2 weeks ago, right?
aneas: dmb, they wont opensource fglrx :)
dmb: aneas: the article seems to think so
aneas: tcore != fglrx
Obscene_CNN: flgrx probably has code from M$ in it
rx__: fglrx probably has the cure to AIDS in it
aneas: or the cause
dmb: fglrx is also a POS
dmb: i get random artifacts on the screen when using the latest on the bottom right
osiris_: aneas: we have initial exa support in radeon 6.8.0
dmb: it goes away for a little when i change virtualterms
Obscene_CNN: well thats two people from other channels that have look at the news story
aneas: Obscene_CNN, please be more pro-obama, kkthx
dmb: isn't an obama or hillary or McCain fan
dmb: although I think hillary is the most evil, obama is the second most evil, and mccain is the third most evil
Obscene_CNN: Wants Alfred E. Neuman to win
rx__: notices 'No 2D and 3D acceleration so far.' is wrong on the wiki too
aneas: anything improving video playback is "3d accel", right?
rx__: 3d accel comes before video playback
aneas: emmes, you there?
dmb: hi nenolod
dmb: aneas: so is the tcore stuff not actually published yet?
aneas: thats the place to look for it
aneas: but its not there
dmb: aneas: i think its not there
dmb: aneas: probably comes out the 22 :D
dmb: aneas: how did you get to that article?
aneas: it was on a "recent articles" page on phoronix, but i forgot where
dmb: aneas: just found it here also: http://www.radeonhd.org/
aneas: yeah, but i think that was posted later
dmb: are people getting payed to work on radeonhd?
dmb: AMD Releases Tcore, 3D Design Document in Graphics on February 23, 2008
airlied: it leaked.. so the stuff it talks about isn't out yet..
airlied: dmb: the developers mostly work for SuSE..
dmb: so much for ruining the surprise phoronix guys
dmb: well, not really a surprise, but still
aneas: dmb, thats how i found it, altough i think google sent me to that search page
michaellarabel: Err it showing up on RadeonHD.org was a bug and is now removed.
dmb: guesses that michaellarabel runs radeonhd.org :D
gusta1: wow, removing something from the internet....
gusta1: as if that ever worked..
aneas: michaellarabel, by now we all have a backup of it ;)
gusta1: like I tell that 15 yo girl taking a photo of her boobs and giving her msn friend.
gusta1: good luck with that one.
dmb: its been deleted :(
michaellarabel: Well, just keep the information to yourself then please until the not so distant future...
aneas: good luck finding a specific boob-pic on the internet...
gusta1: Could be the next big thing in the backup industry, just sharing it online..
dmb: pats michaellarabel on the back
gusta1: aneas: well, you might not find what you're looking for, but someone else will "happen to" find it ;)
aneas: true :)
gusta1: keep the information to ourselves... so that phoronix can be the first to point it out? oh my... the trying-to-be-nr-1 is on i see
gusta1: well i just hope it won't be too far away until we have some basic 3d in radeonhd due to this...
airlied: like the info isn't much use without the tcore drop..
marcheu: airlied: you know you can take a week off for 3D programming starting next week :)
aneas: will i get rich and famous if i post my local backup? ^^
aneas: i guess not :/
michaellarabel: dmb: I was just taking care of that last bug... It was due to an impromptu feature that was made just a few hours ago.
airlied: marcheu: I knew already ;-)
dmb: michaellarabel: ok
marcheu: airlied: OMG you're in the secretz !! now tell me ze next planz !!!!111
airlied: marcheu: NVIDIA are going to release a fully open source driver, I SWEARZZ..
aneas: i can haz secrtz?!
michaellarabel: gusta1: You can spread the news all you want about it, but what I am saying is that as a courtesy to AMD until the release is made just keep it to yourself.
airlied: marcheu: I've been working on it for months now :)
marcheu: airlied: OMG I can follow the lwn article advice and drop everything nowzzz !!!!1111
rx__: CAN I HAZ 3D IN R300?!!!1112334
marcheu: rx__: just checkout mesa :)
rx__: oh okay
aneas: rx__, the 80s called, they want their card back
airlied: marcheu: OMG I needz to post it to osneews..
dmb: airlied: are you serious about nvidia release an open source driver?
gusta1: i just ran stellarium on radeonhd+mesa. it waz ze shit!
dmb: i thought they were under some nda's and couldn't release anything
aneas: dmb, i think he was fooling aroundz ;)
rx__: dmb, i think you can quote him on that
aneas: so, umm, lets pretend that AMD could possibly release some 3d specs for r500/600 somewhere around 22nd/23rd. which driver will be faster utilising this to a point the stupid normal guy (me) can use it ... radeon or radeonhd?
airlied: aneas: 3D driver is in Mesa, so both drivers can use it.
gusta1: i think he means less mesa, more chair
gusta1: oh, perhaps people don't speak spanish....
agd5f: Just a note to everyone, that article wasn't actually published yet. We are still in final reviews of the code and documents, so I'm not sure what will be ready, by the end of the week
gusta1: basically "it will be ready, when it's ready"... before summer?
agd5f: we just had the 3D doc review call today, so we still have to go over some more edits and feedback
agd5f: It will be soon, but I don't want any one to be too disappointed if we miss the date a bit
aneas: "a bit" is still great
gusta1: according to the last phoronix "news" about "amd open source 3d": "The 3D documentation will consist heavily upon sample code rather than the internal register documentation we have seen thus far."
agd5f: gusta1: for r5xx we are actually going to be releasing a programming guide rather than code
gusta1: this was in september, and the date (before christmas) is completely wrong. so the question is, is the content wrong too? just register mumbo jumbo, or real code?
gusta1: ok, so that was wrong as well, i see..
gusta1: great work, phoronix.
agd5f: we originally looked at releasing code, but the programming guide ended up being a better option
michaellarabel: gusta1: Actually, as is mentioned in this forthcoming article, John's view had changed somewhat due to tcore being too modularized for learning purposes.
dmb: i personally think a programming guide is a better thing then example code
agd5f: tcore is code and will be useful for the drm and memory management
agd5f: part of what's taken so long is we didn't really have a programming guide per se. I've been compiling it over the last couple months
agd5f: osiris_: sorry, I've been too busy to post much lately
agd5f: I do plan to get back to it
osiris_: agd5f: that's what I thought. anyway it's good to know that some good stuff is coming soon :)
dmb: good stuff :D
gusta1: any plans for gallium3d?
agd5f: gusta1: initially we want to get 3D up and runing quickly, so the plan it to build on the r300 driver. once gallium and ttm settle a bit, we'll work on porting over to that
dmb: gallium3d is the support for the new opengl stuff right?
Obscene_CNN: When is AMD going to retire the radeon name? Maybe the could call the next chip series the Plutoneon and nuke the competition :D
agd5f: dmb: yeah, it's TG's new framework for 3D drivers
gusta1: when (if) gallium will be supported correctly by amd, the llvm2shader stuff will be extremely interesting
aneas: airlied, you said earlier the 3d driver is in mesa,
aneas: so mesa will provide a libdri.so using 3d accel
aneas: then what is meant by "3d accel in radeonhd"
airlied: aneas: radeonhd need to setup the card correctly so the 3D driver can run.
airlied: aneas: it needs to talk to the kernel drm and setup the DRI layer.
aneas: that seems like a rather "small" job
airlied: its mostly just porting code from radeon..
airlied: they also need to enable acceleration via the CP which is porting but slightly more work.
airlied: also the 3D engine can be used to do more accel stuff in the DDX driver.
airlied: so textured video, and render accel require the 3D engine
aneas: thx :)
aneas: im just trying to understand how everything works together and which part does what
dmb: is there going to be anything in fglrx that isn't going to be able to be replicated in radeonhd (besides the bugs :P)
michaellarabel: UVD for R6xx
hwdyki: is radeon 9250 supported by the radeonhd driver?
airlied: hwdyki: nope.. radeon driver
Soul_keeper: that was R3xx if i'm not mistaken ...
Soul_keeper: dri has an opensource driver for it
airlied: it was r200 hw.. and the open radeon driver works fine
Soul_keeper: also you can use the proprietary on anything after the 8500 i believe
hwdyki: what driver do i use for for xorg?
airlied: hwdyki: radeon
airlied: or ati
hwdyki: i don't see any radeon sources on xorg
airlied: hwdyki: radeno is part of -ati
hwdyki: is 3d fully supported?
airlied: hwdyki: yes.. Mesa has a driver for it
Soul_keeper: guess they are hosted there now
hwdyki: i already have the r200_dri driver on my system. :)
Temujin_: Soul_keeper: fglrx only works on 9500 or later
Temujin_: unless you go all the way back to 8.28
Soul_keeper: Temujin_, ohhh nice
Soul_keeper: i'm considering picking up a 3870 unless something better is coming out from amd here in the next month or two
hwdyki: did amd release specs?
hwdyki: no specs for their older stuff?
Soul_keeper: i doubt it
airlied: not yet.. they probably will eventually.. but they have to work their way down the list