soc: hi everyone
libvde: emmes: lunch is probably not going to happen...
emmes: lol
emmes: the two of you still have headaches?
libvde: no!
libvde: we're just... not fully lucid yet :p
sonne: I am now for the first time using radeonhd to connect to a TFT via an analogous port and the display is slightly greenish, i.e. everything that used to be grey is light green
sonne: forget it... heisenbug
libv: :)
sonne: libv, I am not sure what that was: first everything was greenish, then there was no more grey (==it was white) and now it is OK...
Death_Syn: signal interference?
bahadunn: are the via unichrome drivers still open source?
bahadunn: not that I expect you guys to know really
bahadunn: seems like via and amd are the only ones doing open source drivers right now
bahadunn: oh and intel I think
libv: bahadunn: were they ever open source?
libv: bahadunn: via has always shipped binary only bits in it
libv: bahadunn: and their dri has been binary only for a while now too
libv: but my unichrome driver has always been open source, it just doesn't support hardware i didn't have at the time when i was still actively working on it
libv: now i have two more devices... but no time
bahadunn: libv: I saw some articles on phoronix saying that back in 2005 via open sourced its drivers
bahadunn: libv: and there is a via driver for xorg apparently
libv: in 2005?
libv: HAH!
bahadunn: thats what it says
libv: this was first done in 2003
bahadunn: I read some article that also said via open sourced and then closed source the driver again
libv: but this is not really open source
bahadunn: its very confusing trying to figure out what the deal is with via's drivers
libv: bahadunn: find out where this information came from :p
libv: <--
bahadunn: it came from you?
libv: via is rather clueless
libv: yes
bahadunn: I read that also
libv: http://libv.livejournal.com/11205.html
bahadunn: so in 2008 via's drivers are not open source correct?
libv: they never passed the bill
libv: part of it is open sourced
libv: but not thatz those bits are useful
bahadunn: I see
bahadunn: so if I wanted to use a via driver for graphics I have to go through their installation method?
bahadunn: I would like to just use the xorg-via drivers
bahadunn: not sure if they are the same as via's drivers or not
libv: no, depending on what hardware you have and what xserver tree you want to run against, you should use openchrome (but your mileage will vary) or my unichrome code (where i only support the hardware i own)
bahadunn: well right now I have a mini-itx via board with the CN700 chipset
bahadunn: but I use this system as a router/firewall with no graphics
bahadunn: and I bought the system with that intension
bahadunn: and my intensions have not changed
bahadunn: but I thought there was an open source driver so I was tempted to try it out with the motion compensation etc... and see what it could do for video playback and all that good stuff
bahadunn: but now I think I wont waste the time
bahadunn: are you guys impressed with amd's open source moves?
bahadunn: do they seem sincere about it?
libv: bahadunn: we are the people doing part of AMDs open source moves
libv: bahadunn: amd asked us for ideas on doing this, we eventually gave them a proposal, and here we are; radeonhd
libv: bahadunn: amd is fully backing open source drivers. amd wants to make money on selling hardware, and therefor they are doing everything possible to get their hardware supported under linux
libv: and other free software of course
bahadunn: good
bahadunn: I have always liked AMD as a company and been using them for years
bahadunn: I am glad to see them do this
bahadunn: right now I use nvidia stuff mostly
bahadunn: but I will be switching back to ati to support amd
libv: we do not think nvidia will go fully open source soon
bahadunn: I dont either
libv: i think most people hoped that amd would open source ati at some point after the acquisition, and this is exactly what is happening now
bahadunn: I think nvidia will keep doing what they are doing right now for some time
bahadunn: yes
bahadunn: I agree
bahadunn: how long before the radeonhd drivers support most features of ati's cpus?
bahadunn: gpus I mean
libv: well, this year still ;)
bahadunn: is there a projected timeframe?
bahadunn: like a roadmap?
libv: anything more precise cannot be said, we're moving as fast as we can without losing track of quality
bahadunn: yes I know
libv: we need this stuff to be solid most of all, features come second place to that
bahadunn: quality is most important
bahadunn: yes I was not trying to give the impression of rushing anything
bahadunn: I was just wondering for an informed opinion of the future
libv: well, we're still somewhat evaluating things, gathering as much information as we can on 2d and 3d, but we hope to have some things working this quarter, most things work next
bahadunn: this stuff sure is exciting for open source people
libv: but then, there's always something that stalls things left and right, and we have to keep up with ATIs new hardware releases
bahadunn: true
bahadunn: I read some things saying that hd playback might be a problem because of the drm parts of their gpus
bahadunn: I read that they must make a decision on that
libv: well, it will have to handled by cpu and 3d engine
bahadunn: something about modularising it or cutting drm out completely
libv: there is no way that amd can disclose what they are not allowed to disclose at all
libv: it's a movie industry thing
bahadunn: yes I know
bahadunn: how will the 3d engine handle hd playback?
bahadunn: will it be as good as the hd hardware playback?
libv: time will tell :)
bahadunn: true
bahadunn: I am waiting for amd's new IGP chipset to come out
bahadunn: looking forward to it a lot actually
sytse: libv: btw, what is your stance on radeonhd vs xf86-video-ati for cards supported by both?
libv: sytse: splitting the x driver off between r4xx and r5xx is the only sensible technical solution
libv: sytse: which is exactly what we did with radeonhd
sytse: libv: so it's not supposed to be a platform for getting things working properly as quickly as possible, but after a year or so candidate for complete merging into xf86-video-ati?
libv: sytse: radeonhd will not merge into -ati
libv: sytse: -ati is being split up and should disappear
sytse: ah, of course :-)
libv: sytse: it should become -r128 and -radeon
libv: sytse: -mach64 has already been split out
sytse: yes, but -radeon supports r4xx and r5xx now, too
libv: your mileage will vary.
sytse: well, preliminaril
sytse: y
sytse: yes, definitely, but is it not possible to create a unified driver for earlier radeons and r4xx/r5xx/r6xx?
sytse: or at least, not sensible
libv: why?
sytse: ah well, maybe I should just have a look at the code some time, that might answer these questions more properly for me..:-)
libv: sytse: there is barely anything for an X driver to share between r4xx and r5xx
sytse: well, it just seems odd to me, that there's two drivers attempting the same thing atm
sytse: ah
libv: so the only logical thing to do is to have split X drivers.
libv: as said before...
libv: 17:45 < libv> sytse: splitting the x driver off between r4xx and r5xx is the only sensible technical solution
sytse: yes, sorry, misread that
libv: all that can really be shared is r5xx 2d acceleration and drm initialisation
libv: which is tiny compared to the rest
libv: and which cannot be shared with r6xx either
sytse: so you're basically saying that the guys trying to write atombios/r5xx support for the 'radeon' driver are not doing a sensible thing?
libv: sytse: yes
libv: sytse: feel free to quote me on that everywhere, i do not exactly make a secret of this.
sytse: :-)
libv: which really makes me wonder why you are asking questions along this line
libv: because my stance in this is rather obvious
sytse: heh
sytse: well, I've just joined here yesterday
sytse: my knowledge doesn't really exceed what you can defer from phoronix' headlines ;-)
sytse: but I should really UTSL instead of asking questions..
libv: right, in that case i am sorry, but i really do not deal well with things that are not fought on technicalities but purely on politics, and this is exactly what the radeonhd versus radeon thing is all about. I try to seek the best technical solution everywhere, within my own, apparently, very unpopular criteria (like being backwards compatible), but this search of the technically most ideal is something shared by only a few people it seems.
reist: hi everyone
reist: i'm trying to get my HD2600Pro running with radeonhd, but all i'm getting is a black text screen with an unblinking cursor in the corner
reist: is there anything i can do to find out what is wrong?
reist: the radeon driver does works - that's what i'm using now
libv: reist: latest git?
reist: yeah
reist: i think my whole xorg build is latest git
libv: did you have the same problem with 1.1.0?
reist: yes
reist: i've been trying for about two weeks
libv: ok, can you send a log with -logverbose 7 to the mailinglist?
libv: oh, wait a second
reist: oh, 1.1.0 is older than that...maybe i missed it
libv: did you run the radeon driver before this?
libv: did you powercycle in between?
reist: ah, probably not
libv: or maybe the fglrx driver?
libv: right, this could be it
libv: we restore whatever we set, or get very close at least
reist: fglrx doesn't run on with git head - missing symbols
libv: because we know what we set :)
reist: i see :)
reist: i'll try powercycling now
reist: and then 1.1.0 as well, just to be sure
caramba: libv: Hi! I also have problems with 2600 HD. I posted this dump http://lists.opensuse.org/radeonhd/2008-01/msg00128.html
caramba: I'm not sure if I got it right with the -logverbose 7, does it look ok?
reist: libv: I've tried with both git head and 1.1.0
reist: same result: the screen flickers once, and i see an empty text screen with an unblinking cursor on the top-left edge
reist: only ctrl-alt-del works to reboot
reist: i'm getting the same Xorg log too, only the radeonhd version changes
reist: caramba: you have much more information then me
reist: i tried running 'startx -- -logverbose 7'
reist: but my log is miniscule
caramba: yes that's waht I did too
caramba: I'm wondering if my problem is simply that the monitor sends an incorrect EDID
reist: oh, one thing I can tell - my card is unlisted in the code (wasn't listed in pci.ids either)
reist: I added a line for it in rhd_id.c, but it didn't change anything either
reist: here's the line:
reist: { 0x9589, 0x1458, 0x2180, "Gigabyte HD 2600 Pro", RHD_CARD_FLAG_NONE, DVI_BA10_DVI_AB01 }
reist: I just copied the Sapphire line and changed the ids according to what lspci gave me
libv: reist: where is your log?
libv: reist: for this it should also be perfectly ok to just run Xorg -logverbose 7
reist: libv: http://lists.opensuse.org/radeonhd/2008-01/msg00193.html
libv: reist: it looks as if our driver doesn't even get to do anything itself much
reist: yes, it's really strange
reist: the radeon driver loads fine, but radeonhd gets stuck there
libv: reist: could it be some issue with resource management in X?
reist: can't really tell
reist: i can program, but i've never dealt with drivers or X
libv: reist: can you run Xorg in gdb
reist: i can try
reist: what do i do while it's in gdb?
libv: well, do this remotely
libv: and have a second login and kill the Xorg process
libv: no hard kill, just a normal kill to have gdb pick this up
libv: then backtrace
reist: alright, i think that's doable
reist: will need to get a friend's old computer on the lan
reist: hope it'll work alright
reist: anyway, this'll have to wait for tomorrow
reist: good night
reist: libv: hey, seems i got a bit insomnic thinking about the issue :p
reist: anyway, something very strange seems to happen with radeonhd here
reist: xorg crashes with a missing symbol...
reist: xf86stat
libv: hrm
libv: could be... all the libcwrapping was supposedly removed
libv: reist: it is not a symbol ffrom our driver
reist: well, nm sees as U...
xAFFE: I have a realy strange problem, I just discovered. I cant change the backlight of my laptop. I need to switch to tty1 and there I can change the brightness flawless. Any ideas, how this can happen?
libv: xAFFE: yes, well known problem
xAFFE: ah ok
reist: libv: well, that's strange - that symbol seems to come from some headers that seem to not be part of X anymore
reist: or at least not what i have in the source directories...
xAFFE: is there something I can do to support the development?
libv: hrm....
libv: right...
libv: let me pull in some more git stuff and see this
libv: because this is still symfunced
libv: but doesn't seem to be defined anymore
reist: libv: and now that i deleted them, the symbol's gone from what nm lists
reist: xf86_ansic.h and xf86_libc.h
libv: right, leftover from an old install?
libv: reist: this is what happens when you use a distribution without a package manager :ppp
reist: yeah, about a month and a half ago, i think
libv: hides from marcheu
reist: hehe
reist: well, Slackware does have _something_
marcheu: libv: ?
libv: marcheu: you old slackie you :p
marcheu: libv: I use fedora ATM
reist: is the slackie :)
reist: right, trying again...
libv: marcheu: you admitted to it recently... sins of youth and such
marcheu: oh sure, but ATM it's fedora
marcheu: 6 months ago I had mandriva...
marcheu: I'm some kind of switcher
libv: :)
marcheu: so I don't take distro wars personnally, otherwise I'd waste a lot of time that way
reist: libv: it works! i'm using radeonhd now
reist: thanks
reist: it even works with my old 17" connect as a secondary
reist: and switches resolutions (the radeon driver really couldn't do that)
reist: and the card line i added to rhd_id.c seems to be working :)
reist: "(--) RADEONHD(0): Detected an RV630 on a Gigabyte HD 2600 Pro"
airlied: reist: wierd radeon couldn't switch resolutions? got abug number?
reist: no...didn't open one for it
reist: i really got the whole system (with card) built two weeks ago
reist: was just testing everything until now
reist: anyway, xrandr or gnome's display properties - they both didn't change the resolution of the 24" DELL from 1920x1200
reist: and i got the display on monday, so it's all been experiments this week
reist: airlied: i could try and check again exactly what happens if you want
airlied: reist: I'll give my own card a go, something may havbe brokne in it..
reist: alright, and I'm off (with a task for tomorrow to scour my system for old headers <_< )