Nightwulf|work: hi all
nanonyme: sytse: Just decided to do it the easy way. I recompiled the library without making a package with the right prefix, then manually copied libXdmcp.la in place.
osiris_: egbert: ping
egbert: osiris_: what's up?
osiris_: egbert: you might be interested in this patch http://paste2.org/p/129179
osiris_: egbert: also I found possible null ptr derefs in rhd_i2c but I don't know what's the proper fix
egbert: osiris_: ah, ok. have you checked with rhd_conntest that there isn't another hpd line hooked up?
egbert: osiris_: where do you see the null pointer dereference?
osiris_: egbert: see rhdInitI2C. on first for loop iterations I2CPtr is null, and we use I2CPtr->scrnIndex when printing error messages
egbert: osiris_: ok, will check.
osiris_: egbert: rhd_conntest shows RHD_HPD_NONE
egbert: ok :) will apply your patch, thanks!
osiris_: egbert: I'm also fighting with two radeon cards. one is rs690 (onboard) and second is rv620. I'm not able to get rs690 working when both are enabled
osiris_: because there's no BIOS in PCI resource
egbert: osiris_: yeah, this is a problem with the onboard cards.
osiris_: even when rs690 is set as primary vga
Nightwulf|work: hm....very strange...whenever i enable DRI with the r7xx-r6xx-support branch, i get a black screen after X starts up on my RV635 and R680 but log says "[DRI] Installation complete"
egbert: oh? you don't see the BIOS ROM of the added card in the PCI config space?
osiris_: egbert: is there a way to bypass this? IIRC it works ok on WindowsXP
egbert: osiris_: can you do an lspci -v and post it somewhere?
airlied: osiris_: can you see them in sysfs?
osiris_: airlied: yes, both cards are visible
egbert: osiris_: the cards may be, but what about the PCI ROM of the secondary?
airlied: osiris_: no the ROMs
osiris_: the ROM is disabled on rv620 but visible. no ROM on rs690
osiris_: lspci -v output: http://paste2.org/p/129181
egbert: osiris_: ok, is this with rs690 primary?
osiris_: no, rv620 is primary now
airlied: osiris_: so no rom file in /sys when rs690 is primary?
osiris_: airlied: no, neither when it's secondary
osiris_: when rs690 is primary, I'm able to run X on rv620, the screen is on, but it's all black
egbert: ah, ok, that's another problem then.
nanonyme: Maybe that sytse's patch would help there too?
nanonyme: There was a black screen problem on r670, his patch was said to fix it. Haven't gotten to try yet with all this X.org recompiling mess.
osiris_: rs690 works if I pull out rv620
nanonyme: rv670 even.
airlied: if rs690 is primary you get no rom file? it only appears if rs690 is on its own?
osiris_: airlied: yes
airlied: osiris_: damn that sounds like a kernel bug then
Nightwulf|work: wonders wether he should provide further information
egbert: airlied: the rom of an igp doesn't necessarily have to show in pci config space.
osiris_: don't know if it is relevant but if rs690 is primary both cards are shown as "VGA compatible controller", when rv620 is primary rs690 is "Display controller" and rv620 is "VGA compatible controller"
osiris_: in lspci
egbert: osiris_: you need to check /sys/bus/pci/..../rom
osiris_: when rs690 is primary I'm able to enter X only with vesa driver
egbert: for /sys/bus/pci/device/
osiris_: egbert: as I said before, there is no rom file for rs690 if external card is plugged in
osiris_: doesn't matter if rs690 is primary or secondary - no rom file. it exists only if rs690 is on its own
airlied: thats definitely a kernel bug, can you pastebin a dmesg?
osiris_: airlied: dmesg output http://paste2.org/p/129187
dvandyk: airlied: (late) congratulations!
airlied: osiris_: thats from the rs690 as secondary?
airlied: osiris_: can you get one from rs690 as primary?
airlied: I suspect I know where the bug is, you might need to kick me tomorrow though, baby + bed time
osiris_: airlied: yeah, rs690 is secondary now.
osiris_: airlied: should I get only dmesg output when rs690 is primary? or lspci too?
airlied: osiris_: both, can you log a bug on bugzilla.kernel.org? pci subsys I tihnk, cc firstname.lastname@example.org
egbert: osiris_: your patch and the NULL pointer reference fix are pushed.
egbert: osiris_: thx!
osiris_: egbert: np :)
osiris_: airlied: sure
osiris_: egbert: what about the problem of black screen on rv620 when it's secondary. where should I start to debug this?
dvandyk: fyi, i have had a similar problem with a r5xx card and Intel integrated graphics
dvandyk: when the pcie card was not the primary device, it wasn't visible via lspci and obviously there was no output
dvandyk: don't know if that is related
osiris_: dvandyk: hmm, what about the case where r500 is primary? is intel card visible then?
dvandyk: no, it isn't
dvandyk: 01:00.0 VGA compatible controller: ATI Technologies Inc RV505 CE [Radeon X1550 64-bit]
dvandyk: but nothing in regard to the intel thing, which is G35 i think
osiris_: dvandyk: then I would say that it's a BIOS limitation. it doesn't allow two display controllers to exists in the same time so it completely disables the bus that the secondary card is on
osiris_: airlied,egbert: little update for the no rom case.
osiris_: I was wrong: there is a rom file when rs690 is primary, but its size is 0
osiris_: airlied: should I still file this bug
osiris_: one more thing I forgot. to make rs690 visible when it's secondary, I have to enable SurroundView option in BIOS
Soul_keeper: http://www.petitiononline.com/ut3linux/petition.html nice
Nightwulf|work: signed :)
Nightwulf|work: here's a Xorg.0.log and the insert messages of drm and radeon modules belonging to my report -> http://pastebin.com/m1b4d5871
Nightwulf|work: would be nice if anybody could tell me wether this seems to be a configuration issue or a bug I should report on bugzilla or ML
Nightwulf|work: behaviour is identical with my R680 @ home
bridgman: osiris_; surroundview is the only option where I would expect both roms to appear; surroundview is marketing-speak for "both cards work" ;)
Nightwulf|work: hi bridgman
osiris_: bridgman: yeah, but only rom for external card appears
libv: osiris_: of course.
libv: osiris_: this is how bioses work.
libv: osiris_: the chipset bios image extracts itself into the parts of the real mode memory it uses, for the igp graphics bios, this will then be the C segment
libv: then the bios will go over the pci devices, and run their respective bioses, for the primary vga card, it copies the pci rom to the C segment, overwriting the IGP one
libv: osiris_: use coreboots flashrom, to see whether it is capable of reading your bios flash and dump it
osiris_: libv: I'm not talking about the video BIOS info that shows up during PC startup, but the availability of rom file in /sys/bus/pci/devices/xxx/rom file
libv: then use awardeco or amideco to extract the lha archives in them
libv: osiris_: the IGP device does not come with separate flash.
libv: osiris_: poke the pci device directly, and you will see that its ROM bar is empty
libv: osiris_: as said before, it is part of the motherboards main bios image.
libv: osiris_: if anything overwrites the C segment, then the IGPs bios disappears
libv: and anything here is any VGA type device that is set to primary
osiris_: libv: hmm, but why is rs690 rom unavailable when rs690 is the primary vga card?
libv: ok, then i misread what you were stating
libv: it should be available
libv: osiris_: then it is probably a kernel bug, which tbh, doesn't surprise me, not sure whether image sizing has been fixed already
osiris_: libv: don't know if I understand what you said. the rom for rs690 should be available when it's primary, but not when it's secondary, right?
libv: osiris_: correct
libv: osiris_: nothing should overwrite the vga rom in the C and D segments in that case
libv: any other pci device will have its rom put behind the vga rom
osiris_: libv: ok, will file a bug report then
libv: actually, we should provide some information on how to extract BIOS images, and should allow our driver to load bios images specified in xorg.conf
osiris_: libv: there's another problem. when rs690 is primary, and I try to get X running on secondary (rv620) the screen is up, but it's all black
libv: it also shouldn't be too hard to hack the atombios part of bioses, somebody just needs to take the time to write up the tool for it
libv: osiris_: this is probably a different issue, and then you should file a bug against our driver together with a verbose log
osiris_: libv: I can try to debug it by myself, just need a clue where to start. Xorg.0.log shows no errors
libv: osiris_: could be many things
Nightwulf|work: libv: i don't want to be annoying but i wonder nobody answers on my report...something missing with it? well known issue i simply didn't know it is?
libv: Nightwulf|work: i personally am quite tied up with suse xorg bugs atm
Nightwulf|work: libv: hmm...i understand that...but if nobody reports them, they won't get fixed :)
libv: but i believe egbert is working on fd.o bugs as well atm
Nightwulf|work: hmm...posted this one already when he was on
libv: Nightwulf|work: they won't get forgotten, we just need to get our bugload on the suse bugzilla down first
Nightwulf|work: libv: ok, but perhaps you could answer one question to me...
libv: maybe, i'm installing an 11.1 on an agp system atm to verify some radeon bug right now
Nightwulf|work: libv: i wonder why the r7xx-r6xx-support branch of the drm module reports a 2006 date in dmesg when inserted...is that correct or did something went wrong with my branch switching?
libv: Nightwulf|work: nobody has bothered to bump anything in drm.ko for aeons
libv: so it is "correct", in that it is how things are
Nightwulf|work: libv: might be...but the master branch reports the same date and there are definatly differences between the two branches...so somebody simply forgot to change the insert messag?
libv: Nightwulf|work: it's some defines
libv: but yeah, noone bothered.
libv: no-one bothers with trying to track api changes anymore these days
Nightwulf|work: k...simply wanted to exclude a build or branch error caused by myself which then causes the issues with my cards simply because versions don't fit
libv: we went from very hard abi stability under xfree86, to having little to nothing api trackability anymore under xorg
Nightwulf|work: that sucks
libv: yeah, all users suffer
Nightwulf|work: k...guess it would be best I post that issue in the bugtracker too so it doesn't get lost
libv: Nightwulf|work: yeah
Nightwulf|work: libv: thx for not letting me die by dumbness :)
osiris_: airlied: bug report filed http://bugzilla.kernel.org/show_bug.cgi?id=12442
osiris_: libv: any tip about the problem? I'm really willing to play with it to learn something, just don't know where to start.
libv: first step would be to read the verbose log
libv: and then go and compare it to a verbose log of the card being primary
libv: then register dumps of both situations to spot any differences
libv: but rv620 is already dce 3.0 so there is part of that code already fully dependant on atombios
libv: so dumping might not be very succesful
osiris_: ok, will check the verbose log first
agd5f: osiris_: even though the sysfs rom resource is size 0 for IGP chips, I think it generally still works. try echo 1 > rom; cat rom > /tmp/vbois.rom; echo 0 > rom;
libv: this sysfs rom retrieval scheme is broken.
kdekorte: Did a little testing with radeonhd git (r6xx-r7xx-support branch) and still am getting a little font corruption, although it is less
kdekorte: and XV will only work correctly when the metacity composite manager is off, but when the manager is off the ui is much slower
kdekorte: otherwise, it is looking ok
kdekorte: I'm using a 3650 (r635) with dual head (1680x1050 + 1280x1024) on Fedora 10
Nightwulf|work: at least your 3650 works with r7xx-r6xx-support branch o.O
Nightwulf|work: do you have DRI enabled in config or not?
adamk: If he has Xv working at all, then he has DRI enabled.
Nightwulf|work: then i wonder what difference is between his 3650 and mine....since my machine @work and the one @home use same mainboard/cpu combination and on both DRI doesn't work, i guess it could be an issue witch only occurs on that specific combo
agd5f: Nightwulf|work: AGP doesn't work yet if you happen to have an AGP system
Nightwulf|work: it's a phenom x4 system on an asus MVP32A-Deluxe mainboard (790fx chipset)
Ge0rG: hm. why do I never ever meet bridgman online?
nanonyme: Are you living in the same time zone?
nanonyme: I mean, if he's several timezones off from you, it might explain it.
nanonyme: sytse: Hey, thanks. :) I was just about to try to apply the patch again manually just to notice it was already in git. :D
sytse: ooh, nice :)
sytse: 10 minutes ago
nanonyme: I'm also studying jhbuild to help me building X.org with less effort.
dvandyk: if anybody is interested in r6xx/r7xx gpgpu stuff: http://github.com/dvandyk/gpu-toolchain/tree/master
dvandyk: it's currently able to correctly parse a minimal kernel as described by the r6xx ISA, and it's able to generate the CF and ALU instructions, as well as most of the needed relocations
sytse: well, almost all of it, everything except for the drm_core_ioremap* changes, which alex wants dave's opinion on
sytse: nanonyme: heh.. switch to gentoo ;-)
sytse: dvandyk: oooh... cool
sytse: very cool
sytse: if I had time, I'd check it out
dvandyk: it still has some bugs, mostly regarding loop CF instructions
dvandyk: and i haven't yet had a chance to assemble the minimal kernel by using pen and paper, so there is no real testing yet
sytse: (I'm going abroad for 6 weeks starting next saturday, and I'm not taking a laptop, so I'd best put off things like this until after that)
nanonyme: sytse: I might make a Gentoo 32bit chroot if this doesn't still trivially work.
nanonyme: I like having the main system stable, I tinker inside chroots.
nanonyme: (Besides, Debian will probably get decent support for my card in the next few years anyway)
kdekorte: Nightwulf|work, I also installed the kernel modules from libdrm (r6xx-r7xx-support branch), but I did not install the libdrm code, just the module
kdekorte: Also, I am on a Intel G35 chipset, with a Q6600 cpu (Asus P5E-VM motherboard)
osiris_: libv: I give up. here's the log for rv620 as primary: http://paste2.org/p/129276
osiris_: libv: here rv620 as secondary: http://paste2.org/p/129278
osiris_: libv: where did you get reg description for rv620?
libv: osiris_: bridgman has not made this public yet.
libv: osiris_: please attachs those logs to a bugreport
libv: wtf is all that CAIL stuff doing in the log
osiris_: libv: first, I need to report one :) where should I file it? bugs.fd.o?
libv: osiris_: yup
TuomasT: fglrx related, but might as well ask here..: Both in Linux and Windows drivers Pixel buffer objects no longer work with non power of two textures since couple of months and additionally in Linux drivers PBO itself has not worked for couple of drivers revisions. Whom to bug?
osiris_: libv: CAIL stuff comes from posting secondary card
libv: ok, is quite noisy though :)
libv: TuomasT: #ati iirc
TuomasT: Will RadeonHD OpenGL support PBO?
nanonyme: Hrm, wasn't it one of those things that required Gallium3D?
TuomasT: Its related to faster data upload to GPU
TuomasT: in OpenGL texture upload
nanonyme: Yeah and is also afaik superceded by FBO. :)
agd5f: TuomasT: eventually. needs memory management.
TuomasT: nanonyme: Maybe that is why I'm having trouble with its support
TuomasT: No, actually FBO seems to be a different thing
TuomasT: Only shining light with ATI's OpenGL support is this driver and even its years away :(
lupine_85: I wouldn't say *years*
TuomasT: Time will tell
agd5f: TuomasT: the memory manager work is already in progress. main thing now it to get userspace (mesa in this case) fixed to properly use it.
osiris_: libv: https://bugs.freedesktop.org/show_bug.cgi?id=19535
nanonyme: agd5f: Does fixed in this case mean Gallium3D or some temporary userspace solution, btw?
agd5f: nanonyme: either way.
nanonyme: I rather wondered if developers are interested in making the temporary solution. :) Doesn't sound very encouraging to me to make something you know will get scrapped.
lupine_85: nanonyme: the life of a software developer is short and cruel
lupine_85: or long and very, very cruel
agd5f: nanonyme: the existing mesa code can pretty easily be moved over to using a memory manager. in fact both glisse and airlied have tress in various stages or working
nanonyme: Ah, right.
nanonyme: Right, I just fed up with this. Gentoo system for r6xx testing it is.
osiris_: agd5f: you're right. I can read the bios after echoing 1. don't know why the bioses are different (the one with only rs690 card, the second with rs690 as primary and rv620 as secondary)
agd5f: osiris_: different cards, different bioses
osiris_: agd5f: no, I was dumping bioses from the same card
osiris_: only in first case rs690 was the only card in system. in the second case I've put rv620 in
rehabdoll: wee, got dri working \o/
rehabdoll: fonts are messed up with exa though :>
agd5f: osiris_: are you saying you get a different bios image from sysfs depending on which cards are in?
osiris_: agd5f: yes. I'm getting bios from rs690 in both cases.
agd5f: osiris_: from sys or when you run the driver?
osiris_: agd5f: from sysfs in both cases
agd5f: so the sysfs rom file for the rv620 returns the rs960 rom?
osiris_: agd5f: no :)
osiris_: agd5f: I was trying to get bios from rs690 in both cases. first case: only one card - rs690 (onboard). second case: rs690 (primary), rv620(secondary)
osiris_: agd5f: in both cases the bios size is 54784 bytes, but they're different
agd5f: osiris_: yeah, one is posted, one isn't probably
agd5f: osiris_: er...
osiris_: agd5f: both should be posted because in both cases rs690 was set as primary
rehabdoll: hum, xvideo doesnt run
kdekorte: rehabdoll, do you have a composite manager running?
rehabdoll: xvinfo reports "no adaptors present"
agd5f: rehabdoll: then you don't have dri enabled
rehabdoll: (WW) RADEONHD(0): Direct rendering for R600 and up forced on - This is NOT officially supported yet and may cause instability or lockups
agd5f: rehabdoll: you need to use the r6xx-r7xx-support branch of radeonhd
kdekorte: rehabdoll, you need to have Option DRI and Option AccelMethod EXA in your xorg.conf file
rehabdoll: i am, i have :)
rehabdoll: ah, sorry
kdekorte: agd5f, I see the git branch in the log, but I also see AccelMethod none in the log...
rehabdoll: didnt have exa enabled
rehabdoll: thanks :>
osiris_: agd5f: so it is normal situation that I get two different bios images for the same card?
Enverex: I saw the message about being able to have 3D OR 2D accel, not able to have both, is that likely to be fixed anytime soon?
agd5f: osiris_: no unless there is some flag set for multiple cards or something
libv: osiris_: use strings or atomdis to find out whether these images are for the same card
nanonyme: Hmm, Xvideo working perfectly and without lag on rendering with RV670.
nanonyme: (Ah, spoke too soon. Scrolling is a bit laggy :)
kdekorte: nanonyme, any font corruption?
nanonyme: Not that I see.
kdekorte: hum, I had a little on my r635 with todays git
nanonyme: Where should it be visible, subtitles only or browser font too?
Ge0rG: oh, more changes in the git? that sounds great. :>
kdekorte: Anywhere on the desktop... I saw it in some terminals
kdekorte: mainly on the current line of the terminal where the cursor was (non-flashing cursor in gnome-terminal)
nanonyme: Don't make a party yet, I think I might have done a misinterpretation.
nanonyme: It didn't throw any errors when I set AccelMethod exa and vlc rendered with Xvideo so I thought it was fine.
nanonyme: However, (WW) RADEONHD(0): RV670: HW 2D acceleration is not implemented yet. -> (**) RADEONHD(0): Selected ShadowFB.
nanonyme: Good to be suspicious, apparently.
kdekorte: yup, looks like your still in ShadowFB
nanonyme: Yeah, it explains the lack of corruption and/or font problems. I was expecting those.
nanonyme: The problem was highly likely between the computer and the chair.
nanonyme: Yeah, finally got my very own font problems. :)
kdekorte: nanonyme, XV still work?
nanonyme: Seems to work fine, yes.
nanonyme: Maybe I'll try next if the EXANoComposite removes font problems for me.
osiris_: libv: yes, these images are for the same card
nanonyme: Heh, still rendering problems, however, the fonts are now readable.
osiris_: looks like there're only two differences
kdekorte: nanonyme, how is the speed of it? Guessing still slow
nanonyme: Not fast but it no longer lags while scrolling web pages.
nanonyme: (That is, like it did a few moments ago with shadowfb. Without DRI was slightly faster though)
nanonyme: I think the biggest issue (on my system) is fonts, not speed.
nanonyme: Though apparently on window switching fonts are quite slow to render. (That is, if the new window's text section was covered by the old window)
nanonyme: But yeah. It starts. Thanks again, sytse. :)
kdekorte: Is the xserver 1.6 font/pixmap cache stuff required for decent performance or is that something else?
agd5f: kdekorte: that improves font performance, but in this case, the driver is completely un-optimized. I'm trying to get it working before I optimize
nanonyme: Sounds good.
kdekorte: agd5f, guess I was jumping the gun then... :) make it work, then make it fast right...
agd5f: kdekorte: yup
sytse: nanonyme: :)
sytse: in 7 weeks I'll be back in the netherlands, maybe I'll help a little bit :)
sytse: maybe help porting the fb driver, I don't know
sytse: s/porting/adding modern gfx card support/, obviously
nanonyme: Well, at least I finally got my r6xx testing system up, in the end with surprisingly little effort. :)
nanonyme: Mental note: never use 1.4 again, it seems to break virtual terminals *hard*.
nanonyme: Erm, xorg server 1.4 even.
yangman: yup, 16-bit color is definitely all wrong
nanonyme: xrandr can't change between colour depths, can it?
nanonyme: Just wondering.
yangman: it's not part of the spec afaik
yangman: not sure if it's something the server can do on-the-fly
nanonyme: Imo might be a useful feature. Just remembered Windows has been changing colour depth on the fly as long as I remember so I wondered if xrandr could do the same.
yangman: I'm pretty sure it can, but it's not part of the randr spec
yangman: it's a matter of having a tool to do it