mmp: osiris__: hello :)
mmp: (or in other words, the RS600 nightmare is back :)
diogo: so I can't install the mesa 7.1 on any distro to get it working to see if it has any better stuff on the ati xpress 1150!
diogo: I just saw arch linux update it on the testing repo
diogo: I'll test it
diogo: hey using debian with mesa 7.1 and xorg 1.5rc6 from experimental... the radeon driver is working (i mean no black screen) but when trying to do anything with dri like blender it doesn`t start
diogo: diogo@diogo-laptop:~$ blender
diogo: Compiled with Python version 2.5.2.
diogo: Checking for installed Python... got it!
diogo: intern/ghost/intern/GHOST_WindowX11.cpp:175: X11 glxChooseVisual() failed for OpenGL, verify working openGL system!
diogo: X Error of failed request: BadWindow (invalid Window parameter)
diogo: Major opcode of failed request: 18 (X_ChangeProperty)
diogo: Resource id in failed request: 0x40ec5ff9
diogo: Serial number of failed request: 26
diogo: Current serial number in output stream: 27
diogo: sorry for posting here pastebin is no working at all
MostAwesomeDude: diogo: http://pastebin.com/
MostAwesomeDude: http://pastebin.ca/
MostAwesomeDude: Works fine for me.
diogo: :( its down here
diogo: ok sorry about the pasting in here.... but what should I do?
diogo: pastebin.com works
diogo: !!
diogo: http://pastebin.com/m5bcb8969
diogo: here is the pastebin
loswillios: ah nice, google earth works again with mesa-7.1 and xorg 1.5rc6
MostAwesomeDude: diogo: Does direct rendering work?
loswillios: well, works as in does not crash (it obviously uses software rendering :/)
diogo: cant see apparently glxinf and glxgears are not working
diogo: they don`t exist on my system
diogo: but DRI started no problem on Xorg.0.log
MostAwesomeDude: loswillios: I meant glxinfo or such.
MostAwesomeDude: diogo: What system are you on? No mesa-progs or mesa-utils packages?
diogo: im on debian testing with the xorg from experimental
diogo: 64 bit
loswillios: MostAwesomeDude: yup that works OpenGL version string: 1.3 Mesa 7.1
loswillios: glxgears works too
diogo: found mesa utils
diogo: I`ll install it
loswillios: but googleearth won't, not even with the disable_lowimpact_fallback workaround :/ guess it's related to my rs480 or something
diogo: yes it is working
diogo: glxinfo said OpenGL version Strin? 1.3 Mesa 7.1
diogo: direct rendering? Yes
diogo: my keyboard is wrong on xorg.conf
diogo: when I said ? I meant :
diogo: but to prove something goes wrong
diogo: the glxgears doesn`t work
diogo: Error: couldn't get an RGB, Double-buffered visual
MostAwesomeDude: diogo: Check DRM.
diogo: ok
diogo: dont see any problems either on drm
diogo: 0
diogo: http://pastebin.com/m5babd3e0
diogo: what can it be?
MostAwesomeDude: Well, if you built your own mesa, you might need to rebuild and reinstall it.
diogo: the case is that I didn't may I build by my self and install it over will crash the apt but whatever I'll try it
MostAwesomeDude: Well, no, just try a reinstall.
loswillios: x-moto runs fine too
diogo: ok
diogo: already did reinstall it and didn`t work
diogo: maybe a apt-build
loswillios: install arch linux :p
diogo: yeah I thought so... I love arch
diogo: but I saw that the xorg 1.5rc6 only for i686
loswillios: yeah
diogo: and my laptop doesn`t work well with 32 bit only 64 bit
diogo: loswillios what is your card?
loswillios: wow. I always here things the other way round
loswillios: diogo: RS480 - XPress200M
diogo: hehe... my dell vostro 1000 if on 32 bit the kernel 2.6.26 doesn`t work but if on 64 it works.... if on 32 bit the led trigger doesn`t turn off if on 64 it does turn off and works perfectly
diogo: also the suspension on 32 bit the bios hangs on first reboot on 64 it doesn`t
diogo: mine is Xpress 1150 - RS485
diogo: maybe I'll try
diogo: but can`t update the kernel :( I may try latter to see if thw kenrel 2.6.27 rc works
diogo: I`ll try arch
diogo: back latter
bitnick: How do I specify (in xorg.conf or otherwise) which monitor sits on which output? I have a VGA->Scart cable on my VGA connector, but right now X always try to use my DVI/TFT resolution for the VGA output, even if my "VGA TV Screen" is the only enabled screen.
hifi: vga can be converted to scart? :o
hifi: or does it need a special graphics adapter
bitnick: To rgb scart, yes.
bitnick: Well, you need a DUB-15 to Scart cable of course, but no signal conversion.
bitnick: DSUB
bitnick: Details here: http://www.idiots.org.uk/vga_rgb_scart/
hifi: does every tv with scart support that?
bitnick: No, you need an RGB capable scart
hifi: thought so :)
bitnick: ... but many are
bitnick: A related question: does anyone know how to add an interlaced mode with xrandr? It chokes on the "interlaced" modeline keyword...
hifi: thanks for the link, might build that cable some dayt
hifi: my current s-video to scart adapter gives pretty bad quality output
diogo: hey the mesa did work on arch linux 32 bit
diogo: :D
diogo: but still GL Render bugs on blender :(
diogo: I'll test the new kernel if not I'll install the 64 and try to build the mesa 7.1 on the 64 bit
loswillios: diogo: yeah, I'm on .27-rc5 too
diogo: well where did you found the .27-rc5 for 32 arch
diogo: haven't test it
diogo: maybe it works
diogo: ?
diogo: loswillios: if it was build from source did you used the abs PKGBUILD?
loswillios: oh right, I'm always tracking git kernel
loswillios: no PKGBUILD stuff and such - doesn't matter to me much for kernels
diogo: loswillios: sorry network fall down
diogo: how did you got the .27-rc5?
loswillios: 19:19 < loswillios > oh right, I'm always tracking git kernel
loswillios: 19:19 < loswillios > no PKGBUILD stuff and such - doesn't matter to me much for kernels
diogo: so you created the kernel by hand?
diogo: no packages no nothing
loswillios: no
diogo: ?
loswillios: errr, yes
diogo: ok
diogo: yes no???
diogo: ok
loswillios: by hand
diogo: so I'll test the archs one.. if not I'll get the 64
diogo: thx anyway
bitnick: How do I specify (in xorg.conf or otherwise) which monitor sits on which output? I have a VGA->Scart cable on my VGA connector, but right now X always try to use my DVI/TFT resolution for the VGA output, even if my "VGA TV Screen" is the only enabled screen.
bitnick: Prehaps it's driver independent? I'll ask om xorg instead...
tormod: bitnick: see http://xorg.freedesktop.org/wiki/Projects/XRandR
robbat2: need a hand with an issue on my new 3650XT - if I boot my machine with DVI-0 connected (as single head, or as part of a zaphod config), it just hangs, and the last message in the Xorg.log is: RADEON(0): EDID vendor "SAM", prod id 637
robbat2: there are two further up instances of "RADEON(0): EDID vendor "SAM", prod id 637" in the same log
robbat2: "in RADEONProbeOutputModes" is the second-to-last line
robbat2: happens on both 6.9.0 and git head as of last night
bitnick: tormod: thanks, the thinkwiki link has some useful info. I'll try it.
bitnick: You would think the radeon man page would include info about the names of the outputs...
oga: hmmm. someone ran a static analyser on our kernel and it flagged up a few drm bits.
oga: there's a bunch of instances in radeon_cp.c where we read the value in a register then we write out to it without including what we read.
oga: is that correct? in which case, why the read?
libv: oga: "historic reasons", i'm sure :)
oga: well, either the old version needs to be ORed into the register write, it doesn't need reading, or there's a very specific reason why it needs reading before writing.
oga: I'd like to confirm which
libv: oga: well, i'm sure no-one knows anymore
oga: well, it's in RS480 and RS690 code, so it should be fairly recently
libv: oh, in that case, ask agd5f
oga: agd5f: here?
rx__: bets having to read before write
oga: It's definitely possible, worth checking
libv: rx__: i'm not sure, if it is rs480/rs690 specific then it sounds like MC registers
spstarr: hullo libv
libv: rx__: on modern hardware, it should be resilient enough to not need something like this, i could be wrong of course
libv: spstarr: hi
rx__: modern yes :)
libv: actually, iirc, some of the pll indexed registers required some extra poking in even older hardware; r200 if i am not mistaking but these are neurons which were last used last summer i think
libv: so i might be pretty far off
rx__: what are you working on now libv?
libv: it was when we were still being told that non of the avivo hardware used indexed registers anymore
libv: when i clearly saw other things from the actual x86 bios :)
libv: rx__: preparing for XDS atm
libv: printing out maps, stuffing one of the test laptops with current code
rx__: will you be talking?
libv: no, i have little of interest to talk about atm
rx__: ah
libv: just boring stuff
robbat2: per my problem earlier, inside RADEONProbeOutputModes, if I comment out the first xf86OutputGetEDIDModes I can bring up zaphod mode fine, however there is some weirdness when i'm exiting X (refreshs to last display of DVI-1 contents on both sides)
airlied: oga: which bits are flagged?
airlied: ah I see one we read the MC_MISC_CNTL then write it.
airlied: same with GART_FEATURE_ID
airlied: good chance we were just copying fglrx.
oga: airlied: there were three, those were two of them.
oga: MISC_CNTL, FEATURE_ID,, RS480_AGP_MODE_CNTL, RS480_AGP_ADDRESS_SPACE_SIZE are the whole list.
oga: pretty much all the reads in radeon_set_igpgart.
osiris__: oga: the MC setup process for RS690 have been REd and I actually didn't checked if these reads before writes are necessary, just copied what fglrx does
osiris__: it would be the best to get some feedback from AMD about how MC setup should look like
rx__: wonders if there is some errata involved :)
oga: osiris__: thanks.
oga: all I needed to know
indes: .. anyone know anything about loading drm.ko under 2.6.26 with the init_mm symble not being in the kernel anymore... ?
osiris__: np
indes: workaround?
indes: hm.
osiris__: indes: just add EXPORT_SYMBOL for the init_mm function
indes: .. I suppose thats the easy way out ;-)
indes: osiris__: should I replace the EXPORT_UNUSED_SYMBOL ..?
indes: or leave them both
airlied: indes: you just need to rebuild with export unsued symbnols
indes: EXPORT_UNUSED_SYMBOL(init_mm); is there..
indes: (arch/x86/kernel/init_task.c)
indes: I put EXPORT_SYMBOL(init_mm); below it .. ;-)
airlied: don't bother
airlied: just change the config option to export unused symbols
indes: couldn't find it in the menuconfig
airlied: its in kernel hacking
airlied: enable unused/obsolete exported symbols
indes: nice, ty.
indes: builds revision 3
indes: ty, hopefully this'll go.
spstarr: looks at koji for any new kernel
spstarr: nothing yet )
spstarr: :)
airlied: bryce: for quriking you'd mostly have to quirk on AGP host bridge rather than on the card.
airlied: .but then in some cases it would be on both host bridge and card.
airlied: we already have one quirk in there I think.
bryce: airlied: ah cool - if you give me a pointer, I can take a shot at working up a patch to add a quirk for this one too
airlied: bryce: RADEONSetAgpMode in radeon_dri.c has a quirk in it.
bryce: thanks
airlied: mainly for fastwrites.
bryce: ok, I'll take a look
terracon: I quirk thee!
airlied: woot suspend/resume without crashing on modesetting..
airlied: corrupted crap.. but not crsahed
rbrett: airled: Have you guys figured out what your going to do with suspend/resume an encrypted disks?
airlied: rbrett: I think the only answer it to not allow suspend/resume with an encrypted root.
airlied: but I'd say we'll just leave it up to the user.
rbrett: airlied: I see, thanks
spstarr: blinking squares
bryce: airlied: ok let me run this by you to make sure my understanding is correct... this particular bug is an AGP incompatibility between the Mobiligy M6 LY and the intel 82830 830 Chipset Host Bridge, so for this I'd add a (vendor == PCI_VENDOR_INTEL) && (device == PCI_CHIP_M6_LY) there in RADEONSEtAgpMode maybe right after the AGP mode stuff but before it gets into the fast right stuff?
bryce: and at that point set mode |= RADEON_AGP_2X_MODE for this chip/hostbridge combo?
airlied: bryce: sounds about right yes.
bryce: ok cool, I'll work up a patch then. thanks.
airlied: some sort of function that returns a defaulty AGP mode for a chipset/gpu combo.
airlied: then let the user overwrite it.
airlied: its very messy though..
airlied: lots of things affect.. I'm sure I could find people with bad power supplies who get AGP lockups different.
bryce: yeah I know this agp mode stuff sucks... at least in this case it's a laptop so hopefully we can assume most people with this combo will be having the same problem
airlied: bryce: the BIOS also sets defaults.
airlied: maybe Alex can turn up something from fglrx people.
bryce: airlied: ah do you mean RADEONApplyLegacyQuirks()?
airlied: bryce: nope that just does bios connector quiriks.
airlied: more that the BIOS has options on a lot f laptops to set the AGP modes.
airlied: and changing those can affect the driver later.
airlied: so its not always chipset/gpu combo alone
bryce: ahh
bryce: troubling
bryce: maybe there's a way to probe for that though?
airlied: well we can find out what the current mode is I think.
airlied: we tried the believe the BIOS trick for a long time but that failed badly.
bryce: airlied: here we are - https://bugs.freedesktop.org/attachment.cgi?id=18623
spstarr: tries composite effects with kde trunk
spstarr: hmm
cxo: goes to get more beer
spstarr: hmm
spstarr: kwin(5627) KWin::Workspace::allowClientActivation: Activation: No client active, allowing
spstarr: kwin(5627): Compositing self-check failed, disabling compositing.
spstarr: direct rendering is yes
spstarr: glxgears is ok
cxo: i dont know whether i want to cry or swear at people when they say things like that