DavidS:hi, I'm trying to get the debian pacakges to work on my HD2900Pro, but the xserver fails with 'Failed to detect a connected monitor' after detecting the monitor via "DDC on line 1"
DavidS:where can i find documentation on the possible options to force recognition of the screen?
ndim:DavidS: The Debian packages from september?
DavidS:it's a git snapshort from 2007-10-06
ndim:Still... forget it.
DavidS:git clone to the rescue?
ndim:The simple hint is to comment out your monitor section. But 90% of the important changes have happened after that snapshot.
ndim:"git clone", or a "reportbug xserver-xorg-video-radeonhd"
DavidS:I get the same error without any xorg.conf
DavidS:the joy of new hardware. still I specifically bought this card because of the published specs, so I guess I should shut up and dig in :)
ndim:Wow. git is really awesome. I'd have expected a conflict on this merge/rebase, but no... it just did the right thing.
DavidS:ndim: yeah, for a "stupid" program, git is amazingly intelligent :) the current git of radeonhd still doesn't correctly detect my card ... I followed the trail to rhd_conntest and probably should send the requested connector stuff to the specified mail address?
ndim:Including the Xorg.123.log.
ndim:Hmm. I think this is about complete... http://radeonhd.lauft.net/
DavidS:evil domain name :)
DavidS:ndim: thanks for your patience. sent the report to the ml
DavidS:any experience how long it might take until these connectors are enabled?
ndim:Minutes, hours or days.
ndim:I haven't seen any of the devs here yet today.
ndim:DavidS: Uhm. "built from current git" and it does not print the git commit?
DavidS:sorry, I skipped that,
DavidS:the last commit was 6048f47c8178fc636de14849a51527c60460a833
ndim:The Xorg.0.log contains the message.
libv:DavidS: so did you try the latest?
libv:DavidS: whqt hqve you got connected where?
ndim:libv: 6048f47c8178fc636de14849a51527c60460a833 is the latest master, and that is in his Xorg.0.log
libv:DavidS: don't use the first DVI connector, everything else should work just fine
libv:DavidS: this will be fixed soon though
ndim:I think it might be time for pushing the ndim-git-version branch, and changing the configure.ac version from 0.0.2 to 0.0.3 :-)
emmes:egbert: have you looked at ndim's patches? I thought you wanted to.
egbert:emmes: i haven't but i should. i've got my day off today, bit this shouldn't stop me. open source is open source.
DavidS:libv: first == upper?
walder: emmes: here ?
walder: emmes: any hope encourage xrandr to make LVDS "primary" output ?
walder: emmes: I still do not get - current behaviour considereed as bug or not ?
emmes: i would assume the best would be to open a bug at bugs.freedesktop.org
emmes: this is a general randr bug.
emmes: actually, missing feature.
walder: emmes: Unfortunately I can't describe clearly what this bug about in terms of xrandr internals :(
emmes: just try, and set me to CC, so I don't overlook it. I'll comment about it if the description isn't good enough
walder: emmes: ok
libv: X.org driver for R5xx/R6xx: for more information: http://wiki.x.org/wiki/radeonhd
libv: with /topic in front that works better :p
walder: emmes: https://bugs.freedesktop.org/show_bug.cgi?id=13317
walder: emmes: what about hack-like solution provided by other drivers ?
egbert: libv: thanks for the wiki page!
ndim: libv: Great idea with the wiki page.
ndim: wonders how are we going to keep the wiki page, README, radeonhd.man, and the actual behaviour in sync.
ndim: Anyway... I'll try to work http://radeonhd.lauft.net/ into the wiki page as far as sensible.
egbert: ndim: maybe you want to create a sub page. this is easier to edit and also easier to read.
libv: egbert: split pages suck, apart from the device listing, this is actually quit short
libv: quite even
libv: ndim: what do you mean "we"
libv: *looks at ndim intently* :ppp
ndim: Anyone working on this beast, me included.
libv: ndim: btw, we should bump the version to 0.0.3 indeed and get your patches included
egbert: libv: this page can get rather big with all the distro specific information.
libv: surely all we need to know is where to point apt to?
libv: *runs away*
ndim: A sub-page for packages?
egbert: ndim: i would say so.
egbert: klick vs. scroll.
ndim: libv: NOT to debian experimental, anyway.
ndim: 20071006 *cough*
ndim: "experimental" *cough*
ndim: goes get drunk on cough syrup.
emmes: libv: great wiki page!
ndim: emmes: Yeah, he's good at copying from the man page and README, isn't he? :)
emmes: walder: what hacks are you referring to?
emmes: ndim: you know that I love your work ;-)
libv: ndim: but i'm GREAT! at copy pasting, ain't I :p
ndim: I'm glad to see it's useful enough to be copied. :)
libv: but yeah, the readme and manpages are indeed quite good
emmes: man needs a little love, but that is well known :-/
Tigerchen: emmes: hey there, i noticed a strange thing with initial-randr today
ndim: Tigerchen: It works? :P
emmes: bashes ndim *hard*
Tigerchen: ndim: nope :(
Tigerchen: emmes: well, i plugged on a monitor (without the norandr option) and the picture on external was quite ok, but the internal panel shows the usual strange crap
Tigerchen: and both panels only worked at 1024x768 (with the known crappy tiling on the internal) although they should at least agree on 1280x1024
Tigerchen: i don't know if the external supports 1400x1050 although i think so
libv: Tigerchen: so the tiling is still an issue? we need to fix this, just like we still need to add hooks to our crtc structure for crtc blanking
libv: Tigerchen: this is after resume right?
wa1der: emmes: any hints why ?
Tigerchen: libv: resume? you mean from suspend? nope. but it's the initial-randr-branch, no problems with that on master (at least at last test) or at randr with the "norandr" option enabled
Tigerchen: gotty go, will have a look in here again after i return
emmes: wa1der: why what?
emmes: Tigerchen: maybe you can send me another log file privately by mail - I got too many logs and configs, I'm a bit lost ATM
emmes: best all in one mail, including description ;)
wa1der: emmes: xrandr --output VGA_CRT1/DAC_A --auto
wa1der: X Error of failed request: BadMatch (invalid parameter attributes)
wa1der: emmes: xrandr sees second output, tells that monitor is connected, but failed to turn it "on" with --auto
emmes: wa1der: do you have a recent xrandr? i had to fix several bugs there...
emmes: hm, but with only one monitor...
emmes: wa1der: what does xrandr -q tell you?
emmes: wa1der: split personality, or what? ;-)
emmes: wa1der: i see the corrupted x cursor for the first time here!!!
emmes: and it's even only on one of the two displays, so definitely memory corruption.
emmes: reproducable! joy! 8)
wa1der: emmes: "walder Nickname is already in use. (from anthony.freenode.net)" :-(
wa1der: emmes: yaooo ! cool
emmes: wa1der: I just verified this - it's the bugs I already fixed in upstream xrandr. I just really don't understand why nobody else was running into that (especially for the intel driver)
wa1der: emmes: for me it first start on one display, then becomes broken on both
emmes: wa1der: doesn't matter. what matters is that I can reproduce this here.
wa1der: emmes: yes, thanks
emmes: what were you referring to?
emmes: I have an idea how to do that, but I'd like to do it equivalently to other drivers if there are already solutions for that.
wa1der: emmes: there was reference in irc talk or in list, if I am not mistaken, about option of other driver that just swap outputs, I'll try to find exact driver
emmes: wa1der: would be great, yes. I know what has to be done, but I don't want to do it differently than other drivers, if this is not necessary.
emmes: ndim: I just (finally) checked all your patches, and they look good. They are pushed on master now.
ndim: emmes: Great!
ndim: starts thinking about more patches.
emmes: just push them on the same branch as always, I have a shortcut for that in my git now ;)
ndim: Well, an easy way for a distribution to add some kind of identifier to the version message would be nice.
ndim: emmes: Uhm, OK, then I can't rebase that one now.
emmes: when we will have tags for released versions, that would be something
emmes: ndim: why?
emmes: if git-fetch fails, i'll just delete the branch, and be done
emmes: feel free to rebase
ndim: runs a "git fetch" and "git-rebase-subtree".
frb: libv, egbert: I've copied the bios from the card as secondary to http://for.wiw.org/rhd
emmes: has to dig a little into git to understand how shortcuts are not automatically fetched ;-)
frb: but it is identical according to diff
emmes: frb: egbert has (theoretically) a day off today
frb: I get thurs, fri off
wa1der: emmes: The old radeon driver had an option "MergedXineramaCRT2IsScreen0" for this.
wa1der: emmes: it was quote
emmes: wa1der: yes exactly. the older driver. only the RandR capable drivers are interesting...
emmes: I think I'll go for something like "OutputOrder", so you can set it to "PANEL_LCD1/LVDS,VGA_CRT1/DAC_A" or whatever they are called on your system.
emmes: better even, RROutputOrder.
wa1der: emmes: hm, probably interesting only first in order, something like "primary" option
wa1der: emmes: something like: xrandr --output PANEL_LCD1/LVDS/TMDS --primary
emmes: wa1der: yes, but why go for an inferrior solution, if this one is just as easy to implement?
emmes: also, if you only add one here, it will be primary.
wa1der: emmes: ok, in that case
emmes: this won't be dynamic, though. AFAICS there is no way to do this dynamically, without improving the Xinerama implementation.
wa1der: emmes: IMHO, it is not a problem
emmes: well, i could imagine that you would like to change things
emmes: depending on whether you attach a projector for presentation, or a local flat panel at your desk
emmes: so this *should* be dynamic.
emmes: not at first, though.
wa1der: emmes: ehh ... probably you are right
wa1der: going to try fresh radeonhd driver, with softcursor disabled
emmes: walder: not fixed yet
walder: fresh driver failed to "unsplit" heads
walder: reboot/poweroff does not helped
walder: hm... I am able manualy unsplit heads, but still can't set right resolution on LVDS
walder: conclusion: xrandr --output PANEL_LCD1/LVDS/TMDS --left-of VGA_CRT1/DAC_A - no more works for me, but --pos still works
walder: also xrandr --output PANEL_LCD1/LVDS/TMDS --mode 1400x1050 --preferred - does not works also (resolution does not changed, no error returned)
walder: Oh..., I've found the reason - outut names was changed
walder: some names
libv: right, LVTMA is either LVDS or TMDSB
libv: no longer LVDS/TMDS
libv: during the initialisation of this output it should be clear what the LVTMA block is doing, and from there i decide which name to use
libv: this is far more sensible for users
ndim: rhd_conntest: v0.0.2, dist of git branch fedora/snapshot, commit 3c724155
libv: wasn't the version bumped?
ndim: Here, the branch name shows where that program was from.
ndim: However, if someone uses the same .tar.bz2 and builds a Rock Linux or whatever package from it....
ndim: scratches his head.
Tigerchen: emmes: well i'll see what i can do I'll have to get to the uni to have a external monitor
libv: ah, there we go, tmdsb comes up nicely on rv630
libv: now hack that into code :)
frb: I wonder if my card(s) will work by the end of the year :)
libv: frb: we certainly do hope so
ndim: What is the difference between TMDSA and TMDSB BTW?
ndim: Just two output signals on one card?
airlied: ndim: just two different TMDS blocks
airlied: they do the same thing but theres two of them..
ndim: "block" being a hardware entity, or part of the encoding standard, or?
airlied: ndim: hardware entity
ndim: reads http://wiki.x.org/wiki/Development/Documentation/HowVideoCardsWork
ndim: Many things are the same as 15 years ago when I last read about the deeper workings of graphics cards.
walder: emmes: just seen X cursor glitch again - it appears on one head, then moved with mouse on another head and on return back - disappears
walder: emmes: git-rev-parse HEAD = 99fbaeeb443b5474bb99f24541ebfe697484df0d
libv: ndim: TMDSB is LVTMA
libv: ndim: B just makes more sense for users than LVDS/TMDS
ndim: Hmm. No mention of LVTMx in http://wiki.x.org/wiki/Development/Documentation/HowVideoCardsWork
libv: ndim: LVTMA is LVDS/TMDS A
libv: ndim: shared lvds tmds block
libv: ndim: flick one bit, set a load of different registers differently, and you can either drive an LVDS panel directly, or driver a DVI/HDMI connection
ndim: I guess that is ATI chip specific.
libv: ndim: yup
libv: ndim: back in early august i mailed bridgman telling him the docs were incomplete, that there was no tmdsb :) this was in the days when we weren't even able to power up a crtc with a dac enabled :)
libv: we were overwhelmed with this documentation like pretty much everyone who downloaded it is :) so much that i didn't notice how this block worked
ndim: libv: I feel so much relieved about hat.
libv: was a rather horrid start-up phase, without any overview documentation of the hardware
ndim: That's why I ignored the docs as well.
libv: we still don't have an overview that quickly describes things in a way that is referenced in the register description :(
ndim: No way to start understanding it in any way.
ndim: My thoughts are with you guys :)
libv: ndim: we do get paid, so we're supposed to suffer, i guess :)
emmes: ndim: and actually, as soon as it works, it is all the more rewarding ;-)
ndim: That is true, but I don't dare to wish you more rewarding tasks anyway :)
emmes: i'd happily write a 3d driver even and especially if i had complete docs ;)))
emmes: is off for today now
emmes: prepare for randr being merged
emmes: ph34r me ^__^
frb-work: unless you're fixing my 2600 problems, I have gn0 ph34r
libv: frb: we will fix these, don't worry :)
libv: just make take some time still ;)
frb-work: then he gets gn0 ph34r from me
kereoz: hi there
libv: cool, TMDSB on hd2600xt works nicely
tomaha_: libv: great :-)
libv: now testing the other rv6xxen i have here :)
kereoz: an idea of how to build radeonhd on openbsd ?
libv: should work just as well
kereoz: I cannot run ./autogen.sh without a lot of undefined macros
libv: kereoz: did you read the readme? :p
kereoz: but i did not help
libv: so which macros are undefined?
kereoz: just a minute, I fetch it and run it again :)
kereoz: configure.ac:13: error: possibly undefined macro: AM_INIT_AUTOMAKE
kereoz: configure.ac:15: error: possibly undefined macro: AM_MAINTAINER_MODE
kereoz: configure.ac:18: error: possibly undefined macro: AC_DISABLE_STATIC
kereoz: configure.ac:19: error: possibly undefined macro: AC_PROG_LIBTOOL
kereoz: configure.ac:35: error: possibly undefined macro: XORG_DRIVER_CHECK_EXT
kereoz: configure.ac:56: error: possibly undefined macro: AM_CONDITIONAL
kereoz: configure.ac:192: error: possibly undefined macro: XORG_MANPAGE_SECTIONS
kereoz: configure.ac:194: error: possibly undefined macro: XORG_RELEASE_VERSION
frb-work: that's easy
frb-work: 1> install automake
frb-work: 2> install libtool
frb-work: 3> install the xserver SDK package for your distro
frb-work: in suse 10.3 it's xorg-x11-server-sdk iirc
kereoz: automake is installed but I forgot to define AUTOMAKE_VERSION
kereoz: in openbsd, the only thing I can do is fetch Xorg cvs
kereoz: (i already tried without success)
kereoz: do you think it could work ?
ndim: I am sure OpenBSD has a possibility to build software for X.
ndim: And for that, it must have some sdk/macro/whatever package/port/whatever.
mjg59: Isn't OpenBSD still shipping the monolithic tree?
kereoz: now it's a new way to do it
kereoz: jsut a minute (i check the name)
ndim: (Sorry, I have not done OpenBSD administration in years)
frb-work: I haven't used any bsd in like 7 years
mjg59: Ok. Then you're simply missing the development environment.
kereoz: xorg for openbsd
kereoz: but it's based on xorg 7.2
libv: kereoz: should be perfectly ok for us
libv: kereoz: our driver doesn't mind :)
ndim: kereoz: If you just need a very quick hack, you could try the xmkmf based build method.
libv: oh, but does he have the sdk or a prebuilt tree installed then?
libv: because without that, even the imake route is not useful
ndim: Of course.
kereoz: if I fetch the code, I have the full source tree
kereoz: in /usr/src
kereoz: but I don't know if there is a way to avoid downloading the full three
libv: kereoz: then it should work perfectly, if the source tree has seen at least a partial make
kereoz: a partial make ?
libv: i used to know which make commands you had to actually run before you could build a driver against an xc tree
libv: and i can't access the machine from here which has that sort of info (as the dsl modem needed to do that is lying here as well :p)
libv: kereoz: iirc, Makefiles and includes, preceded by two black magic calls
libv: one was a touch of something in config
frb-work: I haven't built X manually in like 5 years either
kereoz: ok cheers :) I'm goind to have a deeper look a this
kereoz: I did not expect a partial build to be needed
libv: kereoz: otherwise, just start the build, and ctrl-z /fg it until xmkmf against it works :p
libv: very unscientific, but works :)
alessandro_: whats happening with radeonhd, now that theres support for 500 in radeon?
libv: alessandro_: radeonhd just continues?
libv: alessandro_: i have no idea why completely different modesetting is being forced into that driver.
libv: makes no sense from a technical point of view
kereoz: libv, :)
libv: alessandro_: it isn't as if -ati isn't a big enough mess as is
libv: alessandro_: it's much easier to port over 2d accel to our driver than it is to force avivo style modesetting into that driver
alessandro_: libv: thats what i thought too
alessandro_: but why not "integrating" radeon hds cleaness into radeon?
libv: alessandro_: what for?
libv: alessandro_: gains nobody anything
libv: alessandro_: as said, we need to port over 2d acceleration and be done with. this is the only sensible solution
alessandro_: libv: making the driver cleaner and leaner?
airlied: alessandro_: we were adding atombios support to radeon to support some r400 features, funnily enough adding r500 support wasn't that hard..
libv: alessandro_: probably, somebody else can do this work
alessandro_: airlied: so whats happening in future? :-)
frb-work: I'd rather see the driver work on newer cards than integrate with older ones
libv: frb-work: yes, yes :p we will fix your offset issue :ppp
airlied: alessandro_: what I said on the blog.. r600 2D accel..
airlied: alessandro_: and r500 3d support..
frb-work: libv: it's not just for my card though
alessandro_: airlied: but your not going to work with the readeonhd guys in future?
libv: airlied: so why not do this with the radeonhd driver?
frb-work: libv: the point of this driver is to make a new one for the new chips with the new arch, not to hack stuff into the original driver
airlied: libv: the code already existed for accel. I didn't have to touch it..
libv: frb-work: exactly
libv: airlied: you had to do a lot more work though
airlied: libv: no that's the point I didn't really..
airlied: libv: I have a lot of tested accel and dri setup code..
libv: and pull in about 10kloc of foreign code
airlied: libv: the atombios code is foreign but needed for proper r400 supprt in any case
libv: airlied: so the xaa/exa stuff is working?
airlied: libv: yes out of the box.. with drm support
libv: airlied: great, we look forward to pulling that into radeonhd then
frb-work: I forgot to check the license on radeonhd
airlied: but the radeon driver isn't the radeon driver from years ago..
libv: frb-work: MIT, of course
alessandro_: sorry for that dumb input but that looks like there will be 2 drivers in future
frb-work: it's against my principles to work on anything under the GPL v3
libv: frb-work: pure MIT
airlied: its a lot cleaner since randr-1.2 and agd5f..
frb-work: ok, I like the MIT license
libv: airlied: then we will have a lot easier time pulling the tiny bit that is xaa/exa acceleration in
libv: airlied: thanks :)
airlied: libv: xaa/exa accel isn't that tiny though..
airlied: libv: neither is dri support
alessandro_: airlied: can i try your work?
libv: airlied: compared to modesetting?
libv: airlied: who are you kidding?
airlied: libv: modesetting with atom is trivial..
airlied: libv: I just call some functioon..
libv: airlied: sure.
libv: airlied: did a vt restore recently?
airlied: libv: we seem to restore on exit properly..
airlied: the D1VGA regs do all that stuff quite well..
libv: only d1vga doesn't help.
airlied: oh I know that but at the moment I vt restore fine, I'm not sure if its luck or design though..
libv: but i guess you'll find out
airlied: and playing wth d1vga seems to be quite useful..
airlied: I'm also looking at this from a kernel modesetting pov..
libv: if you have everything else set up correctlym yes
airlied: if I have to get atombios code into the kernel I really want to use it..
airlied: as rdeonhd didn't want to use it, I wasn't left with a massive amount of choice..
airlied: now we may hit issues with atombios but as you guys never enumerated your issues I think we'll have to figure it out ourselves..
libv: so you think we never enumerated our issues?
airlied: libv: not publically.. and AMD haven't given me anything internally..
libv: feel free to ask bridgman
airlied: libv: exactly.. not something I can publically reference..
libv: airlied: this was august and early september, when we were not allowed to talk about this
libv: airlied: just like you weren't allowed to talk about what you were doing until your nda thing was cleared
libv: airlied: is this the code you were working on a year or so ago btw?
libv: airlied: or is this something new, partly based on -avivo?
airlied: libv: not quite.. the drm code is 2 years old..
airlied: libv: and the memory controller setup is 2 years old..
airlied: but the rest is radeon + radeonhd + more atombios code
airlied: I started using some avivo code but it mostly disappeared as I added atombios..
libv: so the drm code and memory controller setup was previously blocked by the legal issues?
airlied: libv: yea I used registers that hadn't been released..
airlied: libv: I've now cleared those registers with AMD for release if they weren't in the docs
airlied: libv: and I've just cleared a bunch of r600 mc regs..
alessandro_: airlied: sorry for asking again, but any release of your code just yet?
airlied: alessandro_: atombios-support branch of xf86-video-ati
airlied: alessandro_: r500-support of drm repo
alessandro_: lets see if i can get them together
alessandro_: im on x1400 mobility
airlied: alessandro_: what hw you got? it works best on r5xx..
alessandro_: anything on powersaving?
airlied: alessandro_: not yet.. but we have atombios entry points and tables..
alessandro_: sounds good
alessandro_: really looking forward
airlied: alessandro_: my main focus is 2D accel on r500/r600 and 3D accel on r500 going forward..
alessandro_: thats exactly what i need :)
airlied: alessandro_: with agd5f hopefully hitting the atombios modesetting code..
alessandro_: randr is already working?
airlied: alessandro_: works for me.. but mileage may vary :)
alessandro_: so agd5f is working on radeon as well?
airlied: alessandro_: yes..
alessandro_: thats somewhat obsoleted radeonhd for me now..
airlied: alessandro_: only if it works :-)
alessandro_: it will :-)
airlied: alessandro_: for the drm I need to add the pciids..
alessandro_: what card did you test it on?
airlied: alessandro_: but the DDX should be ine without it ..
airlied: alessandro_: X1300, X1550, X1900, X1950 and sotart on HD2400XT
airlied: sorta on
alessandro_: hm, so just about any other card except mine :-)
airlied: alessandro_: what you got?
alessandro_: x1400 mobility
alessandro_: in a thinkpad t60
Tigerchen: alessandro_: works like a charm here
airlied: ah that could be fun.. I've been trying to get LVDS testing :-)
Tigerchen: on a t60 2007-vce
airlied: Tigerchen: the radeon or radeonhd driver? maybe we should move to xorg-devel or somewhere -)
alessandro_: airlied: its just a bit confusing finding those branches.. i always hit radeonhd related stuff
alessandro_: Tigerchen: were talking about radeon
libv: Tigerchen: we will get you 2d accel as soon as we find the time btw :)
airlied: alessandro_: git://git.freedesktop.org/git/xorg/driver/xf86-video-ati
Tigerchen: thinks he'll better go to sleep
libv: right now i'm still stuck doing lvtma, emmes is fixing most of randr (not that many driver side issues apparently), and egbert is working on other remaining issues
alessandro_: airlied: can i switch the branch through git-fetch origin? im not into git yet :-)
airlied: alessandro_: once you clone the tree .. just git checkout atombios-support
libv: surprising how many randr bugs did come up.
Tigerchen: i just don't get it why it tries to set up my display with 1024x768 without the norandr option
alessandro_: its weird that only radeonhd is hitting these bugs
libv: Tigerchen: with or without?
libv: alessandro_: they are proper and clear bugs
alessandro_: how do intel and radeon get around them? hacks?
Tigerchen: with -> no problem, 1400x1050. without -> 1024x768 and tiling stuff
libv: alessandro_: apparently emmes is not brushing thigns under the carpet
airlied: libv: in server code? fixes in tree yet?
libv: alessandro_: many people are reporting rather good feedback and work with us on the bugs that pop up
libv: airlied: of course, haven't you been paying attention?
libv: Tigerchen: so the proper modesetting code works rather happily on your panel (even though i haven't put in the multiple mode handling yet), but randr just lands you with 1024x768?
libv: Tigerchen: weird
libv: Tigerchen: but then, emmes is iirc working with you on that already
Tigerchen: i thought so, but i wnated to check with an external panel first and produce a log
Tigerchen: I'll do so tomorrow
Tigerchen: no i think I'll go to bed
airlied: libv: no commits in server tree from you guys to randr code..
airlied: ah I did see some talk on the list..
libv: hrm, dacb fails to load detect, weird.
libv: egbert: there is something seriously wrong with the connector table i am seeing right now
frb-work: I heard egbert was off today
libv: the 2400xt is reporting two dvi-i, while it has one vga and one dvi
libv: frb-work: yeah, i know, but he gets up early :p
libv: bah. from what i can read in the new atombios connector information, it is handling things correctly, but the information there is just broken
libv: and because there is of course no DVI there, there is also no hpd to listen to, and then we ignore the connector.
libv: good thing we are able to work around this sort of nonsense.
ordchar: lets check this new r500 support :)
alessandro_: same here
alessandro_: im off for giving it a try
ordchar: i see the atombios-support branch, but the r500 is hiding from me
airlied: ordchar: that's the one
ordchar: cool, tnx
ordchar: i need to add my pci id's?
airlied: ordchar: nope I should have added them all..
airlied: ordchar: granted maybe not correctly :-)
airlied: blind adding pciids is always fun..
ordchar: i see an 7145 in the .csv so lets give this a go :)
alessandro_: airlied: what shouldnt "radeon" be enough in xorg.conf?
airlied: alessandro_: should be ...
alessandro_: doesnt come up just yet
alessandro_: no magic or something?
airlied: alessandro_: pastebin the log..
airlied: alessandro_: or mail me it firstname.lastname@example.org
alessandro_: airlied: i first need to get gdm to stop fireing up this silly Xorg config tool
alessandro_: oh well i try with startx
ordchar: well i would be suprised if my card works from the first try seeing my history with fglrx,avivo,radeonhd .. but who knows :D
alessandro_: airlied: its simple
alessandro_: doesnt detect my card
airlied: alessandro_: ah maybe I missed a pci id
ordchar: my appologies i forgot to save the log. but it _definately_ did not work :( I had this scary effect where the screen appeard broken, a white color started filling the screen from the corners
airlied: ordchar: laptop?
ordchar: acer aspire 5672
alessandro_: airlied: u should have mail
ordchar: arlied it: it look very much like an etch-a-sketch toy
airlied: alessandro_: you don't have the branch checked out or something..
airlied: alessandro_: no r500 in that driver.
alessandro_: i cloned the branch
airlied: alessandro_: git checkout atombios-support
alessandro_: and did a git-fetch origin atombios-support:atombios-support
libv: ordchar: bleeding?
alessandro_: airlied: this didnt work
airlied: libv: sounds like lvds turned off.
libv: sounds rather nasty
ordchar: libv, that could describe it, but i don't know what you understand with that word, i feel like an ass not saving the log though
airlied: ordchar: no worries.. I'll try and get a laptop here..
alessandro_: airlied: so whats the svn up counterpart?
alessandro_: thats what i probably missed
ordchar: alessandro_, git pull; git checkout origin/atombios-support
alessandro_: pull updated 15 files
alessandro_: is that "right"?
alessandro_: im seeing atom bios
alessandro_: while make-ing
libv: alessandro_: same code complains all over our tree you know :p
libv: would be good to see those nasty comments and whatnots fixed in those headerfiles
egbert: libv: without pedantic you don't see that many complains
libv: ah, right. -ati
libv: once upon a time, it didn't even do -Wall
alessandro: airlied: it somewhat worked now
alessandro: but its getting from black into my gdms color while beeing very pixeled and slow
alessandro: airlied: next log is on its way
ndim: airlied: xf86-video-ati atombios-support branch needs to add radeon_atombios.h to EXTRA_DIST in src/Makefile.am.
airlied: okay I've disable mobile chips for now until agd5f can push some changes that may help..
alessandro: so u dont see anything wrong with my log actually?
airlied: alessandro: what have you plugged in btw?
airlied: alessandro: at least we get DDC from the panel and dvi output..
airlied: actually panel and vga output
alessandro: airlied: a Dell 24 incher on the VGA
alessandro: but it told me that the resolution is out of range
alessandro: while the LVDS (?) the Laptop panel tried to display something
airlied: alessandro: yeah I think our laptop support needs some work which isn't surprising considering your the first person to try it :-)
airlied: alessandro: I think agd5f has some fixes upcoming that should help, but I'll see if I can source some hw..
alessandro: airlied: i keep an eye on the gitweb rss feed then
alessandro: and will come back
alessandro: dammit only the main summary is feeded
alessandro: airlied: so i should give it a try again in some days?
airlied: alessandro: yes I'll post on my blog when we get another bit done.
alessandro: airlied: nice
alessandro: thanks for now
alessandro: :-) see you guys
ordchar: better add your blog to my rss reader then
ordchar: whot no rss what kind of crap is livejournal :)
ordchar: (o nm)
rx__: there is ;)
dli: airlied, is r500 already supported by the git version xf86-video-ati?
airlied: dli: in the atombios-support branch
airlied: dli: not in master yet..
dli: airlied, great, let me try it now
airlied: dli: if you are on !laptop it may work okay.. laptop not so good.
dli: airlied, too bad, I'm on laptop :)
dli: airlied, I would have thrown the ati card away otherwise :(
dli: airlied, no luck :( R500 mobility support is incomplete. You need to force enable it
airlied: dli: yeah I disabled it to avoid anyone messing up their panels :)
dli: airlied, I see, I should wait then
dli: airlied, would r500 support xvideo for movie playback soon? still no ETA for radeonhd
airlied: dli: no different.. for radeon, they removed the playback hw..
dli: airlied, at least, I want to see the same speed as avivo. I have been told again and again about "the same speed", but avivo is simply faster, fast enough for fullscreen video playback
airlied: dli: that is wierd..
dli: airlied, I get the speed for radeonhd, if I run avivo on :1