so1: hi ..
so1: i have a talk today ... what chance do i have that it will work when i plug my lpatop with an ati mobility x1400 to a beamer?
so1: do i need to configure something?
so1: or do i need a tool to set it up somehow?
so1: or will radeonhd just recognize it?
so1: someone?!
yangman: so1: have a look at the website listed in the topic
yangman: so1: it's difficult to say what kind of sucess you'll have
so1: yangman: are you online?
so1: so bascially, is there any difference between an internal display and a beamer?
so1: or are they just two devices for which either the driver has/gets useful data and can use it or can't get/doesn't know anything and can't use it?
so1: i guess everyone is sleeping at this time? :-)
egbert: so1: no. people are awake.
egbert: so1: there is a difference between an internal display and a beamer, yes.
so1: :-)
so1: so the driver has to care which device type he cenonnects to?
so1: how does that work?
egbert: when you plug in the beamer randr should find out that and where a new device is connected.
so1: i always wondered why tft are quite easy getting to work but beamers are hard ... i always thought bcause beamer sales are not as high as tft sales so no one had really sepnt time on it ...
egbert: so1: but we are still seeing bugs in randr 1.2 (on the server side) so there is a finite chance that it's not doing what you expect.
so1: but i learned something :-)
egbert: beamers often don't supply ddc.
egbert: because of cabling issues, kvm's etc.
so1: egbert: what about these keys on laptops which toggle between external and internal display, do they use a different technique or is that operating system-defined?
emmes: so1: panels often don't work right either :P
so1: emmes: yes i know :-)
egbert: so1: those keys often (but not always) generate an acpi event.
egbert: but this is not handeled right, yet.
so1: i have a 22" 1680*1050 panel here too, first it was a pita ... but then i decided to delete my xorg.conf and start from scratch, now it works without configuration ...
egbert: better you use xrandr app.
so1: ah ok
emmes: so1: and read the wiki about 'virtual'
so1: so basically when i have a driver which, say supports 2d, it does matter if the display device is an internal display, a external tft or a beamer, because beamer give less data than other devices?
emmes: so1: depends on the projector, yes (beamer is german english only ;)
so1: so if i had all necessary data available, i could get it working, but automatic configuartion is somewhat limited?
so1: emmes: ouch ...
so1: thanks!
emmes: standard false friend ;)
so1: always glad people understand _and_ correct me!
emmes: most americans will understand beamer as well (because they are used to the germans ;)
so1: emmes: and i always laughed about the people with their handy :-)
emmes: naja, ich sollte es verstehen :-P
so1: ^^
egbert: emmes: this is because there are so many germans on irc. (especially on this channel)
emmes: yep, and pullover, talkmaster, etc.
egbert: handy, inline skates ...
so1: that is one thing i think is quite funny, when it comes to opensource german- and frenchspeaking people are overrepresentated ....
egbert: so1: this used to be very different several years ago.
so1: americans are strong, too but they have 300 millions of people there
so1: egbert: really?
so1: we just have approx 140 millions
egbert: yeah, but this is really long ago. going back 10 years.
so1: egbert: what was then?
ilm: german people and the like just make more noise :|
egbert: probably the accessibility to internet.
emmes: ilm: you don't really think that, do you?
so1: egbert: omg ... germany is a development country regarding internet access :-P
ilm: emmes, what if i do ? :P
egbert: so1: tell me! i only had access because i was at university back in these days.
so1: ilm: i would be intereted in that too
emmes: ilm: then i consider you mistaken ;)
so1: ah ok
so1: egbert: so the most were americans then?
ilm: just joking around, but now it's not fun anymore :-)
egbert: so1: that was my impression. yes.
so1: ah ok
emmes: ilm: sorry, should have played along |)
ilm: np
egbert: emmes always gets so aroused.
emmes: lalala
egbert: :p
so1: "xrandr" on nooo no gui ...
so1: ^^
emmes: egbert: so mem offset was just accessing R6XX_MC_VM_FB_LOCATION the right way?
so1: that's funny
emmes: i don't understand the R6XX_MC_VM_MISC_OFFSET thing yet...
so1: maybe someone can help me interpret my tft data? :-P
so1: http://ubuntuusers.de/paste/18789/
so1: so at the moment 50hz are selected, but i could have 51 hz too?
emmes: radeonhd? this looks a bit like nvidia :-P
so1: yes, yes ... i just tried it on my main pc
emmes: nvidia doesn't support randr 1.2 yet
so1: ah ok
emmes: thus they have to emulate different setups - and they use the refresh rate for numbering them
emmes: this is a bad hack (tm), and described in the readme
so1: emmes: how did you know that i have a nvidia here?
emmes: because that is the only driver that is using this scheme ;)
emmes: and it is *too* obvious :-P
so1: so it could just be, that 49.9hz and 50.1 are available and they just rounded them?
so1: ah ok
emmes: no, the refresh rates have *nothing* to do with the actual refresh rates
emmes: e.g. 66Hz could be on VGA, 67 on DVI, 68 on VGA with 75Hz, etc. :-P
so1: http://ubuntuusers.de/paste/18790/
so1: ouch ok :-)
so1: ok, what's the thing above? :-P
emmes: looks good, except for the 0mm x 0mm ;)
so1: ah ok
so1: wait ... about the nvidia thing ....
so1: oouuuch ...
so1: how stupid is that?
so1: IF they use numbers which look like hz, why the heck do they use a .0 behind it?
so1: that's absolutely confusing ...
so1: maybe i should try nouveau
so1: about the radeonhd one:
emmes: so1: the .0 comes from xrandr - this is a float
so1: so it basically says panel/lvds (my internal panel) is connected (of course) and running on a certain resolution, and vga_1/dac_a is my connection to an external display which is not connected?
so1: and the vt-out is disabled too
so1: emmes: ok ...
so1: da hier soviele deutsche rumrennen, mal die frage: was haltet ihr von der "stromberg"-verarsche "obersalzberg"? gute comedy oder reine geschmacklosigkeit?
emmes: kenn ich nett -> kein kommentar :P
Tigerchen: mal youtube fragen
emmes: so1: panel/lvds is unknown connection - probably because it doesn't have ddc
Tigerchen: lol
so1: Tigerchen: gibts teil 1 bis 3 ... halt was für absolute stromberg-fans ... weil eben die kompletten characktere quasi kopiert sind ... gestik, mimik, ausdruckseies etc ...
so1: ausdrucksweise
so1: emmes: ah ok
so1: as long as it works i won't complain
so1: :-)
Tigerchen: so1: ich kenn zwar stromberg net so gut, aber hitler-verarschen find ich meistens cool, hitlers helfer von switch war auch immer cool
so1: :-)
so1: meine lieblingsstelle: "sie haben erika mitgenommen" er: "als was denn? panzersperre in ostpreußen?"
egbert: emmes: there are two offsets. the misc_offset name was created by me. i didn't know what to use instead of misc. it's a placeholder.
emmes: sure
emmes: so can you actually set the apperture now? or just detect it?
egbert: emmes: i can set it :)
egbert: emmes: one register wasn't documented of course.
emmes: egbert: as always :P
so1: ah ,,,
so1: did you get any new docs?
so1: or has ati yet figure out what their cards do?
so1: :-)
so1: btw ... the kernel has some sort of "own 2d driver" is that correct?
egbert: dli: are you around?
ndim: WRT the stdint.h types, it is a pity we cannot just use the AC_TYPE_INT32_T series of macros.
sonne: emmes, any news on randr?
so1: btw ... did xserver 1.4.1 get released yet?
Zhenech: no
Zhenech: but already introduced new bugs :(
emmes: sonne: working on it. Fixup gets a broken mode (HSync = 7.10188504e-34) and I don't know yet why
sonne: emmes, thanks
emmes: name is also NULL...
ilm: hmm,
ilm: my ebuild doesnt work anymore. aclocal complains about configure.in
ilm: ow nm, repositry has changed or smth ?
ilm: fatal: Not a git repository: 'xf86-video-radeonhd'
libv: Zhenech: pfff
Zhenech: libv: eeh, when my browser shows fonts with the upper half of the letters 1pixel off to the right it is kinda annoying (no. not with radeonhd)
libv: Zhenech: this is probably an acceleration issue with the driver you are using there
libv: Zhenech: try to reproduce it with a driver like vesa
libv: or disable EXA or XAA in your config
Zhenech: vesa testing is already on my todo
libv: ok :)
Zhenech: working on some debian stuff atm
emmes: sonne: i've fixed a MAJOR bug. actually, this was broken in the xserver, but i also have a quirk for that in the latest git
emmes: i haven't tested it much, but it is actually astonishing, that it worked *at* *all* before...
emmes: now i cannot reproduce the --auto issue any longer, and the screen size is printed correctly :)
emmes: sonne: so please try, and tell me the outcome
sonne: emmes, but I just should update radeonhd I hope
sonne: anyway brb
Zhenech: emmes: "--auto issue"?
emmes: Zhenech: if you disabled the panel and tried to reactivate with --auto, it just bailed
emmes: and actually, the second screen went black as well...
Zhenech: ah :)
Zhenech: saw this one last week
emmes: it perfectly makes sense that this bug was responsible for that, and more.
Zhenech: will test at saturday
sonne: emmes, yes --auto seems to work now (did not manage to create a black display yet)
sonne: howerver I lost the additional resolutions for my external display?
sonne: and I cannot change resolutions
emmes: hm
emmes: I can here
sonne: i.e. xrandr --output DVI-I_1/TMDS_A --size 640x480 does nothing
emmes: hm
sonne: and I only have 1280x800 and downwards in the external display's supported resolutions
emmes: sonne: I guess, it's once again time for a logfile ;)
sonne: I remember that on friday the other resolutions were there
sonne: only the logfile?
emmes: xrandr -q --verbose would be great
sonne: ahh and this time it does not matter if I start X with the monitor connected or not
emmes: so far, nothing else.
sonne: emmes, the files are here: http://nn7.de/debugging/Xorg.0.log http://nn7.de/debugging/xrandr.txt
emmes: WTF?
sonne: emmes, yes?
emmes: your monitor is apparently not detected any more...
sonne: hmmhh... at least the driver knows that it is connected...
emmes: sonne: can you retry with --logverbose 9?
sonne: err strange that should have been logverbose 9
sonne: ohh no was 7 only
emmes: yes, you don't want 9 typically
emmes: (too much noise with DDC)
emmes: but as DDC isn't working -> ;)
Tuju_: hi, if lshw says "Radeon R250 [Mobility FireGL 9000]" - what driver should i get for it?
emmes: the radeon driver.
emmes: this is an older chip
Tuju_: I'm looking for ati proprietary fglrx
emmes: isn't supported any longer
Tuju_: emmes: are you sure?
sonne: OK brb
emmes: pretty much
emmes: everything
libv: Tuju_: please go to #radeon
emmes: there you go
Tuju_: libv: ack, thanks
emmes: sonne: BTW - you are restarting your current X session for each test?
sonne: emmes, sure, new log at same url
emmes: you know that you can start a second Xserver (and xterm) with 'X :1 & sleep 1; DISPLAY=:1 xterm' ?
emmes: (log is Xorg.1.log in that case, of course)
sonne: yes ...
emmes: egbert: have you changed anything WRT DDC lately?
sonne: now wonders why I did it differently
emmes: egbert: http://nn7.de/debugging/Xorg.0.log
egbert: emmes: ?
emmes: egbert: apparently it doesn't detect the monitor on TMDS_A any longer
emmes: sonne: still xrandr --output DVI-I_1/TMDS_A --mode 640x480 should work
sonne: emmes... it doesn't
emmes: i read so :-]
sonne: emmes, should I switch to some non-mirror mode to do so?
sonne: I mean something like leftof etc?
emmes: nope, no difference there
emmes: this is reflected on a higher level
sonne: emmes, I am clueless... if you get an idea what I could try just say so..
emmes: sonne: i just noticed that you still have 0x0mm...
emmes: this is *weird*
emmes: *sigh* seems that there are some more unitialized data structures lying around...
egbert: emmes: i have not changed anything in the ddc code lately. what version has worked last?
emmes: sonne: you remember?
sonne: emmes, I can of course go back to some older git version to verify things
emmes: if you could git-bisect the checkin, that would be awesome. I currently have no idea who could be the culprit...
sonne: hmmhh I wish I knew which version was the last one to detect the resolution
sonne: (cannot find any working one so far)
sonne: emmes, do you know whether this channel is logged? I would want to figure out which version / at which time worked
emmes: phorenix (sp?) logs this channel, AFAIR
libv: phoronix
libv: it's at www.radeonhd.log
libv: err
libv: org
libv: pff
emmes: freud :)
sonne: *argh* not time stamps
emmes: i could check my personal log, do you remember what you said when it worked?
libv: sonne: yeah, timestamps would be nice
sonne: emmes, no
sonne: my brain is empty
emmes: do you remember when?
sonne: emmes, ahh, the other emails I sent you: friday 6:34
sonne: the xorg.0.log there has the 1680x1050 line in there
emmes: mactel-ml?
emmes: or bugreports@
sonne: bugreports@
sonne: subject macbook pro vs AL20xx
emmes: commit 6895da05
emmes: so 'git-checkout 6895da05' and verify that it works - then git-bisect good; git-bisect bad master
sonne: emmes, does not work anymore
emmes: way cool
sonne: same few resolutions in xrandr
emmes: did you change anything else? new xserver?
rmh3093: libv, now that there is docs for the r400 and r500's is there any change of getting the radeonfb driver updated to work with these cards?
sonne: while I do stay debian-sid-up-to-date I am quite sure there was no new X server packages released in the last 3 days
emmes: hm.
sonne: can I somehow from the log figure out which git revision of radeonhd I am using?
sonne: (II) RADEONHD: version 0.0.3, built from git branch , commit 6895da05 with error: error running 'git-symbolic-ref HEAD'
sonne: so yes :)
emmes: only thing that *could* change something sounds quite windows-like: shut down computer, switch off both computer and monitor, and reastart clean
emmes: ndim: something for you, apparently git-symbolic-ref fails ;)
sonne: OK, doing
sonne: brb
sonne: emmes, same thing after the shutdown / restart
sonne: *err*
emmes: sonne: sh*t
emmes: sonne: can you try w/ 'Option "norandr"'?
ndim: sonne: Can you pastebin/upload/email src/git_version.h, please?
sonne: emmes, I did, now only the 1440x900 resolution is there
emmes: sonne: sure, but paste the logfile so I can check whether the monitor has been detected
sonne: emmes, that is what I meant it is not
emmes: ah, ok
sonne: emmes, http://nn7.de/debugging/Xorg.1.log and git_version.h
ndim: BTW, are you still aiming for a "release" this week?
sonne: I have to go now... will be back in an hour (I hope)
sonne: cu
emmes: cu
emmes: ndim: well - *I* do. :^)
ndim: emmes: OK. then it makes sense that I invest a little time in the man page.
emmes: ndim: especially options ;)
emmes: if in doubt, ask.
ndim: I'm especially interested in limiting the amount of copied text shared between the man page and the wiki page.
emmes: ndim: sure. but some things bear repeating ;) and the options are explained nowhere so far (except for 1,2)
ndim: Most of the options I neither know or understand.
emmes: maybe just add some stubs, I'll fill it out then :)
Zhenech: mh, any news about ati releasing more specs?
ndim: emmes: http://radeonhd.lauft.net/patches/ndim-doc/
rmh3093: ndim, any chance of the radeonfb driver getting updated to support r400-r600 cards?
khorben: doesn't it already?
rmh3093: no i dont think so
khorben: ah sorry misread
rmh3093: i think it only goes up to some r400's
rmh3093: my M56p definately dont work with it
rmh3093: i would love to have 1680x1050 framebuffer
rmh3093: 1400x1050 sucks
khorben: vesafb doesn't do that?
rmh3093: vesafb can only do vesa compliant modes
rmh3093: which does not include widescreen resolutions
rmh3093: err
khorben: ah right
rmh3093: but i know people with older radeons get 1680x1050 with the radeonfb driver
ndim: rmh3093: I have no idea about the radeonfb.
ndim: . o O ( Multihead for the framebuffer console )
rmh3093: where are the official docs that amd released?
ndim: ftp.x.org/doc or something
libv: sonne: can you run conntest and see if it still does DDC through that?
ndim: emmes: http://radeonhd.lauft.net/patches/ndim-git-version/
ndim: If there are no additional requests for me to do something, this concludes my patch submissions for today.
ndim: goes back to exploring pdftk.
libv: ndim: :)
emmes: ndim: pushed
ndim: emmes: Just the man page?
the-me: hello
ndim: (I have the git-symbolic-ref fix as well)
libv: the-me: so what issues do you still see?
libv: the-me: we know about brightness
emmes: ndim: didn't see that this was two different branches
libv: and the scrambled fb will be properly blanked in a few minutes
ndim: I wouldn't dare molest you with the same branch twice. :)
the-me: libv, this framebuffer one but now I see some other issues, please wait a few seconds, I will create screenshots *first have to boot up notebook*
libv: ok
libv: hrm, screenshot needed, doesn't sound good
the-me: hard to describe :)
the-me: but: I'm using kpowersave which makes my screen black after some minutes of inactivity. with radeonhd, it takes a long time where the screen gets black and in this time, there are many purple stripes on the screen
libv: the-me: this is done by adjusting the actual framebuffer content i think
the-me: another issue: most of my desktop is grey, for example the toolbars of firefox. with radeonhd if I look closer to my screen, I can see, that the grey isn't constant
libv: the-me: yeah, this is temporal dithering
libv: the-me: 18bit panel, 24bit framebuffer
libv: the-me: so the LVTMA block needs to do some reduction there
the-me: how boring, you know all my bugs ;) I can't make a surprise to you!
libv: :)
libv: the-me: the purple stripes do worry me
the-me: hmm, should I create a movie of it with my digicam?
libv: the-me: but if you are talking about a gradual blackening of the screen, then this is probably all done in software
the-me: I dont know how kde and kpowersave handle this in precission
emmes: ndim: had to rebase first
libv: me neither, but it is worrying as to how this produces purple stripes
libv: could this be the dithering trying to cope with the fb content?
libv: imho this could be achieved rather nicely by gradually taking the gamma down
sonne: libv, what is the exact command I need to run ?
sonne: libv, I see DDC: RHD_DDC_NONE
sonne: emmes, so ... what now?
emmes: sonne: I asked Egbert to help you - DDC is his work
emmes: Luc might also have some ideas
sonne: emmes, OK
sonne: emmes, so the xrandr mode changes might be impossible due to wrong/missing DDC infos?
sonne: (even the 800x600 ones I mean)
emmes: not really
emmes: but i'd like to tackle one issue a time
emmes: i have a monitor connected with BNC here, so no DDC, and it works just fine :-(
sonne: OK... it might of course be that DDC info is gone from the monitor... like gone to nirvana ...
emmes: egbert killed two monitor's DDC during programmin the DDC bits, because we had no programming docs, but don't be afraid, that cannot happen any more ;)
libv: hrm
sonne: well as long as I see the hex dump of that monitors edid in the xorg.0.log I have some hope that in the worst case I could force the driver to use that one
sonne: and yes, I had that problem with an old powerbook at some point ...
sonne: and there a kernel patch doing exactly this - providing the internal displays edid- helped :-)
emmes: sonne: i don't see it in the log
sonne: isn't it this thing EDID (in hex):
sonne: in the old logs I meant ...
emmes: yes, in the old ones
emmes: there the monitor was detected.
egbert: sonne: have you power cylced the monitor?
sonne: egbert, yes via power button
egbert: if so please run rhd_conntest.
egbert: see what it tells about ddc.
sonne: DDC: RHD_DDC_NONE
slackern: emmes, sent a response to your request wanting me to try a new newer release of the driver.
slackern: goes away to learn to read what he just typed before pressing enter
sonne: egbert, ./rhd_conntest 01:00.0 | grep DDC - right ?
egbert: sonne: it says RHD_DDC_NONE?
sonne: yes
egbert: that tells that the slave address for ddc doesn't exist.
egbert: this doesn't look like my problem - where ddc was still there but the edid data block was runed.
sonne: hmmhh, good or bad?
egbert: good question ...
sonne: OK...
egbert: maybe you want to power cylce both the computer and the monitor.
libv: i guess reseating the cable, at both sides, has been tried?
sonne: as this is a macbook pro I can run osx / windows and do tests there if that helps
sonne: egbert, I already powercycled both computer and tft
egbert: sonne, this may be an option.
libv: ah, macbook internal panel?
sonne: egbert, but what to do there ?
libv: hrm
egbert: sonne: also replug the cable on both ends as libv said.
sonne: no external display
egbert: sonne: ok, so it's the internal panel.
libv: egbert: we had issues with macbooks before, right
egbert: err; we had this before.
libv: sonne: was there an efi update?
emmes: egbert: no, not about internal panel
egbert: the edid block (or timing info) should come from atombios then.
emmes: the *external* display doesn't work
egbert: emmes: that's what i thought.
sonne: libv, no
libv: ah
libv: no, internal display
libv: as opposed to no internal display
libv: means something else :p
libv: so the ddc to the outside is broken now
libv: hrm, would it be possible to wire up gpio lines for ddc?
libv: and test that?
emmes: yes, with apparantly no software change
sonne: ahhh
sonne: yes
sonne: I replugged cables and turned the monitor off ...
libv: sonne: also, do you have different hardware to test with?
egbert: there was the case where suspend/resume helped.
sonne: nothing
libv: egbert: right, yeah, curiously
egbert: this fixed things for internal displays.
sonne: libv, only a single tft here ... and the other computers don't have a dvi output
sonne: so what now?
egbert: sonne: have you tried to suspend and resume the laptop?
sonne: egbert, no ... but I shut it down / up
sonne: anyway I can try brb
egbert: sonne: please give it a try.
slackern: emmes, sent you another log now using norandr option.
emmes: slackern: thnx
slackern: emmes, your welcome.
slackern: emmes, and thank you too btw :)
emmes: won't be able to fix this today, though.
sonne: egbert, yup that *did* help
sonne: DDC: RHD_DDC_0
sonne: DDC Line[0]: Slaves: a0 a2 a4 a6 a8 aa ac ae
egbert: sonne: hrm. i should get myself a macbook.
egbert: and start poking.
emmes: slackern: working on a different issue ATM
sonne: emmes, suddenly xrandr shows manny resolutions, though not the one of the display ...
sonne: egbert, macbook pro 1,1 I am on...
sonne: emmes, and resize requests are still ignored
emmes: sonne: not that i recommend that - but it would be interesting to see whether after reboot it works now ;)
sonne: well... maybe the size is not there because of the issing virtual line
slackern: emmes, oh no worries, just let me know if you need more information.
emmes: sure
egbert: emmes: it won't
emmes: ok?
emmes: so you have some ideas?
egbert: resume changes something. no idea what.
sonne: emmes, well if I add virtual 1920 1200 or so then the right resoution appears
emmes: sonne: oops
emmes: that's interesting
sonne: so now if only changing resolutions would work
emmes: ;)
emmes: something for tomorrow or so
sonne: I remember that you suggested that to me yesterday
sonne: err friday
emmes: but you could git-bisect the commit that breaks changing the resolution.
sonne: emmes, it never worked ...
emmes: oh!
emmes: scratches his head
sonne: however it was worse, remember the days where --auto made all screens black :-)
emmes: do you have a recent logfile at nn7.de ATM?
emmes: maybe you could upload one with you trying to change to different resolutions
sonne: emmes, now Xorg.1.log
emmes: and also check whether xrandr --verbose --output XXX --mode YYY prints out *anything*
sonne: emmes, momplz
sonne: emmes, now Xorg.1.log
sonne: emmes, err --mode ?
sonne: I was always ever only using --output xxx --size yyy
sonne: --mode works !
sonne: argh, with the old driver one can create black displays
sonne: so it now works ?!?!
sonne: what I find strange is that after resizing, gnome does not recognize that the screen resolution has been chaned
sonne: changed
sonne: emmes: had to kill X ... just in case you said something
emmes: sonne: my fault with --size...
emmes: OMFG
emmes: sorry
emmes: should be more careful when instructing people with xrandr...
sonne: emmes, well, it works :-)) so I am happy, except for that gnome did not realize that the resolution changed
emmes: so what version of gnome are you using?
sonne: 2.20 IIRC
sonne: 2.20.1
emmes: well - which distribution, I should ask (because i have no real clue about gnome versions ;)
sonne: debian sid :-)
emmes: i know there used to be issues. but I havn't tested gnome here yet.
sonne: just dreams of working on that big display
emmes: sonne: just a second
sonne: actually the background resolution adjusted to the full screen but not the panel etc
emmes: hm, no gnome installed on this laptop, have to do that first
sonne: emmes, maybe that is a wanted thing... I mean maybe I have to make the external display the primary display?
sonne: I am so clueless about xrandr :(
emmes: sonne: on kde it does work. now installing gnome
sonne: wonders how gnome figures out the display resolution
emmes: randr sends an event
yangman: is there a known issue with improperly set DPI?
emmes: yangman: with latest git master no, with some versions before (like during the weekend), this is solved
yangman: radeonhd on my laptop seems to be doing all the EDID detection properly, then ignores the screen dimension and sets DPI to 75
sonne: emmes, doing xrandr --output PANEL/LVDS --off makes the display go fullscreen
emmes: yangman: git version
yangman: latest, as of 40 minutes ago
emmes: sonne: so it does work
emmes: yangman: eek
yangman: could it be randr related?
emmes: *everything* could be randr related, even the end of the world ;)
yangman: heh
sonne: emmes, but how does one work in mirror mode ? or is that not possible
yangman: the version of libXrandr I have installed doesn't want to play nice with radeonhd. I've yet to try something newer
emmes: sonne: in clone mode you should have the same resolution on both monitors. otherwise, the bigger one wins. you can reduce the resolution of the bigger one as well. panels don't scale, though ATM.
emmes: yangman: DPI detection is something for the server.
emmes: so no libXrandr involved
sonne: emmes, exactly that did not happen... the bigger one had a high resolution 1680x1050 and the internal display stayed at 1440x900 but no scrolling!
yangman: hmm...
sonne: and the panel adjusted to the lower resolution screen...
yangman: it works fine if I manually set display size
sonne: s/the panel/gnome/
emmes: yangman: for something not as urgent as the other stuff, please create a bug report (especially with Xorg.log)
emmes: so it won't get lost
emmes: and you can try 'Option "NoRandR"' and check whether it works fine then
emmes: sonne: panning isn't implemented in randr yet. nowhere.
emmes: they dropped it upstream, and so far nobody bothered puting it back in again.
yangman: emmes: I have to have NoRandr enabled for it to work at all. segfualts otherwise
emmes: ai, I remember
emmes: had you been able to send me a gdb stack backtrace?
sonne: emmes, I see. And now since 'the scaler or how you call it' is not yet implemented I cannot have 800x600 on both displays or even a single resolution that fits internal and external display...
sonne: makes sense that this confuses gnome
sonne: so to summarize: turn off the display I don't want gnome to adjust ...
sonne: to
emmes: sonne: right :-(
emmes: sorry, but that's the way it is ATM. with all randr implementations.
emmes: egbert said implementing the scaler would be easy, but we want to release first.
emmes: this is more important
sonne: emmes, well I think the scaler is really important ... otherwise it is quite confusing
emmes: sonne: i know, but getting a release done is more important.
yangman: emmes: not yet. I don't seem to get a very meaningful stack trace out of gdb, which is probably due to everything other than radeonhd lacking debug symbols
emmes: remember: release early, release often :P
sonne: I mean people that come from fglrx are used to have all the lower modes there
sonne: emmes, OK
emmes: yangman: compile with make clean; make CFLAGS="-O0 -g3"
sonne: that I read as: release today add scaler tomorrow
sonne: :-)
emmes: and for the xserver - if using opensuse - install xorg-x11-server-debuginfo package
emmes: sonne: you got it
emmes: sonne: so for the moment I can consider your issues fixed?
sonne: emmes, literally :-))
sonne: emmes, yes
yangman: emmes: will do. I'll give an update once I have some time to test it
emmes: (except for that weird DDC after resume only bug)
emmes: yangman: thanks
sonne: be sure that I will torture the thing a bit...
sonne: right
emmes: is afraid of more bugs...
emmes: sonne: yes, please!
sonne: pads emmes
sonne: pets
sonne: please put the info that the scaler is not yet in also in the release notes as it will confuse people... might be worth another release even when it is in
emmes: egbert: I have another machine here where DDC fails, on both outputs. so i can bisect
emmes: tomorrow
sonne: emmes, so it worked once for that person? and does (not like I had it) still work with that old version?
emmes: sonne: no, false alarm ;)
emmes: it *does* still work, just the CRT doesn't do DDC at all any more...
sonne: very good =:-)
khorben: libv: thanks so much for the blank hook btw
egbert: emmes his ddc, this was me :p
emmes: egbert: you killed *my* monitor?!?
emmes: slaps egbert in da face
emmes: :P
egbert: emmes: i thought you were hungry?
sonne: puts the live fight on youtube
frb-work: moo
egbert: frb-work: hi!
frb-work: howdy
egbert: frb-work: your white screen problem should be fixed now.
frb-work: yay, that's on the PD, so I can probably test it now
egbert: you need to pull the latest stuff as i've committed a missing piece 30 minutes ago.
frb-work: I planned on it, I haven't pulled anything since last week
egbert: frb-work: ok
frb-work: I don't think it worked
egbert: frb-work: what do you see?
frb-work: (II) RADEONHD: version 0.0.4, built from git branch master, commit 2e0f5f11
frb-work: is that your version?
egbert: yes.
frb-work: I still got the white screen
egbert: hrm.
frb-work: what line did we patch before?
airlied: egbert: with the monitors you messed up the DDC did you just over-write the first few bytes?
egbert: can you get me a -verbose 7 log?
airlied: egbert: I've got one here where the first couple of bytes are junk..
slackern: Just added "DisplaySize 338 270" to monitor section and now fonts looks better for me in GDM :)
airlied: but the rest is fine..
frb-work: I want to make sure we didn't double-offset because git doesn't seem to care if I edit files
egbert: airlied: no, there was mess sprinkled all over.
egbert: some byte sequences seemed to have gotten moved or duplicated.
airlied: egbert: ouch.. I'm going to try and repair mine at some point ..
egbert: airlied: what manufacturer?
airlied: egbert: sony
egbert: airlied: ah, mine was iiyama.
airlied: egbert: it makes a good test monitor for dac load detect now..
egbert: airlied: if i i knew what i did exactly. i tried some tricks usually used for programming i2c memory - none worked so far.
airlied: egbert: since I can't find it any other way :)
egbert: airlied: exactly. that's what we use them for too :)
airlied: egbert: yeaha I'm the same, I found a DOS app on the net that claimed to re-program it but didn't..
egbert: airlied: it actually increased its value.
egbert: :p
frb-work: egbert: http://for.wiw.org/rhd/Xorg.out
egbert: airlied: i was more lucky with the card bios.
egbert: airlied: i managed to 'flash' it, too. but there is a decend app around to repair that.
egbert: airlied: i even think it's from ati. although they don't want to admit.
egbert: frb-work: i think i know what your problem is.
frb-work: I'm an incorrigible asshole with self-esteem problems?
frb-work: :_
frb-work: :)
egbert: frb-work: nope :)
frb-work: oh good, everyone says I'm quite friendly and confident
egbert: frb-work: even if you were - it wouldn't make a difference for the driver :pp
egbert: frb-work: yeah, you are. you did not even get upset when people were giving you crap the other day :)
frb-work: what's the point?
egbert: frb-work: there is no point in getting upset about such things.
frb-work: anyway, back to the driver
egbert: frb-work: right.
egbert: i think i now the issue.
egbert: i should talk to emmes, though.
egbert: unfortunately he is not around any more.
egbert: went home to eat
egbert: pfff - as if a developer needed that.
egbert: frb-work: still around? can you pull again?
egbert: dli: are you around?
dli: egbert, yes
dli: egbert, any good news for me?
egbert: dli: well, i've investigated your problem.
egbert: dli: i cannot reproduce it here.
dli: egbert, you mean on radeon? I don't have any problem with radeonhd for long
egbert: didn't you have the problem that it was slower than avivo?
dli: egbert, yes
egbert: i could not reproduce this here.
dli: egbert, I think libv makes it clear, it's not on ToDo list
egbert: well, i had it on mine.
dli: egbert, try mplayer, "mplayer -zoom -vo x11" to play any video
dli: egbert, try to play fullscreen
egbert: i tried glxgears as you said this had differences in fps, too.
airlied: color tiling?
dli: egbert, let me try it now
egbert: airlied: does avivo do color tiling?
airlied: egbert: not that I know off but they may just do what fglrx did..
egbert: i'm not sure if it makes a difference for fullscreen.
frb-work: hmm?
egbert: frb-work: did you try again?
dli: egbert, verified
egbert: dli: ok, so glxgears makes a difference?
dli: egbert, glxgears fps: 800 from radeonhd, 1100 from radeonhd with avivo on :1
egbert: could you please give me a log of radeonhd (again) and the output of "cat /proc/mtrr".
dli: egbert, the fps difference hides the fact, avivo is much faster with video playback
frb-work: egbert: it works now
dli: egbert, I can play video on radeonhd up to like 600x400, avivo can play 1400x1050(fullscreen), without frame drop
egbert: frb-work: ok, thanks!
dli: egbert, I have heard someone runs radeon and gets the speed for fullscreen video with X1300, I am waiting for airlied to fix radeon for mobile cards now
egbert: dli: i can run radeonhd on rs690 full screen 1680x1050 without any problems.
airlied: dli: well radeon does use color tiling so it should be faster...
dli: egbert, how much fps from glxgears? with rs690
egbert: dli: haven't tired this on rs690 yet.
dli: egbert, I got only 800fps from my firegl v5250 now. that's why I hate ati/amd so much
egbert: i had to reinstall my system.
frb-work: egbert: need anything else on that box? I need to finagle my system to free up a HD
egbert: frb-work: if you can give me the log and the output of 'cat /proc/mtrr' while radeonhd is running i should be set.
egbert: frb-work: oh, sorry.
frb-work: just the normal log?
egbert: frb-work: two threads intermixed.
egbert: frb-work: no, forget it :)
frb-work: oh, ok
egbert: frb-work: you should be all set. at least on the one box.
egbert: frb-work: i assume the other still has problems?
frb-work: egbert: it's in vista right now so I can work, I can check it after I finish the work on the other
jandem: just curious, i see some commits about 'MC', what does mc stand for?
frb-work: Mind Control!
jandem: frb-work: hehe :p
dli: airlied, can you explain the speed difference due to running avivo on :1
egbert: frb-work: no prob!
airlied: dli: or maybe avivo is overclocking your memory )
egbert: jadem: some setup for in the memory controller.
frb-work: wow, that screensaver needs to be banned from the planet
dli: airlied, how can I verify that?
airlied: dli: I'm just guessing really :)
egbert: dli: you have an X1400, right?
dli: airlied, firegl v5250
jandem: egbert: thanks
dli: airlied, I see one way, I can monitor video card temperature
frb-work: I also have a firegl v5200 mobility I can test with
airlied: dli: you could dump lots of regs with avivotool ..
egbert: airlied: this has been tried already :(
egbert: airlied: no conclusive results.
egbert: airlied: the funny thing is: it also happens when avivo is still running but vt-switched away.
airlied: egbert: did you dump the MC regs?
airlied: egbert: hence why I'd go for memory controller..
egbert: airlied: this was another problem. some cards use the upper 256M for scanout while writes thru the pci aperture go to the lower 256M.
egbert: airlied: oh, ok. we do dump some mc registers.
frb-work: egbert: my console is hosed after exiting X though
egbert: frb-work: hrm.
frb-work: I'll check again after a reboot
egbert: ok.
frb-work: of course, I'll be switching to a 64bit OS at the same time, since the 32 was on the drive I'm pulling
egbert: frb-work: ok.
egbert: frb-work: shouldn't make a difference.
egbert: dli: could you please send me the log and the output of 'cat /proc/mtrr'?
egbert: i need to quit now - good night!
dli: egbert, log from radeonhd or avivo?
egbert: dli: radeonhd.
egbert: please mail it to eich@suse.de.
egbert: then i can look at it tomorrow morning.
frb-work: what is avivo?
agd5f: frb-work: old reverse engineered driver for r5xx hw
frb-work: crap, I don't know git
frb-work: fatal: Entry 'src/rhd_crtc.c' not uptodate. Cannot merge.
frb-work: how do I just force it to overwrite and do it?
dli: egbert, sent
egbert: dli: thanks!
egbert: you said, radeonhd works faster when avivo is running 'in the background', right?
egbert: dli: it get's slower as soon as you terminate avivo, if i recall correctly.
dli: egbert, right, glxgears runs at a faster 1,100fps on radeonhd or avivo , when avivo runs at :1
egbert: dli: and when you kill avivo fps drop?
dli: egbert, yes, the speed on radeonhd returns to 800fps if I quite avivo on :1
egbert: dli: without restarting radeonhd, right?
dli: egbert, as I said, the speed difference on video playback is more dramatic then the glxgears numbers
dli: egbert, without restarting radeonhd
egbert: dli: but glxgears is already signifficant.
egbert: dli: while signifficant. ~ 30 percent.
dli: egbert, yes, the speed difference between 600x400 and 1400x1050 is more than 30% to me
egbert: dli: ok. glxgears is easier for me to test.
egbert: dli: which kernel are you using?
dli: egbert, 2.6.22-gentoo-r10
egbert: ok.
egbert: dli: thx!
dli: egbert, thank you!
egbert: dli: i need to go to bed! starting to get really sleepy. good night :)
dli: egbert, nite