so1: hi
so1: i'm just wondering: the radeon driver supports the later gpus too since some days ...
so1: what are the differences beween radeon-hd and radeon?
so1: or the plans for the future?
so1: is it likely that there will be 2 seperate drivers or will the unified in one way or another?
emmes: so1: easy, they pulled in our code. noone knows where this is going, the radeon driver is IMHO an unmaintainable mess
so1: mhhh
so1: so besically they are able to use their old code for accelerating 2d with exa on some new cards?
emmes: exactly
so1: and the important different opinion is, that they want to use atombios for output, and you don't, is that right?
emmes: we wanted to extract the according bits into our driver as well, but we didn't have the time so far.
emmes: well, we use atombios as well, if it is suited. we just found to many issues for the simple things (like programming the pll)
emmes: and these typically don't change from chipset revsion to revsion at all
emmes: it's just a pitty we even have to talk about "they" and "us" :-(
so1: mh ok
so1: hope people find a way to cooperate :-)
so1: are there any plany to support earlier version too?
so1: r200/300 and so on?
so1: so to speak, you try to extract the information from atombios whereas radeon whats to use the functuions of atombios?
emmes: nope, we'll not support older chips than r5xx.
so1: ah ok
emmes: partially, you can put it that way. it's not 100% correct, but good enough. e.g. we use atombios for AsicInit, that is initialization.
emmes: we use the connector tables etc.
so1: ah ok
emmes: all chips before r5xx have a different layout, and r4xx has only parital atombios support
emmes: that's why we don't want to support them.
so1: so it would probably better to have shared code instead where it makes sense ...
so1: 2 implemetations are always good :-)
emmes: eventually we could dynamically load the radeon driver for them, so you wouldn't have to change the driver to run an old card, but that is only wild speculation.
emmes: somehow, yes. But the difficult bits (PLL etc.) have been copied from our driver, so there's only one actual implementation.
so1: do you know if things for gallium3d is already on the horizont?
emmes: no docs.
so1: or is this far far away?
emmes: i'm not exactly sure how the gallium base system is yet.
emmes: s/how/how far/
so1: so better wait and see ...
emmes: yes
so1: i heard it would reduce the driver sizes, beacuse many additional things can be shared between them ... but that's only my haöf-knowledge :-)
so1: /s/haöf/half
so1: i would love to see some fast graphic drivers with gallium direct3d-api support ... just to piss ms off :-)
so1: but opengl3 is probably more important :-)
so1: when it will be releases ...
so1: they delayed it again ...
so1: the spec^
graham: Anybody got an ATI Radeon HD 2600 XT working with this driver under Ubuntu?
egbert: graham: i've got it working on a pro. but the xt shouldn't be a problem. however not on ubuntu.
egbert: so1: the main difference is the atombios stuff. atombios code is a black box. in theory you know how to use it. but we have found several api changes in the tables which are not really reflected in the headers.
egbert: so one really doesn't know if it will be working without looking at the code.
so1: :-/ sounds weird ...
so1: put it currently looks that amd can't keep up revising thir docs with the speed of the development :-)
egbert: the catalyst driver uses it - sure but the driver people have a lot better access to the bios people.
egbert: so1: there are not docs on the atombios api other than the header file which you can find in the sources.
egbert: so1: ati isn't good at documenting stuff. there are register specs. you can download them and see if they are useful.
so1: i hope amd will have time to release information about it when the legal pipleine got a bit more empty :-/
so1: damned! today is my writing mistake day :-P
egbert: ati uses the same specs as we do (except that ours are cleaned from ip and drm issues)
egbert: so1: it's not only the legal pipeline. there just aren't any docs.
egbert: ... beyond the quality of the register specs.
egbert: those docs would have to be written.
so1: omg ... so the whole jokes about that ati didn't know itself what they wre doing was quite right?
egbert: so1: it's not only a joke. it's not even a secret. if you listen around you will notice this pretty quickly.
egbert: so1: it may not be said directly every time but you don't have to read between the lines much.
so1: i'm glad amd bought them, hope the finally make it to clean up this mess
so1: unbelievable ...
egbert: so1: amd is certainly better at documenting stuff.
egbert: but the entire computer graphics market seems to move so fast that noone bothers to do docs.
so1: how could they hire and train new people on writing their cards, when nobody knows what really happens except from personal experience?
egbert: once you are done with them your chip is thing of the past.
egbert: so1: good question. this is probably the reason why the catalyst driver code base is so big.
so1: :-)
so1: nobody has probably the oversight to know what's really necessary, where to share code, which things can be unified ...
egbert: if you wanted to know details about some r2xx chip you'd probably have to dig them up in the driver code.
egbert: so1: yes, that's my impression.
so1: yeah "the source code is the best doc" :-)
so1: don't we love that?
egbert: after a while it becomes a black box.
egbert: i believe that people have their own notes. and maybe these notes are passed on in the group.
so1: maybe in the future, ati people will pull the radeonhd git to see how the card looks like :-)
so1: but i can imagine, the whole speed hacks, benchmark detection things, application specific optimizations just clutter the code base
egbert: oh definitely!
so1: when the product manager says "nvidia is 5% faster on that game, make our driver fatser, too!"
so1: i can imagine that they won't revise the whole codebase :-)
egbert: so1: also i'm not happy to have several drivers doing the same thing. this bit banging isn't easy to get right.
so1: but just for things the game probably doesn't use and remove some unnecessary methods ...
so1: mhh
egbert: there are so many different cards with the same chip and some need special handling. getting them all supported in all drivers is impossible.
so1: hope things get more clear in the future
egbert: i hate to end up in a situation where card a works better with driver x and card b better with driver y (while both cards use the same chipset)
so1: one driver for old cards, one for new, shared exa where it makes sense, atombios where it makes sense ...
egbert: yes, it would be good to share some stuff that can be shared.
so1: the software people always had to fix the bugs the hardware devs were to lazy for :-/
so1: what' the status of libpciaccess?
so1: is it used by radeonhd/radeon?
egbert: thing is: you start with one generation which has a lot in common with the next one which in turn has a lot in common with the second next one but at the end the latest one have nothing in common with the first one any more.
egbert: so1: libpciaccess, yes.
egbert: i added support for it a while ago.
graham: I'm using Xchat, just about to restart X with Ubuntu packaged radeonhd driver to see what error messages I get...
egbert: graham: ok :)
ndim: GNA.
graham: OK, I got these warnings and errors: (WW) RADEONHD(0): Unknown card detected: 0x9588:0x1028:0x2542.
graham: (EE) RADEONHD(0): Cannot map connectors on an unknown card!
graham: (EE) Screen(s) found, but none have a usable configuration.
ndim: graham: http://packages.ubuntu.com/xserver-xorg-video-radeonhd this ancient 0.0.1+git20070918-1ubuntu1 package?
graham: So, I tried adding 0x9588:0x1028:0x2542 to rhd_id.c, by copying the entry for "Sapphire HD 2600 XT", and I got this...
graham: ndim: yep ancient package
graham: I guess I should update from git??
ndim: Then you're about to start re-doing 2 months of hard work.
ndim: Better use git.
Tuju_: ndim: no newer build in koji for f8 than 20071017?
ndim: And file a bug with ubuntu, that this thing is outdated.
ndim: Tuju_: There has nothing changed code-wise.
Tuju_: ndim: ack, that's i needed to know. thanks.
graham: Is it here? -- git://anongit.freedesktop.org/git/xorg/driver/xf86-video-radeonhd
ndim: graham: yupp.
ndim: Tuju_: ARGH.
ndim: Tuju_: No, wait.
ndim: Tuju_: Sorry.
ndim: Tuju_: I misread that as 20071117.
Tuju_: xorg-x11-drv-radeonhd-0.0.2-0.7.20071017git.fc8 is latest
Tuju_: http://koji.fedoraproject.org/koji/packageinfo?packageID=5156
ndim: Tuju_: I'm sorry about that. Use either the F-7 build or the F-8 RPM from my private site for now: http://radeonhd.lauft.net/
ndim: I've been asking rel-eng to let me update the package in F-8, but they have not responded so far.
ndim: The F-7 RPMs from koji should work fine, though.
Tuju_: ndim: do you have bz entry for that?
graham: Well, the newest git does not have my card IDs in it
graham: It has { 0x9588, 0x1002, 0x2542, "ATI Radeon HD 2600XT DDR4", RHD_CARD_FLAG_NONE, DVI_BA10_DVI_AB01 },
graham: But mine is 0x9588:0x1028:0x2542
graham: So I guess I don't have the DDR4 bit perhaps?
egbert: graham: you should not need the card id.
graham: Oh?
egbert: the connector table is pulled from atombios.
graham: Ahah
egbert: only if we see a bad table on a card we 'overrule' it.
graham: So the rhdCards[] table is a kind of blacklist?
egbert: some cards seem to have more connectors in their list than are soldered onto the card. some vendors don't seem to bother to have different bios for every model.
egbert: graham: sort of.
ndim: More like a fix list, which lists the bad boys who need special attention by the teacher.
graham: Thanks
graham: Any pointers for compilation? I want to create a .deb, but can use the .deb from Ubuntu and replace the radeonhd_drv file in it...
ndim: graham: Change the version numbers... uhm... if necessary, build a tarball...
ndim: ...and file a bug against Ubuntu's outdated package.
graham: Yes, will do
egbert: with a .deb we may be able to build packages for ubuntu and debian with the opensuse build system.
egbert: so far just noone spent the time to do .deb files.
graham: Um, this may be OT: my monitor is 1920x1200, the 'vesa' driver only seems to be able to give 1600x1200, the 'ati' driver did not work, and the Ubuntu packaged 'fglrx' driver did not work
graham: So, 'radeonhd' was my best hope
graham: (still is)
ndim: Tuju_: http://koji.fedoraproject.org/koji/taskinfo?taskID=252793
Tuju_: ndim: thanks!
graham: What is the relevance and state of the avivo driver?
libv: graham: things are handled here now, glisse his itch is being actively scratched, so now he went off to scratch other itches :)
libv: this is the thing about X development, there are itches all over the place
Tigerchen: emmes: sent you my logfiles and config
emmes: okey dokey
libv: graham: most are not being scratched at all, could use a lot more scratching, or maybe need scratching in a different, more stability and compatibility focused manner
ndim: contemplates buying some 1680x1050 19" or 22" TFT in the 300EUR class as second screen for this laptop.
Honk: 22" tft for 300€?
Tigerchen: emmes: I'm currently with access to a monitor, so if you need anything more feel free to ask
ndim: Or was it 21?
emmes: Tigerchen: busy with yet another issue, but i'll come to you soon
egbert: emmes, libv: no lunch yet?
libv: ndim: 22" is like 230 atm
Tigerchen: emmes: kk
libv: egbert: not yet
emmes: egbert: ... right... there was something...
emmes: thnx for reminding ;)
egbert: emmes: libv: i'm jsut having mine :)
libv: egbert: mfabian has a meeting with bossman for quarterly corporate paperwork
Honk: ndim: i was wondering which one had a good image quality at that price point
ndim: Tuju_: Proper F8 packages arriving in koji soon, and probably in an updates-testing repo near you a little later.
Tuju_: ack, i already installed that one but didn't restart X yet.
ndim: Well, the binaries should not be different.
ndim: Except for the timestamp.
ndim: :)
graham_: Hi, I just tried the latest git radeonhd, and I got http://www.uk.debian.org/~graham/x/Xorg.log.conn1.nomon
graham_: which has these lines: (EE) RADEONHD(0): RHDLVTMAInit: any other device than an R5xx is still unsupported.
graham_: (WW) RADEONHD(0): DACBSenseCRT: connector type 4 is not supported.
graham_: (EE) RADEONHD(0): Failed to detect a connected monitor
graham_: So I plugged the DVI cable into the other connector, this time farthest from the motherboard, and got this:
graham_: http://www.uk.debian.org/~graham/x/Xorg.log.conn2.white
graham_: ...which looks good, but all the pixels are white. I have seen others report whiteouts too.
egbert: graham_: lvtma on r6xx is actively worked on.
egbert: graham_: you've got this offset problem, too. welcome to the club!
egbert: graham_: everybody is seeing it but us.
egbert: i still need to get frb's bioses to try and chase this down.
egbert: frb seems to have to identical cards behaving differently - this points to differences in the bios.
graham_: The "Atom" BIOS or the PC's
graham_: Can I dump the BIOS and send it to you?
libv: graham_: won't take long anymore
libv: graham_: your pciid is?
graham_: 01:00.0 0300: 1002:9588
egbert: libv: what won't take long any more? lvtma?
libv: graham_: will be working
libv: egbert: yes. looking into rs690 now, as that is different from both r600 and rv6xx
graham_: (WW) RADEONHD(0): Unknown card detected: 0x9588:0x1028:0x2542.
libv: graham_: your chip is already support, just working on rs690 support now
graham_: Cool, many thanks!
libv: err, supported locally :p
libv: so next push i make will fix your problem.
graham_: wow
graham_: shall I poll for git updates, or can you poll me, e.g. email, so I can test for you>
Tigerchen: graham_: on the ml will be a automatic commit-mail
ndim: graham_: And http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-radeonhd has an RSS feed.
graham_: Excellent, have subscribed to ml and added RSS to browser toolbar
libv: graham_: nice :)
emmes: graham_: but note that the offset problem isn't fixed yet.
emmes: so you will get a white screen on the other output as well ;->
graham_: Yep, just tried it, and got a white screen
graham_: But on the first connector, so that's a good thing
graham_: Do you need the X log?
emmes: egbert is working on that, and if we cannot find an easy solution for it, we'll add an option for manually specifying the offset in the next few days.
libv: graham_: at least the modesetting is correct, the framebuffer position is just wrong :p
emmes: that's far from optimal, but better than nothing.
libv: graham_: so progress :p
emmes: ok, I'm going to merge the randr branch into master now
emmes: i think it's sufficiently stable
graham_: Thanks for the code people
libv: graham_: hold your thanks until it finally works properly for you :p
emmes: libv: he's got good chances ;)
libv: yup
graham_: Hehe. Try and get a response like this from a closed-source project.
ndim: BTW... are there any plans for the ACPI handling part?
yojoe: is there a regression with the pixel clock again? I just updated to the latest radeonhd from the buildservice and now my screen is flickering again on my Lenovo Thinkpad T60p (ATI FireGL v5250, M66)
libv: ndim: yes, but first things first
libv: yojoe: ?
yojoe: I know this was fixed in a previous version... I had the radeonhd driver running fine on my Thinkpad... but I don't update too often...
yojoe: now I have to mousepointers again and a flickering screen
libv: yojoe: kay sievers was very happy
yojoe: I did not update the radeonhd driver for some weeks now (maybe 4 weeks... don't know)... so I don't know when the pixel clock problem came back again
libv: yojoe: run with -logverbose and check which dotclock parameters you are setting?
libv: -logverbose 7
libv: yojoe: it shouldn't have come back again
yojoe: run what? Xorg?
libv: yes
libv: yojoe: when did you update the driver?
yojoe: 1 hour ago
libv: did it include my latest fixes which add TMDSB?
libv: ah, so it is not something i pulled there :p
yojoe: no... wait... I remember I tried to update it 2 weeks ago... and there was the flickering... but I didn't had time to look into this deeper and switched to fglrx
yojoe: ok,.... I started Xorg by running# Xorg -logverbose 7from console... what should I look for now?
yojoe: # Xorg -logverbose 7
yojoe: should I look in /var/log/Xorg.0.log now ?
libv: yojoe: yeah, it should be in there
libv: or send me the log
yojoe: ok... I'll send you the whole log via email... what's your address?
libv: radeonhd@opensuse.org :p
yojoe: :)
yojoe: ok... send the email
libv: (II) RADEONHD(0): PLL Calculation: 122000kHz = (((0x6978 / 0x9) * 0xF4) / 0x6)
libv: +(0kHz off)
libv: seems like a very middle of the road value
libv: and you seem to be using the same panel as kay as well
libv: hrm, if you had been here yesterday, i could've verified it
libv: because kay works from home and isn't always in the office
yojoe: well... I don't know if lenovo shiped different panels...
libv: Manufacturer: IBM Model: 2887 Serial#: 0
yojoe: my model is the 8741-C4G
yojoe: I have a wsxga+ panel (1680x1050)
yojoe: if I google for 'lenovo model 2887' it looks like this is a ThinkPad R51.... I have a T60p.... so it is likely that I have a different panel
emmes: egbert: you there?
ndim: Eh. That rotation chameleon tail while waiting for the Javascript to load the package list on the opensuse build server is NICE.
annonygmouse: Hi folks!
annonygmouse: Sorry, but I'm having problems with last radeonhd last version (0.0.3 as phoronix says :)
annonygmouse: Does anyone have a couple of minutes for me?
annonygmouse: Here's the X log with logverbose=7 http://pastebin.com/m4f4a0807
annonygmouse: Symptoms are: X goes up but with blank screen and not able to use keyboard to kill X...
ndim: Eh. That sounds great.
ndim: is glad he has put "test it" before "push out Fedora package" on his TODO list.
annonygmouse: ndim: I'm trying to "revert" the lasts commits on my WC
ndim: annonygmouse: The initial-randr merge?
annonygmouse: stupid to make backup of old working radeonhd driver to /tmp!
annonygmouse: ndim: probably...
annonygmouse: ndim: do you know any easy way to revers my WC changes?
ndim: annonygmouse: Run "git log" to confirm that the last commit was the initial-randr merge.
ndim: annonygmouse: Then just create a branch off the commit before.
ndim: "gitk --all" can help.
annonygmouse: ndim: gitk is really what I needed (had never used git much)
annonygmouse: ndim: I'm working on it, thanks!
ndim: annonygmouse: git branch test-moo ed9065a4288b92d4e3c286071b1a452bb1756a88
ndim: annonygmouse: git checkout test-moo
ndim: annonygmouse: You may want to choose a better branch name...
annonygmouse: ndim: thanks, worked like a charm
annonygmouse: next week I'll try to search the cause (if noone solves it before :)
annonygmouse: thanks!
annonygmouse: bye!
ndim: wonders who in here is the phoronix.com guy.
ndim: Apart from the rhdlogger.
walder: hi ppl
walder: emmes: any news about screens ordering ?
emmes: Read the announcement :)
emmes: it's done, and working
walder: emmes: Wow!
walder: emmes: will test
walder: emmes: ok, semi-works for me
walder: emmes: it really replace screens
walder: emmes: but it does not swap geometry
walder: emmes: only way that I've found to reset geometry is --off, then --auto
emmes: what do you mean with swap geometry?
walder: xrandr --output PANEL_LCD1/LVDS --mode 1400x1050 - does not report any error but does not chnage geometry
emmes: old xrandr?
emmes: so which version of xrandr are you using?
walder: emmes: hm, xrandr ? xrandr-1.2.2
walder: emmes: version from FreeBSD ports
emmes: bugs in xrandr.
emmes: i fixed the upstream, few days ago.
emmes: also few bugs in core randr system (xserver), also fixed upstream.
emmes: but xrandr is the more important one.
emmes: and easy to build
walder: emmes: git magic, I remember
walder: emmes: can you point me to right direction - where it is placed in git ?
walder: git clone git://anongit.freedesktop.org/git/xorg/xrandr
walder: fetch-pack from 'git://anongit.freedesktop.org/git/xorg/xrandr' failed.
emmes: git/xorg/app/xrandr
walder: emmes: 10x
walder: emmes: it not so bad to work on wrong resolution, but screen flicks so that it is not possible to view something
walder: like old CRT displays with wrong clock set
emmes: hmpf.
emmes: hmpf.
walder: emmes: bingo ! now it works
emmes: ;)
emmes: thought so
walder: emmes: thanks a lot
emmes: i dunno why no other driver was hitting these bugs
emmes: walder: was there still any issue with static setup?
frb-away: bork bork bork
walder: emmes: still need to use small trick in gdm:
walder: fgrep xrandr /usr/local/etc/gdm/Init/Default
walder: if [ `/usr/local/bin/xrandr -q | awk '($1 == "VGA_CRT1/DAC_A") { print $2; }'` = "connected" ]; then
walder: /usr/local/bin/xrandr --output PANEL_LCD1/LVDS --mode 1400x1050 --preferred
walder: /usr/local/bin/xrandr --output VGA_CRT1/DAC_A --right-of PANEL_LCD1/LVDS
emmes: the preferred in the monitor section still doesn't work for you?
walder: emmes: yes
emmes: I thought that was fixed upstream in the meantime...
emmes: sighs.
walder: emmes: really ? I do not upgrade Xorg, probably I need
emmes: don't think I should look into that. too busy with other (important ;) stuff
emmes: walder: i'm not 100% sure. I just thought I read something about that in a bug
walder: emmes: ehh, \\
walder: emmes: bug status NEW
emmes: that's normal ;)
walder: emmes: no, I am wrong, just missed bugs, FIXED in 1.4
emmes: hehe
emmes: well, actually 1.4.1, and even then this might not be enough
walder: emmes: quote "really fixed in git, patches nominated for 1.4.1"
walder: https://bugs.freedesktop.org/show_bug.cgi?id=12476
emmes: as i said. nominated. we'll see ;)
walder: emmes: not sure that it will easy to build on FreeBSD
walder: emmes: freebsd port has 11 patches in tree for xorg-server
emmes: you have a working solution right now, i would go with that and wait for 1.4.1 or 1.4.2 or 1.5, whatever works ;)
walder: emmes: ok, thanks
slackern: Goodevening, seeing some odd things with the new randr stuff
walder: emmes: If I'll have some free time - I'll try to build 1.4.1 or apply patches to 1.3
emmes: walder: your choice :)
emmes: slackern: GA
walder: emmes: thanx aga and bb
walder: again
slackern: It's like it's not properly finding the correct values for my monitor at the time being, instead of 1280x1024@75 i get 1280x1024@60 and with GDM it moves the options button to an odd location, the screen is in 1280x1024 but the options button is at the location of a 1024x768 resolution
emmes: the thing with the options button is probably a GDM bug (there were some)
slackern: put up a pastebin here too of the xlog http://paste.ubuntu-nl.org/45388/
emmes: which Xserver version is this?
slackern: emmes, aye could be, i saw the mail in ml also on how to disable it if needed but it's not really a showstopper since everything kind of works anyhow :)
emmes: And also please start X with --logverbose 7 for the log
slackern: alrighty
emmes: You're definitely seeing some bug/regression, so it should be checked who actually is the culprit
slackern: emmes, heres a log with -logverbose 7 if you want to have a peek http://paste.ubuntu-nl.org/45390/
slackern: one nice thing is that it seems to show fonts better now, not as bold as before
libv: slackern: our dpi issue again, no doubt :)
emmes: slackern: sigh. you're using Xorg 1.3.0. So no 1.4.0 I can blame on ;)
slackern: libv, aye, going to post a screenie of the odd locations of the button in gdm and also in gnome itself, windows that used to be maximized at fullscreen open with the bottom border at the same location as the options button in gdm
libv: slackern: don't worry, i don't have time for that right now anyway :)
slackern: heres a sample http://pici.se/159194/
libv: slackern: for now, use randr, and try not to step into the pitfalls :p
slackern: just wanted to show you so you know what im talking about :)
slackern: Haven't had so much time in linux lately but i'll keep updating the driver and report what i see :)
libv: ok, thanks :)
emmes: ah. so this window is fullscreen? ;)
slackern: emmes, it was in fullscreen before the driver update and it defaulted to this size now, i can still maximize it so it fits my screen now
emmes: so, the only thing is that the default isn't correct? that's certainly not X's fault ;)
slackern: the bottom gnome bar was also at that location but when i touched it it flew down to the bottom :)
slackern: and my cat is in heat and purring and making noises so im going crazy :P
emmes: i don't have a clue about gnome. well, i once fixed the resapplet for one issue, and that showed me that they hadn't understood the randr model at all, unfortunately. there are several race conditions in the code.
slackern: oh well it'll probably sort itself out in due time :)
libv: emmes: and you wanted to go home early today? *eyes the ml*
slackern: rofl
slackern: anyhow thanks for you devotion to these drivers guys and girls and keep up the good work :)
slackern: If i was rich or well atleast had some money to go around i would buy you a beerkeg
daniels: emmes: filing bug reports is always good
slackern: hah just noticed something, i can't maximize gedit or gnome-terminal at all to fit my screen i was wrong with what i said before
slackern: so the size of gedit is the maximum i can maximize windows too :)
slackern: doh and if i drag the bottom border of those maximized windows they pop up and down between fullscreen and almost fullscreen ^^
Tigerchen: can i set verbosity somewhere in xorg.conf?
slackern: I guess this is the max resolution the applications see "(II) RADEONHD(0): rhdRROutputModeValid: 1280x800 -> Status 0"
libv: daniels: fixing them is even better i guess ;)
daniels: hard to fix the unknown
emmes: slackern: it's the crt, right?
emmes: this is strange, the edid block apparently says that the monitor *preferres* 60Hz...
libv: emmes: not that abnormal. maybe it is more bandwidth constrained than dpi or size constrained
libv: on the other hand, edid could be off
emmes: if you check the xrandr output you will see a '+' behind this mode. you can of course set the other mode during runtime, or add it as a preferred mode in the config. dunno how you set a specific mode with refresh values in xorg.conf, but it has to be possible. maybe only by mode id (hexvalue, find it out with xrandr --verbose).
Honk: hum
emmes: sh*t
emmes: slackern is off..
Honk: my crt goes into energy saving mode when changing resolution or refresh rate with xrandr
emmes: daniels: sorry to say, but the way resapplet uses RandR is wrong from the beginning. difficult to create a bug report. the docs clearly show that you have to verify date stamps, and if they differ you cannot use the old data any longer, and resapplet does that.
emmes: Honk: best provide logfiles created with --logverbose 7 and your xorg.conf to the mailing list.
emmes: daniels: s/does/doesn't/
emmes: daniels: err, forget that. it was already in the first place
Honk: i wonder if that'd be useful. they said only to file bugreports with xrandr if one has some updated xrandr and xorg version :]
beerockxs: Hi, just a short question about randr. Should I be able to have both my display work, one at 1280x1024 and the other at 1680x1050?
libv: hrm yojoe also ran off, i should point him to our bugzilla as someone here has the same issue as well it seems
ndim: uploads man page patches.
emmes: ndim: cool
ndim: emmes: http://radeonhd.lauft.net/patches/ndim-doc/
beerockxs: anyone?
emmes: beerockxs: yes
emmes: beerockxs: http://wiki.x.org/wiki/radeonhd
emmes: ndim: yet another branch? ;)
beerockxs: emmes: so it looks like i stumbled upon a bug
emmes: beerockxs: possibly :P
ndim: emmes: That's the nice thing about git. :)
beerockxs: My virtual size in xorg.conf is set to Virtual 2960 1050
ndim: xf86-video-radeonhd]$ git branch | wc -l
ndim: 46
beerockxs: that should be right for 1280x1024 + 1680x1050, right?
ndim: beerockxs: I guess so.
emmes: ndim: well, I've added your ndim-git-version branch to my config, so it automatically pulls them, but that doesn't work with you changing branches all the time :P
beerockxs: both at 1280x1024 work just fine, but when I set the mode for the monitor that can do the 1680x1050 to that, the screen of the 1280x1024 monitor goes black
beerockxs: brb
emmes: ndim: i don't understand git, again
emmes: git-fetch ndim ndim-doc
emmes: works
emmes: but i won't find ndim-doc in gitk...
beerockxs: ah, it works ok when i first set resolution, and then do the --left-of thing
beerockxs: yay
emmes: beerockxs: probably bugs in xrandr. you should fetch the newest git bits
emmes: ok, no
emmes: that thing ;)
emmes: yes, i think that is still broken
beerockxs: ok, now to set it up as default
emmes: you should use RightOf not LeftOf
emmes: bug in xserver, fixed upstream, but only yesterday
emmes: xrandr --left-of is ok already
beerockxs: emmes: it works ok when i do the right-of first?
emmes: beerockxs: i mean the static config. use RightOf in the other monitor section, not LeftOf
beerockxs: emmes: oh, ok
emmes: only need to specify this in one of the monitors
beerockxs: can i specify where the "dead" area is?
emmes: ndim: git-cat-file -t 71f312cf0 shows me that I *have* fetched it... still, aparently there is no branch associated with that.
emmes: beerockxs: not that i know.
emmes: well, wrong.
emmes: you can use "Position" instead of "RightOf"
emmes: that has to go in all monitor sections.
emmes: and if you calculate the position (x,y) carefully enough, you can do that.
beerockxs: ah
beerockxs: brb
beerockxs: how do i set the resolution in the static setup?
ndim: emmes: Strange. I have just checked that my public repo has all the stuff... and it has it.
emmes: beerockxs: should be automatic. if it isn't, there's an option 'Preferred'. should be in man 5 xorg.conf
emmes: ndim: if you do it right, it works :P
beerockxs: emmes: It sets both screens to 1280x1024 by default
ndim: Ah. The ancient wisdom.
libv: beerockxs: static setup being the norandr code, right?
emmes: still, this is a bit flacky with git. i'd like to download a branch easier than that, just for evaluation and cherry picking.
beerockxs: libv: Uh, i think it's randr, because the randr announcement mail has the info how to set it up statically
libv: ah, ok. nothing to do with me then :p#
ndim: emmes: "git pull http://radeonhd.lauft.net/xf86-video-radeonhd.git/ ndim-doc" does not look too difficult to me?
ndim: Hm.... OK, that merges into the current branch automatically.
emmes: beerockxs: issue is, it works here ;) still, this seems to be flacky upstream.
emmes: ndim: git-fetch ndim refs/heads/ndim-doc:refs/remotes/ndim/ndim-doc ... is a bit lengthy
emmes: (with ndim already set in the config)
emmes: or can i nuke this refs/heads and refs/remotes stuff?
ndim: [remote "origin"] url = git://anongit.freedesktop.org/git/xorg/driver/xf86-video-radeonhd fetch = +refs/heads/*:refs/remotes/origin/*
ndim: Meh.
ndim: If you adapt that for my repo?
ndim: Hmm. Gotta try that.
emmes: yep, but that gets everything :P
ndim: Right.
ndim: Which is bad.
emmes: had that before ;)
emmes: takes ages for your repro :P
ndim: Just like me pushing everything to that public repo.
beuss: do you have any information about possible 3D support
beuss: or 3D specs release
emmes: ndim: for the common knowledge: that is enough: git-fetch ndim ndim-doc:remotes/ndim/ndim-doc
emmes: beuss: nope
emmes: FAQ
emmes: ndim: I'm against 71f312cf0
emmes: you have done more than the manpage. build system etc.
ndim: What?
ndim: Not in ndim-doc.
emmes: ah i see
emmes: this is ONLY about the man page
emmes: ok
ndim: ndim-doc is only about docs.
ndim: As the name suggests :)
beuss: by the way, I'm not an expert so what would you say about 2D driver state ? is it stable ? are many features missing ? (I'm using it and the only thing I miss is 3D support) Is there a roadmap available
frb-work: on the machines it works on, it seems to be stable
ndim: I'd guess the RandR/0.0.3 might break a few machines which worked before.
emmes: ndim: pushed
ndim: emmes: Great, thanks.
emmes: mostly modesetting behaves differently.
emmes: because RandR does things differently than we are
beuss: evry time I make a ./configure, I've to manually add #define _CONFIG_H 1 to config.h to avoid rhd.h to throw a #error, is there something to do to avoir this ?
emmes: errr....
emmes: ndim: I think this is something where you could shine ;)
emmes: I'm off for today, my stomach is mumbling strange words to me...
ndim: Uhm. That is where egbert hacked some strange stuff I have never understood, but have accepted that his state-of-the-art-1999-automake needs it that way...
emmes: rotfl
beuss: it doesn't happen to anyone else ?
ndim: beuss: It has worked for me so far.
beuss: ndim: without doing anything ?
ndim: beuss: automake --version; autoconf --version
beuss: ndim: 1.9.6/2.61
beuss: DEbian testing
ndim: that should definitively work.
beuss: I don't understand
ndim: beuss: Running "autoreconf -vis" show any strange things?
beuss: gulp
beuss: I just launched autogen again and it seems to be good
ndim: Great.
ndim: :)
beuss: :)
beuss: sorry for the disturb
ndim: autogen must die.
ndim: And the maintainer-mode stuff.
beuss: I don't remember me doing anything special...
beuss: Anyway this works out of the box now, and this is great :D
beuss: thanks for your hard work
emmes: beuss: welcome to autohell
emmes: is still not off...
ndim: emmes: Shooo!
beuss: emmes: yep, I experienced the same funny things on a project I work for
ndim: In my experience, if you rely on approximately contemporary versions, they work quite well.
beuss: ndim: yes, once your brain has surrender
ndim: beuss: No, even before you can write 200 line m4 macros in one go without having to test them :)
ndim: An automake/autoconf building on a sh with shell functions could be really awesome.
PrimusPilus: I am running fedora 8, I used git to grab the newest ver, built it, ran make install, but X says it cant find the driver, does it need to go in some special place for fedora?
ndim: PrimusPilus: You've come to the right place.
PrimusPilus: yay
ndim: <- fedora radeonhd maintainer :-)
PrimusPilus: oh sweet
PrimusPilus: so what did I do wrong?
PrimusPilus: some prefix cmd or something
ndim: Probably.
ndim: HOWEVER.
PrimusPilus: I just did ./autogen.sh with no options
ndim: You can just tell X to look for the driver in another place.
PrimusPilus: ah
ndim: However2... you'll have to change the SELinux context first.
PrimusPilus: ./usr/local/lib/xorg/modules/drivers/radeonhd_drv.so
PrimusPilus: looks like its in there
PrimusPilus: ah ok, how do I do that
ndim: chcon --reference /usr/lib/xorg/modules/drivers/radeonhd_drv.so /usr/local/lib/xorg/modules/drivers/radeonhd_drv.so
ndim: chcon --reference /usr/{,local/}lib/xorg/modules/drivers/radeonhd_drv.so
ndim: The latter is shorter.
PrimusPilus: done
PrimusPilus: used the firstone, had to add local to the path though
PrimusPilus: but it ran without error
ndim: xorg.conf "Files" section. ModulePath "path"
ndim: Should contain both then.
ndim: PrimusPilus: Uhm.
ndim: Argh.
ndim: chcon --reference /usr/lib/xorg/modules/drivers/radeon_drv.so /usr/local/lib/xorg/modules/drivers/radeonhd_drv.so
ndim: YOu just need an existing driver to copy the context from.
alessandro_: airlied: around?
ndim: PrimusPilus: YOu could also try http://radeonhd.lauft.net/Fedora-RPMs/xorg-x11-drv-radeonhd-0.0.3-0.0.20071121git/fedora-8-i386/
alessandro_: airlied: just wanted to say, the recent commits didnt help
PrimusPilus: oh
PrimusPilus: I remoed the old radeonhd driver
ndim: I dare not push that to Fedora yet, as I have to determine dependencies on xrandr and the X server first.
ndim: PrimusPilus: Download the old RPM and put it in a known place so that you have it handy if things go wrong.
ndim: And I guess they will with 0.0.3/xrandr.
airlied: alessandro_: bummer.. they worked on some laptops.. I think Alex is trying to find out what the difference waas..
PrimusPilus: whats the best way to restart gdm?
alessandro_: airlied: its weird because i really get exactly the same output, could be related to something else?*
ndim: telinit 3?
alessandro_: PrimusPilus: /etc/init.d/gdm restart?
ndim: Then telinit 5...
PrimusPilus: ok sweet, I got display
ndim: alessandro_: Fedora continues the RH tradition of starting xdm/kdm/gdm from inittab, not via sysvinit.
PrimusPilus: now the real problem, I have tri-head, two x1300 for left and right, and one x1950 for the center, the 1950 displays OK, but the left and right are garbled, I can see my background color on them etc, but its all distorted
alessandro_: ndim: sorry so they differ to any other Dist ive been using :-)
rmh3093: is there anything special I need to get radeonhd working.... I have an x1600 mobility, xorg1.4, and the driver segfaults when I try to start X
libv: PrimusPilus: describe garbled
PrimusPilus: mmm, its hard to explain
PrimusPilus: like lots of veritical rows of green and white squares
ndim: rmh3093: The randr merge contains many changes. You could try Option "noRandR".
PrimusPilus: intermixed with vertical rows of blue (my desktop color) I cant read anything on it
PrimusPilus: kinda like when you got a funky refresh goin on
PrimusPilus: sept its not moving, just static
libv: how wide?
ndim: PrimusPilus: That is the new art installation that comes with radeonhd free of charge.
PrimusPilus: all three monitors are 19" wide screen
libv: are the rows?
PrimusPilus: half an inch
PrimusPilus: per row
PrimusPilus: in groups of 2, then 3, then 2 etc
PrimusPilus: I can see my mouse move around too
PrimusPilus: and menus, but they are all funky
libv: cursor is also garbled?
ndim: I'll be off for a bit, rebooting and testing xrandr. :)
PrimusPilus: only on the 1300 cards, like I said the center 1950 is ok, yes cursor is messed too
rmh3093: ndim, thanks I will try that in a few
PrimusPilus: wait
ndim: rmh3093: cf. radeonhd(4)
PrimusPilus: cursor is OK
PrimusPilus: its just everything else
libv: PrimusPilus: so it is the graph engine then
libv: right
alessandro_: libv: does radeonhd currently supports xrandr with resolutions higher than 1400x1050
PrimusPilus: the res should be 1680x1050
PrimusPilus: they are setup identical to the 1950 in the xorg.conf
libv: alessandro_: there is no hardware limitation, except what is imposed by your monitor
libv: PrimusPilus: right, but the X1300 are not the VGA primary devices
PrimusPilus: yeah
alessandro_: libv: well i got 1400x1050 on my laptop, and 1920x1200 on my monitor on VGA
PrimusPilus: any ideas on how to fix that?
alessandro_: but its only detecting up to 1400x1050 on the external
PrimusPilus: also I cant drag windows from one screen to the other, however my mouse alone will go
libv: PrimusPilus: i know which part of the chip to look, and i know how i could go about testing this, but could you subscribe to the mailinglist and give a short rehash of your problem there and post a copy of one of the logs of the X1300s?
PrimusPilus: mm yeah, how do I access the mailing list?
libv: PrimusPilus: /topic has a pointer to the wiki, which has that information :)
PrimusPilus: k
libv: also, the README has that information as well :)
PrimusPilus: thanks
beerockxs: emmes: PreferredMode in xorg.conf does not set that mode :(
beerockxs: Xorg.0.log says this: (II) RADEONHD(0): Output DVI-I_DFP1_CRT2/TMDS_A using initial mode 1280x1024
beerockxs: although in xorg.conf I have Option "PreferredMode" "1680x1050" in the monitor section for that output
libv: PrimusPilus: it might be next week before i get to this issue though, but it will stay up in my mailbox right in my face
rmh3093: ndim, option norandr got me into X
rmh3093: ndim, would that be a userland issue or a radeonhd issue
PrimusPilus: is there a list of device options somewhere?
beerockxs: anyone have an idea how to get randr to set the initial mode correctly?
frb-work: libv: right after you make my card work right ?
frb-work: :)
libv: frb-work: egbert is working on the framebuffer issue
PrimusPilus: in the meantime, is my only other driver option the fglrx one?
PrimusPilus: for 1300/1950 cards
airlied: PrimusPilus: you could try the atombios-support branch of the xorg ati driver..
airlied: PrimusPilus: but I'm not sure with multiple cards it'll do any better.
PrimusPilus: ah
PrimusPilus: bummer
PrimusPilus: once your used to dual/tri head, its hard to use just one :(
PrimusPilus: for some reason I am thinking the radeonhd driver is telling the 1300 to use the tv out settings or something...
libv: PrimusPilus: nope, graph not set up correctly
PrimusPilus: ah
rmh3093: is there anything I can do to help make radeonhd not crash on my box when randr support is enabled?
rmh3093: do you guys need backtraces or something
rmh3093: or is this just a chan of users with no developers
beerockxs: usually there are lots of devs here
libv: rmh3093: emmes will look into things in the morning :)
libv: PrimusPilus: we have some idea over which bits will actually be causing this
libv: PrimusPilus: please mail us on the mailing list
PrimusPilus: still havent setup my email client, my main PC isent setup atm, due to the vid thing
PrimusPilus: mmm
libv: console clients rock for such a thing :)
PrimusPilus: subscribing now
PrimusPilus: what files you want? Xorg.log I assume?
libv: yeah, i think i or egbert will conjure up a patch in the morning for you to test
libv: for now though, for us, it is getting too late, it's 23.30 here and i am still at the office
PrimusPilus: right
PrimusPilus: sending in a min
libv: PrimusPilus: thanks :)
PrimusPilus: ok, just sent it off
PrimusPilus: also after a min or so those monitors go into power saving
PrimusPilus: but I assume thats normal
libv: PrimusPilus: seems rather quick
libv: PrimusPilus: what if you disable dpms through xset?
PrimusPilus: I am not sure if its a min, just guessing, I havent actually time it
PrimusPilus: less then 10 mins though
PrimusPilus: would disabling it via xset be the same as commenting out the dmps lines in my xorg.conf?
opera-118: how do I know if conntest detects (more or less correctly) both my monitors? its output is, well, a bit cryptic..
libv: PrimusPilus: not really, dpms is on per default, and iirc it cannot be disabled anymore
libv: some option parsing trouble in the server
libv: opera-118: depends on the outputs reported
opera-118: libv: http://pastebin.ca/793073
opera-118: I've got two VGA monitors, each on DVI-VGA adapters to the card.
libv: opera-118: then both DACs should show up
libv: opera-118: and they do :)
libv: opera-118: only one DDC though... weird
libv: opera-118: the driver should be perfectly happy with that
libv: opera-118: why are you asking btw?
opera-118: i'm thinking of trying the driver, again. no real success last time
opera-118: one of my monitors doesn't report EDID :/
libv: opera-118: driver should be happy
opera-118: and, if I can find a way to see, using conntest, if radeonhd finds my monitors right, I won't need to test the driver..
libv: opera-118: what happened last time, and define last time
opera-118: ok, cool.
opera-118: heh, that was a month ago, perhaps more.. perhaps two actually
opera-118: well, I need dual head, that's why
libv: opera-118: we don't sit still :)
opera-118: and my monitors have different resolution etc ;)
libv: ah, if the new randr stuff already works, you can have two seperate modes set up already
libv: already works for you that is
libv: fresh code just pushed into master :)
opera-118: oh yeah, that's kindof a need ;)
opera-118: cool... gotta wait for a torrent tho.. gotta watch heroes before bed :P
opera-118: and yeah, another thing. do I need fglrx do load radeonhd, or is it completely standalone now?
libv: ?
opera-118: hmm, or was that avivo which needed...
opera-118: nevr mind
libv: we have always been very standalone
opera-118: splendid
libv: in fact, fglrx tends to set up some things and doesn't restore properly, and we sometimes still fall over those bits
libv: need to go and test and reproduce though
opera-118: oh.. don't tell me I need to reboot! stupid fglrx... stupid ati...
libv: try and find out
opera-118: oh how I love that ;)
libv: opera-118: if it breaks, i need to remember this pciid
opera-118: 01:00:0?
libv: hrm, agp device?
opera-118: oh... crap i'm stupid...
opera-118: yes.
opera-118: uh no, pci-e
libv: ok... anyway, might be fun to find out on one of our 1650s
opera-118: but you mean, if it breaks to load after fglrx ha been unloaded, I should report this, and my pciid to you?
libv: just state this in this channel, so i have at least a datapoint for trying to reproduce this
opera-118: ok
libv: anyway, almost 0.00, and still in the office, i'm heading for my apartment.
libv: good night
opera-118: do I need to "make install" or can I copy the .so? I'm afraid you guys will (no offense) pollute my /usr ;) or won't you?
opera-118: you german?
libv: work for suse in nurnberg, but i am from .be originally
opera-118: it's zero aclock here too, a few thousand kilometers north of you
libv: just copy the so
libv: if you don't care about package management
opera-118: super.. well, guten nacht!
libv: now that i am using something rpm based, and i seem to severely dislike the tools there are to replace apt, i just copy myself too :p
libv: ah, se
libv: it's been darker there for much longer already :)
opera-118: yeah, since about 1600
libv: night
opera-118: nite
rmh3093: libv, i emerged git randrproto and libXrandr aswell
rmh3093: didn help anything though
kereoz: hi there
ndim: Hmm. I get a screen with randr, but the switching back to the text console is still borked.
ndim: git-bisect time, I guess. But not tonight.
ndim: suspend-to-ram and resume-from-ram work.
ndim: Nice. Now, if I had a working external monitor... (does anybody need a non-functional NEC MultiSync 5FG 17" CRT from 1991?)
rmh3093: this is probably a stupid question, but is there any way to change the clock speed on these cards like there is with the oss ati driver and fglrx
khorben: rmh3093: I suppose the answer to your question is "not yet"
rmh3093: i figured as much
rmh3093: no biggie
khorben: it probably won't be useful until some sort of 3d support is done