dli_: rx__, I did, the pointer image still messes up console
dli_: rx__, and still get underlined pointer
dli_: rx__, I guess sw_cursor would solve all pointer problems for now
rx__: well maybe agd5f will get a chance to look at it once he starts at amd
dli_: rx__, I remember fglrx had lots of pointer problem also
Magnade: acceldfs is accelerated download from screen i think
dli_: Magnade, useful? supported yet?
Magnade: i think it was added to help exa speed
Magnade: dont recall what it helps with any more
Magnade: prob can find something via google
airlied: acceldfs only matters for agp cards... for pcie its on by default..
airlied: enablepageflip is pointless..
airlied: fbtexpercent might make EXA better if set high as we don't have 3D yet..
dli_: airlied, how high, for example?
airlied: dli_: not sure .. I don't play with driver options..
sannes: Hm, I'm having some problems getting two screens to work, they both show up in xrandr output, and everything seems fine except that there are no output on the second screen ..
sannes: (newest git)
tilman: which branch? master or atombios-support?
sannes: master
sannes: hm, maybe I should try with the atombios-support branch?
arekm: isn't atombios used only for >= r500 ?
tilman: sannes: my r4xx has the same symptom with master. try atombios-support
tilman: arekm: no, r400 is supported somewhat, too
arekm: still at r300
pharm: Q?
pharm: anyone about?
osiris_: airlied or agdf5: I tried atombios branch on my X1250 (RS690), but no luck
osiris_: the monitor is detected it switches the resolution, but after switching screen goes blank (power saving mode)
osiris_: and I can't back to text-mode. machine doesn't hang but, to get screen back I need to do reboot
osiris_: I checked the logs, and it says that vram size is 64KB (should be 128MB)
osiris_: tried VideoRam option but didn't help
osiris_: I tried hardcoding vram size, but no luck too
osiris_: what should I do to get it working? currently I'm using radeonhd, but no dri here
osiris_: does rs690 contain T&L unit?
glisse: osiris_: i think rs690 doesn't have tl
glisse: just fragprog
osiris_: glisse: those regs I found and you corrected recently, should be enough to make dri working (if 3d unit is the same as on r400), right?
ajax: rs690 should be pretty much r400 3d minus hardware vertex shaders and tnl
glisse: osiris_: likely
osiris_: glisse: good. I added few functions to drm (just like in r500-support branch), compiled modules, after insmoding them, logs say that drm has been initialized correctly, and dri dev is created
osiris_: so I can't wait to make ddx work, to try the dri
glisse: osiris_: any error/warning in xorg log ?
osiris_: glisse: only when I blindly switch to text console to ctrl-alt-del
osiris_: RADEON(0): Timeout trying to update memory controller settings
glisse: that's what you need to hack
osiris_: RADEON(0): You will probably crash now
glisse: memory aren't programmed the same as on radeon
glisse: this what my patch fixed in revenge
osiris_: currently I don't care about VT switching, I'd like to make it display something in graphics mode
glisse: you need to fix it in radeon
agd5f: osiris_: I think I should be getting an rs690 next week, so it will hopefully start working soon
osiris_: glisse: yeap, I found that fb_location and agp_location are wrong, but using new regs, doesn't change anythinhg, screen still goes off after switching res
osiris_: agdf5: great. maybe I can make it work earlier? any suggestion what I should start with?
agd5f: osiris_: dump the regs under fglrx or radeonhd and compare with radeon
osiris_: the right place to set fb_location and agp_location is RADEONInitMemoryMap (1339 line) in radeon_driver, right?
agd5f: osiris_: yes. that's where the values get initialized. they get restored in mode_set()
osiris_: agd5f: but what address mc_fb_location holds? the pci bar address, addres returned from mmap?
agd5f: osiris_: the location of the framebuffer in the card's internal address space
osiris_: aha
osiris_: same for mc_agp_location
osiris_: ?
osiris_: agdf5: what these addresses are used for if they can only be seen by graphic card?
osiris_: agd5f: oops, sorry for mistyping your nick twice
agd5f: mc_agp_location is the address of the gart in the cards internal address space
agd5f: they are used my the memory controller on the card
agd5f: to access FB or AGP memory
agd5f: s/my/by/
agd5f: card side clients (2D, 3D, overlay, etc.) use the MC to access memory
arekm: agd5f: .197 maybe?
agd5f: arekm: time for a release? No time today. maybe later in the week
osiris_: agd5f: so these values (mc_agp_location, mc_fb_location) are generally read-only?
agd5f: no, R/W
agd5f: you can adjust them to change the card's view of where the FB or AGP aperture are
osiris_: oh
osiris_: agd5f: so in what function are these regs set? I only see them beeing read in RADEONInitMemoryMap
agd5f: osiris_: there and/or drm
osiris_: agd5f: so card sets them to some default values during post, and we only read them to use the addresses when sending some commands to card?
agd5f: right. they get set up by the card and then we fix them if needed
agd5f: but they are used internally
agd5f: my the MC
osiris_: agd5f: what is the fb address in cpu address space (biggest pci bar?) ?
glisse: osiris_: in your case fb address should be somethings after agp location or before if there isn't enought space after
glisse: osiris_: or does bios allocate a big enough range already ?
osiris_: glisse: don't know will have to check this but don't know how. so where do I find agp location address (the one seen in cpu address space)?
glisse: lspci tell you this
glisse: then you can see in the driver how this informations are retrieved
osiris_: that's the biggest card's pci bar?
glisse: i don't remember off hand
glisse: yup
glisse: pastebin somewhere the lspci of the card i can take a look to check
osiris_: http://pastebin.ca/803849
glisse: so biggest bar is where you should set framebuffer
glisse: for agp location it should be the same way as for radeon agp card
glisse: once you hacked this try to compare with fglrx
osiris_: glisse: so agp memory is in system RAM and is set by us, when we add pages to gart table?
glisse: agp memory is system ram, but what matter here is where gpu see this memory
glisse: on radeon mc_agp_location set this informations
glisse: to avoid collision with pci address and agp one you would preferably map agp memory to agp "address space" (can remember the proper name)
glisse: if you can't you map agp memory after the framebuffer if there is enough room otherwise before
osiris_: ok, the biggest pci bar is whole VRAM, and fb is located at the begining and its size is x_res x y_res x bytes per pixel, right?
osiris_: glisse: one more question. the gart is used to "enlarge" VRAM and to give direct access to system RAM for graphic card, am I right?
osiris_: oh, and two more: io ports (pci bar) are for legacy vga? what is the last one pci bar (1MB size) for?
rx__: hm.. speaking of drm.. anyone working on r500 drm?
osiris_: agd5f: are you sure that screen turning off is caused by wrong mc_(fb|agp)_location? I would think that if fb location is wrong it should display some garbage, not turn the screen off just after switching resolutions but IANAE
glisse: rx__: r500 doesn't need much change from drm point of view
rx__: that's what i've been reading
rx__: nobody has done it though
glisse: osiris_: gart also enable you to give a linear view of non linear ram page
glisse: which is needed as allocating continuous page is costly and to be avoided
osiris_: glisse: thanks a lot for explaining me those things. I think I understand most of it :) but I certainly need to read some docs explaining details of agp and gart. could you point me to some valuable docs?
glisse: osiris_: really there isn't much more to learn on agp or gart
glisse: lowlevel implementation is mostly irevealent for us
glisse: we are user of it :)
glisse: beside only doc i read are intel agp specification and they aren't that fun to read
osiris_: glisse: ok, will try to make radeon ddx correctly detect mc_fb_location, and mc_agp_location on my rs690
osiris_: glisse: should the mc_fb_location (in ddx) contain whole value read from MC_FB_LOCATION or only lower 16 bits (MC_FB_START)?
glisse: both value are important
glisse: MC_FB_START is start address but you also need to properly set MC_FB_TOP
glisse: if MC_FB_TOP < MC_FB_START then there is no video ram (even fake ram like on rs690)
osiris_: glisse: I dont set this reg, only read it and put it in mc_fb_location variable
glisse: oh then i don't know long time haven't mess with the radeon ddx code
glisse: i am so busy with my kernel code:)
osiris_: ok, will try both
alessandro: any news on laptop support in radeon?
dli_: alessandro, it works for me
alessandro: dli what are you on?
dli_: alessandro, r500
alessandro: sounds good
alessandro: brb, giving it a try again
dli_: alessandro, just checkout atombios-support from xf86-video-ati, and r500-support from mesa/drm
rx__: dli_; were you having all the same issues in radeonhd?
dli_: rx__, no, radeonhd fixed pointer image long ago
rx__: hmm.. if you want to find out what commit fixed it you can run a git bisect
rx__: or you can ask the devs
rx__: are you familiar with git bisect?
dli_: rx__, I guess I can do it
dli_: rx__, I can locate the lid close issue also
sannes: ugh, a small git question, how do I choose a particular branch when pulling? I pulled first time from git://anongit.freedesktop.org/xorg/driver/xf86-video-ati .. so do I just git branch atombios-support and pull again ?
rx__: add --track to branch
dli_: sannes, git-checkout -b origin/atombois-support
rx__: oh.. so glisse is working on r500 drm
alessandro: still no go :(
rx__: hmm.. lockcursor..
sannes: hm, using git-checkout --track -b origin/atombios-support, seems to work, but I get an error trying to pull .. it complains about not knowing where to merge ..
alessandro: my output is all messed up, looks like a modesetting issue
rx__: do git checkout -f master
rx__: git branch
rx__: git branch -d any-atombios-branches-you-see
rx__: then git branch --track atombios-support origin/atombios-support
rx__: then git checkout atombios-support
sannes: ah, thank you! :)
rx__: :)
sannes: Hm, what am I missing when radeon_bios.c:163 won't compile? (radeon_bios.c: In function 'RADEONGetBIOSInfo':, radeon_bios.c:163: error: 'AtomBiosArgRec' undeclared (first use in this function)... )
rx__: hmm..
rx__: you ran ./autogen ?
sannes: heh, hm .. seems that I did not :P let me try that again .. oops
sannes: thanks again :)
rx__: sure
rx__: this branch is expected to be merged into master 'soon'
rx__: so no more git nightmares
sannes: Both my screens works with atombios support atleast :)
alessandro: rx__: as soon as it reaches some stability?
rx__: don't quote me on this.. but yes i would think so
rx__: it's probably best to make sure there are no regressions
alessandro: :-)
alessandro: GREAT i really would appreciate a working driver on my system
alessandro: :-)
rx__: pff i don't know what everyone is complaining about.. fglrx works fine on mine ;)
sannes: rx__: fglrx hardlocks my computer on console switch .. :P
rx__: so don't use the console *grin*
mcgreg: rx__: I would consider using it too againb, if the memory leakage has been fixed
rx__: add more memory
mcgreg: I have 2GB .. that should be more than enough
mcgreg: and nop, thx god damn not a solution
sannes: rx__ : hm, well, you know I actually did that for a week, but hardlocking on shutdown is not very nice either :P
rx__: hahaha
rx__: okay those are pretty bad problems
rx__: i'm not about to recommend pulling the battery/AC to do a shut down
sannes: anyways, all bugs I have asked about in the open source driver has been fixed (or in some cases already fixed), which is very nice :)
rx__: mcgreg; last i read it was memory leak for anything 3d?
mcgreg: rx__: correct
rx__: well.. in that case.. you could use 8.40
mcgreg: no I couldnt , .. I would need downgraded my kernel, X and so on
rx__: what kernel? 2.6.23?
mcgreg: using .24 even ... and 40 works with 22 21 at best
mcgreg: 22 or 21
rx__: there's patches to make 8.40 work with latest X/latest kernel
rx__: is in the wrong channel advocating fglrx
mcgreg: rx__: correrct again. I have been using it for 7 month and now I can just badly pissed off by the quality. thats it. I know, if I really wanted to, I could use 8.40.4
mcgreg: Ican/I can say
mcgreg: and actually , since I have this driver installed and it works fine, except for 3d, which I really don't need at the monent I am rather satisfied
mcgreg: as logn as I can can wathc videos in full screen, it's fully ok
rx__: that's good
mcgreg: and besides that, if I really shoulöd need 3d, I still have another installation (of gentoo) which stuill has some fglrx installed
rx__: another gentoo person :)
rx__: i've got this setup where either xf86-video-avivo or fglrx is loaded depending on what kernel i pick at boot
mcgreg: rx__: noo! I use debian :) gentoo is just a second install , so if I have some problems with something I can use a totally difference system and tests if it#s just my system or the tools making problems
rx__: oh
mcgreg: besides, debian is amd64 and gentoo is x86 :) (really totoally different) ;)
rx__: i just have a little more respect for gentoo users.. they tend to know a little more than the average user
mcgreg: hmm I wouldnt say that about me :) everything distrubution has it's tricks. you just need a lot to know about gentoo, making (make.conf , the use-flags and so on) but onces you understand this stuff, it get much more clear
mcgreg: being a gentoo user can be very very frustrating.. especially if you have to build/compile somehtiung several times because you forgot some dependecy
rx__: depends on your needs i guess
mcgreg: right
rx__: if you want Just Works.. gentoo isn't your bag ;)
mcgreg: I compiled/emerged large parts of it via chroot ... and that caused a lot of problems, since the host was amd64 :) well, some packages didnt build and I had no idea what was wroing first ;)
rx__: multilib?
mcgreg: well, honestly I dont remember anymore. infact the problems started with the kernel. the kernel has been built, but somehow it was 64bit instead of just 32bit (x86) ... I didnt knew that at first, and even that things didnt work inside gentoo well, that really wasnt funny :)
mcgreg: it was just a big mess
rx__: you learn from it
rx__: a lot of users never have to touch compiling the kernel
mcgreg: but after I realised whats wrong, things corrected quickyl and suddenly a lot of problem disappered
mcgreg: rx__: yeah, you learn a lot by stuff like that
mcgreg: solving problem itself it always good for learning - thats what you already learn in school :)
mcgreg: but well, I am faaar from being an expert, even from being a more experienced linux user :) sometimes I still think I am a damn newbie :)
rx__: i can admit to being a newbie
rx__: but i still have the capacity to learn and some "google sense"
mcgreg: well, I recently learned how to use "git" and how to build by own kernel-kbuild :)
mcgreg: even a package for debian
rx__: nice
mcgreg: which is very easy, if you know how ;)
rx__: unfortunately i don't :(
mcgreg: well, in short , if I remember correctly, it was like "apt-get source linux-kbuild-2.6.2*" (ir was 3 in my case) , enter it, with c, debuild -b" .. and I think that was it. a packages will be created in ../
rx__: i see
rx__: thanks
mcgreg: you're welcome
mcgreg: you should have deb-src in your sources.list (in this case it is trunk from debian kernel repo)
mcgreg: deb-src http://kernel-archive.buildserver.net/debian-kernel trunk main
osiris_: bingo! it works :)
osiris_: I've got radeon driver working on rs690 :)
mcgreg: congrats!
osiris_: thanks:)
osiris_: that was another small step in my world domination :P
osiris_: dpi is wrong
osiris_: airlied: does screen blink when running xrandr on atombios-support branch is a known bug? or just new feature? :)
osiris_: *is screen blink when running xrandr on atombios-support branch a known bug?
osiris_: hmm, again git problem.
osiris_: I cloned xf86-video-ati, then checkout atombios-branch, made some changes, and now I want to diff local changes
rx__: commit the local changes then git diff
osiris_: but want to see what changes I made before commiting
tilman: git diff
osiris_: it shows changes against master
rx__: git diff commit-you-want-to-diff-against
rx__: ehh
rx__: clearly none of us are understanding what you want exactly ;)
osiris_: heh, so from the begining:
rx__: nono
rx__: i just reread
rx__: do git branch
rx__: just to check if you're on atombios-support
osiris_: * (no branch)
osiris_: hmm
osiris_: looks like I'm not
osiris_: so how to switch to that branch
tilman: git checkout atombios-support
osiris_: error: pathspec 'atombios-support' did not match any file(s) known to git.
tilman: some minutes ago you said you checked out the atombios-support branch
tilman: did you delete it afterwards? :p
osiris_: it was some time ago, don't remember how I did that
osiris_: hmm, probably git checkout origin/atombios-support
tilman: git branch atombios-support origin/atombios-support
tilman: git checkout atombios-support
osiris_: Previous HEAD position was 00b4480... RADEON: add options for force TV out as detected and to set TV standard
osiris_: fatal: Entry 'man/radeon.man' not uptodate. Cannot merge.
tilman: git diff > my_saved_changes.diff
tilman: git reset --hard
tilman: then do the co again
osiris_: fatal: Untracked working tree file 'src/AtomBios/CD_Operations.c' would be overwritten by merge.
osiris_: maybe it will be easier if I clone the repo again
osiris_: ok, I'm on atombios-support branch
osiris_: thanks! now git diff shows exactly what I want
airlied: osiris_: you will need drm support for rs690 I think.. like the rs480 IGP code.
osiris_: airlied: currently I'm trying to finish rs690 support for ddx, and I have a question:
osiris_: airlied: look at radeon_driver.c in atombios-support branch
osiris_: function RADEONInitMemMap (line 1339)
airlied: osiris_: your codepaths will be differnent for an IGPchip
osiris_: at the begining we use radeon_read_mc_fb_agp_locatio
airlied: I doubt it uses agp location btsw on the igp.
osiris_: airlied: after few additions it works, I'm using it right now
airlied: osiris_: it works in the DDX, the DRM will be more fun :)
osiris_: airlied: yeap, but back to the question: we use radeon_read_mc_fb_agp_location to set mc_fb_location and mc_agp_location
osiris_: and in line 1411 mc_fb_location gets overwritten anyway
osiris_: so whats the point of using radeon_read_mc_fb_agp_location at the begining?
rx__: uh.. what branch is this?
rx__: atombios-support?
airlied: osiris_: in the old dri case wse don't hit that path.
airlied: osiris_: but yes you might have a point, that code is fragile. path..
airlied: osiris_: so its best to not do too much damage to it :)
osiris_: airlied: yes, those lines won't hit with old dri, but in that case mc_fb_location will be also overwritten (line 1384)
alessandro: airlied: any news?
alessandro: :-D
alessandro: or anything coming for laptop?
airlied: alessandro: does it not work on your laptop. it works on everyone elses..
alessandro: nope it doesnt
alessandro: still getting heavy disortion
airlied: alessandro: please send me a log from the latest git head..
alessandro: airlied: alright
alessandro: but you wont see much, because it "works" i can hear GDM starting and can even log in
alessandro: but the picture looks like really badly interlaced or something
airlied: alessandro: wierd.. what chipset?
alessandro: x1400
alessandro: (mobility)
alessandro: could it be related to my xorg.conf somehow?
alessandro: because all i did was replacing fglrx/radeonhd with radeon
airlied: alessandro: wierd the two others we've heard work...
alessandro: really
alessandro: can I debug somehow, for you to figure?
airlied: alessandro: are you starting a serer from scratch?
airlied: server even.. not running two
airlied: alessandro: send me radeon and radeonhd logs.
alessandro: ok i will do so
alessandro: airlied: what do you mean by from scratch?
rx__: what's the issue?
airlied: alessandro: reboot between driver changes..
airlied: gotta run.. office time
alessandro: jup i did
alessandro: see you
osiris_: airlied: any suggestions why running X with drm (initial rs690 on both) almost hangs the machine (screen is garbled, I can move the cursor, but can't switch back to console)
airlied: osiris_: no GARt setup
osiris_: in logs I get these lines:
osiris_: (WW) RADEON(0): DRI init changed memory map, adjusting ...
airlied: does the writeback test succeed? in dmesg?
osiris_: (EE) AIGLX error: Calling driver entry point failed(EE) AIGLX: reverting to software renderin
osiris_: hmm, this writeback test is run during X startup?
osiris_: airlied: I set up gart the same way fglrx does it
airlied: osiris_: yes when the CP initialises..
osiris_: airlied: if it didn't get logged I can't check
airlied: osiris_: oh you can't read dmesg after it crrashes?
osiris_: no
airlied: if you get garbage on the screen, either the CP isn't running or the GART isn't setup correctly..
airlied: osiris_: I think you may need to use some IsIGPs in the DDX.
airlied: in appropriate places..
rx__: why are there differences between rv515 and the rest of r500?
airlied: rx__: different memory controllers.
rx__: do you have docs on rv515?
airlied: rx__: not really..
rx__: :/
airlied: rx__: I knew the regs had changed so I asked AMD to let me use the changed ones.
rx__: so there may be more regs that are different than the ones in the driver already?
airlied: rx__: the mmeory controller is different.. so all the memory controller regs are different..
airlied: I've only used the regs I needed to make it work...
rx__: k
airlied: rx__: if there are any regs you are wondering about let me know and I'll dig them out for release..
rx__: bus_cntl?
airlied: that should be the same..
rx__: cool
airlied: only the indirect MC regs really changed..
rx__: when you say same.. you mean same as r500 right?
airlied: rx__: yes..
rx__: how should r500 regs be named?
airlied: rx__: in radeon I used AVIVO_ for generic, and R500/R600 for specific
rx__: alrighty..
rx__: sends a patch that should.. accomplish nothing
dli_: airlied, I did a bisect, found the fix for lid close&open problem in radeonhd
dli_: airlied, http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-radeonhd;a=commit;h=1103f74dc04e80f47a84367771e6b981d6a902ac
rx__: wow
rx__: have you bisecting all day?
rx__: been bisecting
dli_: rx__, no, for past 25 minutes
dli_: rx__, can you fix the issue for radeon now?
rx__: maybe
rx__: you meant the commit after the one you pasted right?
dli_: rx__, yes, before this commit, it's broken, with this commit, it works
rx__: this commit doesn't appear to touch anything cursor related..
dli_: rx__, let me see whether I can locate the cursor image problem also, since it's something close
rx__: looks through the file
rx__: or lid related for that matter
dli_: rx__, not easy for me to locate the cursor image problem. the cursor image problem was fixed before radeonhd works for me
rx__: ah
rx__: another bug
dli_: rx__, better to talk to egbert for lid issue, since he fixed the problem for radeonhd
rx__: takes a look
rx__: yeah you might've run into another bug before finding the right commit
dli_: rx__, so, there's another bug? how do I know display messed up, but something has changed
rx__: huh?
dli_: rx__, I can only locate where the display is normal, hard for me to get any info when display messed up
airlied: dli_: oh wierd.. I lack major understanding of RES_SHARED_VGA..
airlied: and why that would help..
airlied: you can try changing the RES_SHARED_VGA for your card..
airlied: I can see disabling VGA resources might stop the bios doing aynthing via vga regs to make the card change mode..
dli_: airlied, I don't see where RES_SHARED_VGA is defined
airlied: dli_: its gets used in one of the radeon_*_gen.h files
airlied: radeon_pci_chipset_gen.h
airlied: http://pastebin.ca/804200
airlied: dli_: try something like that ^
rx__: oh.. that RES_SHARED_VGA means something?
airlied: rx__: I'm not sure what it means I just want to see if turning it off helps..
airlied: rx__: it's some arcane crazy shit from 1990s..
rx__: damn ;)
dli_: airlied, with the patch, I couldn't startx now
dli_: airlied, (EE) Screen(s) found, but none have a usable configuration.
airlied: dli_: hmm wierd.
dli_: airlied, yes, verified, disable the patch, I can startx now