libv: hi udovdh
udovdh: anything for rv630? ;-)
udovdh: got through the weekend ok?
libv: somewhat :)
libv: i should label my weekends "the dead zone" or something
Tigerchen: libv: lying on the sofa, doing nothing?
libv: something like that :)
Tigerchen: I'm currently correcting homework from "my" students... that sucks
libv: dotclock testing here as soon as i have done some final emails
udovdh: emails with details on specs?
libv: udovdh: no, emails about fosdem :)
egbert: plectrum: any chance to test my patches?
plectrum: egbert: not yet. I just tested the one patch. Just starting the day here
plectrum: egbert: do you just mean the diff.radeon_mc_idle or are there more? I updated the bugzilla after testing the mc_idle patch
egbert: plectrum: i've added two more to bugzilla.
plectrum: ok I will test them out
egbert: plectrum: btw: did you check if the lockup you got with the vga text console (non-fbdev) went away?
plectrum: no, I have not tested the lockup anymore but will add that to the test plan
egbert: plectrum: thx.
ndim: wonders whether there is a way to find out which "module ABI version major number" a given Xorg server expects.
ndim: ( https://bugzilla.redhat.com/show_bug.cgi?id=431176 )
plectrum: egbert: looking good so far!! I have switched back and forth 10 times and all is working well
plectrum: it seams a bit slower, but I take it that is for stability sake
plectrum: hmm, but you didn't really add much delay except 20 us so that must just be a perceived slow down, right?
plectrum: egbert: Hey hey!! the lockup with the vga text console is gone too! great job!
egbert: plectrum: sounds good! no there has not been much delay added :) so it is largely perceived, i guess.
plectrum: egbert: I updated the bugzilla
egbert: plectrum: thx!
egbert: plectrum: so can we close this bug? what do you think?
plectrum: I think so. close and move on to more fun stuff, please ;)
egbert: plectrum: ok :)
libv: egbert, plectrum: nice work :)
egbert: libv: :)
plectrum: now I have noticed with no fbdev that there is some junk on the console, but `setfont takes care of it. Is this normal?
egbert: this is the 'other' problem.
egbert: the one with the unreachable aperture. which we though was causing trouble before.
egbert: in fact when you are using linux the kernel should restore the console font itself. i fixed this once.
plectrum: it is mostly readable but well just some extra junk.
egbert: plectrum: ok, we will eventually fix this. but it doesn't have high prio.
plectrum: not at all
plectrum: just a minor annoyance and sounds to be there kernel's faul right?
egbert: well, it used to be that the server had to restore text mode completely. not it should really be done in the kernel. i need to look why this isn't happening.
plectrum: as I said no biggy
udovdh: BTW: did you see http://fedoraproject.org/wiki/Features/OneSecondX ?
soc: does anyone know why opengl3 doesn't get released and there is no public communication about it anymore?
firewing1: I'm running on a Radeon 3850, I can't get DRI working
firewing1: distro is Fedora 9/development, Xorg 1.4.99
firewing1: No errors in the Xorg logs, I have a simple Xorg.conf with only a Device section to specify radeonhd
firewing1: `drm' kernel-module doesn't get autoloaded either, manually loading it doesn't do anything
firewing1: SELinux is off, and this is the only warning in Xorg.0.log: (WW) RADEONHD(0): DACBSenseCRT: connector type 4 is not supported.
firewing1: Would that mess up DRI?
firewing1: Something else weird, glxgears returns "Error: couldn't get an RGB, Double-buffered visual", but if I run "while true;do glxgears;done" it will eventually show up
libv: firewing1: we have no dri for such devices :)
firewing1: libv: It was working before though?
libv: hrm... on pure software rendering?
egbert: firewing1: no.
libv: nothing should've changed
egbert: firewing1: only 2d.
firewing1: egbert: Weird... I'm 99% sure "glxinfo|grep direct" return yes
firewing1: atm it's showing No and everything is slow because of software rendering... I'm sure it wasn't like that before
libv: firewing1: so you're saying that you had a fully working dri driver before...
libv: a phantom dri driver?
firewing1: I thought so... but either way it wasn't software rendering
libv: firewing1: was the moon full? ;p
firewing1: I could for example use glxgears or view the Rhythmbox visualization just fine without killing my CPU
firewing1: airlied: nope
firewing1: fglrx doesn't start with Xorg 1.4.99
libv: firewing1: i thought time machines were still not invented ;p
libv: it's either fglrx, or it is nothing :)
firewing1: Well, is there an approximate ETA for dri?
libv: at this point that is :)
firewing1: I mean are we talking days, weeks or months?
libv: months at least
firewing1: hm, alright
firewing1: well thanks for the info :)
firewing1: I'll try my luck with fglrx 8.02, I haven't tested that with Xorg 1.4.99 yet
libv: it will happen though, but it still is far in future sadly
libv: we are not exactly progressing as fast as we would like :(
libv: if only the pll block on rv620 wasn't redesigned and had kept the restrictions rv610/630 :(
sneakums: i have an x1550 here (PCI device ID 0x7143) that needed Option "HPD" "off" for the DVI to work, is there any useful info on this i can gather for you? using driver for git as of commit a9af866.
libv: sneakums: can you read the readme to rhd_conntest?
libv: sneakums: and then provide a full log to the mailing list?
libv: sneakums: we can then add an appropriate entry to the id table for this card
sneakums: will do
snoopy291: Egbert, I have a question
snoopy291: you wrote: egbert: dli: i can run radeonhd on rs690 full screen 1680x1050 without any problems.
snoopy291: I'm having a problem getting my X1650 to work with my 22" monitor at 1680x1050. Could I see your xorg.conf?
snoopy291: using the radeonhd driver, of course