hbock: I hate RANDR.
hbock: Specifically, trying to work with rhd and randr.
MostAwesomeDude: hbock: Trust me, it's WAY better than the old way.
hbock: Oh I know, I'm just getting some X11 errors when setting up a display that I really shouldn't be getting
hbock: e.g., if I try and use a mode with a higher resolution on a CRTC I get a BadValue error unless I resize the screen first
hbock: but if I resize the screen first I (correctly) get a BadMatch error
hbock: maybe it's a bug with atombios_support.
hbock: goes to try master
hbock: also, rhd is reporting the wrong output width in millimeters, but DisplayWidthMM is correct... weird.
dli: (WW) RADEONHD(0): No monitor size info, assuming 96dpi
dli: can I do anything to fix this?
CCob: any dev's around?
libvde: just now yes
libvde: but i just woke up :p
libvde: CCob: why btw?
CCob: got some questions
CCob: interested in answering?
CCob: or still a bit early for you?
libvde: i have my horribly strong tea, and my caffeine addiction already sent adrenaline surging around on scent alone, so in as far as i am able to provide answers, i am as ready now as ever :p
CCob: :)
Rys: haha
Rys: Go go gadget libv!
libvde: :)
Rys: I've designated today as "finally install my RV770 day", now that we have modesetting for that chip
CCob: I have been using fglrx for some time now with my 780G, but I had a couple of issues. Mainly 2d acceleration. When dragging windows etc... it was very slow
CCob: I changed to radeonhd and 2d was much much better
CCob: but I have some overscan using radeonhd, how can I go about solving that
libvde: overscan?
libvde: hrm...
libvde: does the mode the driver sets match the mode the monitor has?
libvde: CCob: if this is a tft, the obvious thing is to let the TFT auto-reconfigure itself
CCob: as far as I can see yes. It sets it up at 1920x1080
CCob: it's a HD screen via HDMI
CCob: on fglrx I dont have that problem
libvde: ok... but then, afaik fglrx keeps monitor information and everything around itself too
libvde: we just go with what ddc tells us
CCob: the screen information shows the correct resolution and that is running at 60Hz
CCob: the other issue with fglrx is that I cannot for the life of me get HDMI audio working
CCob: Does the radeonhd driver support the audio portion yet
CCob: As far as I know it involves enabling a bit within one of the cards registers
CCob: one last question, the ATI control panel detects that my screen can do 24hz refresh, is there something I can do with radeonhd to get 24hz. In the screen resolution program (Ubuntu) which I think uses RandR it only displays 60hz
CCob: Would modeline's in xorg do the trick?
CCob: xorg.conf that was meant to be
libvde: CCob: some really clueful coder came out of the blue a month or so ago and wrote up hdmi support for our driver, in a way that's unbelievably good as well (as it really matches our driver very well), he did a fantastic job
libvde: CCob: but we've been spread soo thinly on our work that we haven't managed to test this yet :(
libvde: 24Hz?
libvde: eh?
libvde: CCob: probably interlaced, right, which would then mean something like 48Hz but skipping scanlines
CCob: Yea, My TV has a 24hz refresh rate support for content that is encoded at 24fps (Blu-Ray etc...)
Rys: I think it's 24 progress frames
Rys: My TV has the same
libvde: aah, hrm, i wonder how that works, whether it just is a 24Hz modeline that's provided
Rys: I presume so
CCob: yea 24hz/progressive
libvde: it could be that we need to work with some EDID extension to find that out; and it could be that this is very HDMI/HDCP heavy
CCob: ah I see
libvde: CCob: so it shows in the edid blob that's dumped to the log?
CCob: haven't checked the log, but it did show up using read-edid tool
CCob: but I can't check that anymore because I switched to x64 build of ubuntu and read-edid doesn't work on that
CCob: what log should I check?
libvde: /var/log/Xorg.0.log
libvde: if you run X directly, like Xorg -logverbose 7
libvde: then you get a really verbose log that should tell us quite a lot of what is going on
CCob: OK i'll try now. hang tight
CCob: Number of EDID sections to follow: 1
CCob: (II) RADEONHD(0): EDID (in hex):
CCob: (II) RADEONHD(0): 00ffffffffffff004c2d9f0200000000
CCob: (II) RADEONHD(0): 2d100103801009780aaea5a6544c9926
CCob: (II) RADEONHD(0): 14505420000001010101010101010101
CCob: (II) RADEONHD(0): 010101010101023a801871382d40582c
CCob: (II) RADEONHD(0): 4500a05a0000001e011d007251d01e20
CCob: (II) RADEONHD(0): 6e285500a05a0000001e000000fc0053
CCob: (II) RADEONHD(0): 414d53554e470a2020202020000000fd
CCob: (II) RADEONHD(0): 00313d0f4417000a202020202020012f
CCob: (II) RADEONHD(0): EDID vendor "SAM", prod id 671
CCob: (II) RADEONHD(0): Using EDID range info for horizontal sync
CCob: (II) RADEONHD(0): Using EDID range info for vertical refresh
CCob: (II) RADEONHD(0): Printing DDC gathered Modelines:
CCob: (II) RADEONHD(0): Modeline "1920x1080"x0.0 148.50 1920 2008 2052 2200 1080 1084 1089 1
CCob: 125 +hsync +vsync (67.5 kHz)
CCob: (II) RADEONHD(0): Modeline "1280x720"x0.0 74.25 1280 1390 1430 1650 720 725 730 750 +
CCob: hsync +vsync (45.0 kHz)
CCob: (II) RADEONHD(0): Modeline "640x480"x0.0 25.20 640 656 752 800 480 490 492 525 -hsync
CCob: -vsync (31.5 kHz)
CCo1: battery went dead
libvde: CCo1: can you send this verbose log to the mailinglist, together with an explanation of the issue?
CCo1: sure, i'll send it a little later on
CCo1: I am going out now
hbock: libvde: still around?
libvde: hbock: yes, why, what's up?
hbock: I dunno if this has anything to do with rhd, but my dpi/mm_width/mm_height keep changing when changing modes
hbock: [kde-devel@shinigami ~]$ xrandr --verbose --output DVI-I_1/digital --auto
hbock: screen 0: 1680x1050 473x296 mm 90.10dpi
hbock: crtc 0: 1680x1050 60.0 +0+0 "DVI-I_1/digital"
hbock: [kde-devel@shinigami ~]$ xrandr --verbose --output DVI-I_1/digital --auto
hbock: screen 0: 1680x1050 485x303 mm 87.87dpi
hbock: crtc 0: 1680x1050 60.0 +0+0 "DVI-I_1/digital"
hbock: [kde-devel@shinigami ~]$ xrandr --verbose --output DVI-I_1/digital --auto
hbock: screen 0: 1680x1050 484x303 mm 88.02dpi
hbock: crtc 0: 1680x1050 60.0 +0+0 "DVI-I_1/digital"
hbock: ^ all setting the same preferred mode, getting different physical sizes / dpi
libvde: hrm
libvde: this probably is an RandR issue, i doubt there is any extra dpi handling in our driver on top of RandR
libvde: there is some dpi handling in the other case though
libvde: but you wouldn't be able to use xrandr with that
hbock: XRROutputInfo.mm_width is also different from DisplayWidthMM (same with height), which is weird
hbock: hmm, yeah i figured. I didn't notice any dpi handling in rhd_randr.c
hbock: it doesn't seem to affect font rendering at all, which is kind of strange
libvde: the changes are rather minor
libvde: so it won't get you a different font yet
marcheu: libvde: if you detect different physical sizes, how can it be a randr12 issue ?
libvde: marcheu: how can it not be an randr12 issue? randr handles all this stuff for us
libvde: there is no driver intervention on those things afaik
libvde: it's amazing how little driver intervention randr actually allows too
libvde: we had some bugs for opensuse 11 where we had to provide workarounds because randr would do things for us
libvde: without us being able to go anywhere near
hbock: randr client programming is annoying enough as it is, i can't imagine trying to write a driver to use it...
libvde: well, there's the option of just sticking to the model randr12 forces upon you
libvde: then it is much more structured already than what we had before
libvde: but if you don't agree with that structure because, for instance, you're not IGP, then you have to do some dancing around
libvde: but sadly there is only a limited amount of dancing around possible, and radeonhd is doing a lot of workarounds to make it possible
libvde: dpi is probably not where radeonhd has any say
hbock: can you work with, say, keith packard, for randr 1.3 to address those issues?
hbock: or would backwards compat. with 1.2 be too much work?
hbock: libvde: yeah, definitely not rhd's problem. I'm getting a similar issue with radeon
hbock: either xrandr is screwing up the mmwidth or my program is. probably mine, i'll look more into it :)
Nightwulf: hi all
kjo: hi !
Nightwulf: hi kjo
kjo: Does anybody of you know wether it is possible to build radeonhd on debian *etch*
kjo: I tried to backport the lenny package, as explained here
kjo: http://www.phoronix.com/forums/showthread.php?p=19575
kjo: but I got en error :
Nightwulf: isn't a debian guy...sorry
kjo: install -d -m 755 debian/tmp/usr/bin
kjo: install -m 755 obj-i486-linux-gnu/utils/conntest/rhd_conntest
kjo: debian/tmp/usr/bin/
kjo: install: ne peut évaluer
kjo: `obj-i486-linux-gnu/utils/conntest/rhd_conntest': Aucun fichier ou
kjo: répertoire de ce type
kjo: make: *** [install] Erreur 1
kjo: debuild: fatal error at line 1228:
kjo: debian/rules binary failed
kjo: Nightwulf: well... No problem !
Nightwulf: besides that, my french is a bit rusted :)
kjo: do you want a translation, or do you think it's not useful for you because you can't understand debian ?
Nightwulf: let me have a closer look
kjo: Translatad, it is :
kjo: install -d -m 755 debian/tmp/usr/bin
kjo: install -m 755 obj-i486-linux-gnu/utils/conntest/rhd_conntest
kjo: debian/tmp/usr/bin/
kjo: install: can't evaluate
kjo: `obj-i486-linux-gnu/utils/conntest/rhd_conntest': No such file or directory
kjo: make: *** [install] error 1
kjo: debuild: fatal error at line 1228:
kjo: debian/rules binary failed
Nightwulf: k...but the two really french lines would have been ok ;-)
kjo: well, I didn't knew how to explain, then it was easyer for me to copy enerything
Nightwulf: hmm...is install right? doesn't the file exist?
kjo: ^everything
kjo: I can't look on that computer right now
kjo: sorry
Nightwulf: then i can't possibly say what's wrong there ;-)
kjo: I wondered if other people build it on etch
kjo: ok I will control that
kjo: tahnks
Nightwulf: yeah...you will need another guy running into the same problems i guess
marcheu: kjo: I think that building rhd_conntest failed/was not done, but you missed it. in any case, the conntest utility is not required to use the radeonhd driver
marcheu: kjo: so really, it should be ok as it is
kjo: is there a way to disable building this utility ?
kjo: with a paramater or something like that
kjo: cause the debian pagkage will not build until make returns with 0
kjo: well thanks for your answers
kjo: I'll try when I'll have that computer with me
ndim: kjo: If you can pastebin the complete build log, I might be able to help (no Debian here since about 2005).
kjo: ok
kjo: I give it this evening
Darkonr: hi to all
kjo: marcheu: Nightwulf: ndim: I solved my problems
Nightwulf: kjo: great to hear, what was it's cause?
Nightwulf: hi Darkonr
Darkonr: hi :D
kjo: There were a missing dependency to zlib and libpci (or simething like that)
Nightwulf: k...great you solved it
kjo: which were optional, as it was just for rhd_conntest
kjo: but rhd_conntest was used later in the debian package build script
kjo: then the build of the package failed
kjo: but with these dependances it was OK
Darkonr: sorry i'm helping a friend with archlinux, he installed the radeonhd driver but i don't know if he need to put something in Modules :\
Nightwulf: Darkonr: no, he don't...I use archlinux myself :)
kjo: i will update the forum
Darkonr: wow thx so he only need to put radeonhd in xorg.conf and reboot ?
kjo: Darkonr: it's what I did
kjo: Darkonr: you don't need to reboot, just to restart X
Nightwulf: Darkonr: yes, if the xorg.conf is very basic and doesn't contain config options from e.g. catalyst drivers
kjo: (e.g. with CTRL+ALT+BACKSPACE)
Darkonr: ok he's trying
Darkonr: thx i know
ndim: Darkonr: If you have been running fglrx, you probably need to reboot before you get any life out of radeon or radeonhd.
ndim: It might work by accident, though.
Darkonr: he's running vesa because with catalyst he can't start Xorg :\
ndim: Similar warning might apply.
Darkonr: only black screen with catalyst, I hope that with radeonhd it'll work :(
Darkonr: ok I tell him to reboot
Nightwulf: Darkonr: btw...what card is it?
Darkonr: Sapphire X1550
Darkonr: lspci: Display controller: ATI Technologies Inc RV516 [Radeon X1300/X1550 Series]
Nightwulf: k, that card should be supported by both drivers
Nightwulf: mine only works with radeonhd atm :)
Darkonr: he said that it worked on ubuntu gutsy( I think) with gibbon it stopped working and with archlinux it doesn't work too
Nightwulf: sounds weird
Nightwulf: does he use another operating system on which the card still works?
Darkonr: on windows still work he said
Nightwulf: very strange...i have two machines with ATI and one i use since two years with fglrx without a problem so why should a card stop working from a given version on?
Nightwulf: Darkonr: does /var/log/Xorg.0.log show any error messages? (EE) in front
Darkonr: uhm it's strange, time ago I told him to gave me /var/log/Xorg.0. but anything strange
Darkonr: i look if I save the log on my computer
Nightwulf: k
Darkonr: with radeonhd now it work but withouth 3d in glxinfo but i don't know if the radeonhd has a 3d support
Nightwulf: Darkonr: have a look in the wiki on the features page http://wiki.x.org/wiki/RadeonFeature
Darkonr: ok thx
Nightwulf: np
Nightwulf: is away for some minutes
Darkonr: uhm all wip with radeonhd
Darkonr: probably is better radeon old driver?
Rys: Depends on what you're looking for from the driver
Darkonr: I think he need 3d acceleration but doesn't play anything newer than tuxracer :D
egbert: Darkonr: you have to enable DRI with 'Option "DRI"' in the config file. but you will also need a very recent version of mesa and the drm kernel module to get 3d to work.
egbert: look at the wiki page in the topic for more info.
Darkonr: ok thx
Darkonr: uhm so my friend isn't the only one with blank screen
Darkonr: http://bbs.archlinux.org/viewtopic.php?id=50994
Darkonr: @egbert for very recent version of mesa do you mean git ?
gentoofu: git would be good
gentoofu: but if you want a regular package, at least mesa 7.1
Darkonr: ok thx
Darkonr: hope it works Mesa 7.1rc3
gentoofu: you'll also need the most recent xorg-server
Darkonr: ah :\
gentoofu: there's a talk about back porting mesa so you won't hafta install the most recent xorg-server
MostAwesomeDude: Hmm.
MostAwesomeDude: I see no reason why the r5xx stuff couldn't be backported.
MostAwesomeDude: In fact...Hmm...
Darkonr: uhm so i have to wait for a git version with r5xx stuff ?
MostAwesomeDude: Darkonr: The git master branch has r5xx stuff.
MostAwesomeDude: I'm looking to see if it's possible to backport some of that stuff to 7.0.x right now.
airlied: I think radeon_screen.c is the one to be careful with..
airlied: most of the other code should copy back okay.
airlied: I did it back in Fedora 8 days for the rs480
MostAwesomeDude: airlied: I'm only looking at the r300 folder. If it goes okay, I'll put a branch up on my personal mesa repo.
MostAwesomeDude: Hmm. INLINE or __inline__ for 7.0?
airlied: MostAwesomeDude: whatever everyone else used :)
MostAwesomeDude: airlied: 'k. :3
marcheu: MostAwesomeDude: I asked this back then on the mesa list, answer is no one cares if you're inside a DRI driver
MostAwesomeDude: marcheu: Ah. Many thanks.
marcheu: MostAwesomeDude: core mesa is INLINE though
MostAwesomeDude: marcheu: Righty.
airlied: MostAwesomeDude: I think the only area you'll have to worry about is the DRI extension mechanism.
airlied: I looked at doing a backport before but I realised I didn't actually care for Fedor.
MostAwesomeDude: airlied: I wouldn't care either, but I know that for a lot of people, the new Radeon and Intel stuff matters. It doesn't seem fair to force them to upgrade all of X just for Mesa.
Nightwulf: re
marcheu: those people should better learn to upgrade often so we can break backwards compat :)
legume: Nightwulf: fglrx changed for AGP cards - new versions wouldn't work for me and others unless I set aperture size in bios to 512
Darkonr: sorry for disturb you,again, but what my friend should do if catalyst gave only black screen, with radeonhd no 3d because he need to update mesa and radeon I don't know if work but 3d should works :\?
legume: Darkonr: If it's an AGP card he could try setting aperture size in bios to 512 or 256
Nightwulf: legume: i c...sorry I didn't know but it's years ago I had my hands on an AGP card
legume: Darkonr: Or try old fglrx IIRC 8.41
Nightwulf: Darkonr: you give the mesa packages from archlinux testing repositories a try...but hey...it's not called 'testing' for fun ;-)
Darkonr: i told him to try to to change aperture size but he didn't find anything on bios
Nightwulf: hmm...I don't know any BIOS for mainboards with AGP slots which doesn't have such an option
Darkonr: uhm it's not so unstable testing, I use it everydays:D
legume: Darkonr: Should be somewhere - maybe hidden options - google for mobo
Nightwulf: Darkonr: you would change your mind if you earn your money with that machine/installation ;-)
MostAwesomeDude: airlied: The differences in radeon_context are minimal; the only thing of note is the vblank support.
airlied: MostAwesomeDude: it'll be radeon_screen.c :)
airlied: MostAwesomeDude: its shared between r100/r200/r300
Darkonr: @nightwulf probably yes ahah :D
Nightwulf: well, time to go to bed...night all
Darkonr: good night
MostAwesomeDude: airlied: Oh, that one.
MostAwesomeDude: With the chip IDs, etc.
airlied: MostAwesomeDude: yup..
Darkonr: @legume what was you talking? i forgot it :\
Darkonr: ahh the aperture size probably is hidden ? :\
legume: Darkonr: Maybe I've heard of it will try and find the post - Oh yea old fglrx is 8.40.4 not what I said
Darkonr: they still works on a new kernel ? :\
legume: Darkonr: I don't know about kernel. I found the message from someone who couldn't find aperture he said "All I had to do was switch it from booting PCI first to onboard/AGP."
MostAwesomeDude: airlied: Almost finished going over stuff. Should I cherry-pick, or should I just make one big commit?
MostAwesomeDude: I'm committing to a branch on my repo BTW, not the main mesa_7_0_branch
legume: Darkonr: Don't know if that helps or not :-) Maybe google will help him - anyway we are OT for here
Darkonr: thx legume i'll try sorry for the ot
Darkonr: bye bye i go
airlied: MostAwesomeDude: one big commit sounds fine
tylere: is radeonhd a better choice on an HD3850 card if I only care about 2D? fglrx is working for me, including 3D, but the 2D performance frankly sucks balls
tylere: window dragging for instance, is very laggy and leaves trails
Telek: marcheu: Regarding Compat: That's fine as long as it doesn't require updating glibc, the linux kernel and a whole lot of other things, including maybe installing hal and dbus, or what not, esp on pre-acpi systems. I've got a stable of them here at home, and linux is starting to get to a point where I'll have to migrate them to BSD just to stay running.
airlied: Telek: why do they not work with Linux?
airlied: or is it just distros are too big?
Telek: It's the core system files are getting too big.
Telek: glibc/gcc/linux kernel keep bloating out and slowing down.
airlied: Telek: well gcc is the same on BSD..
Telek: Plus there's like 2-3x the library requirements to get a basic system up now. (And yes, you CAN, given that I have one with SUSE 11.0 installed on it, but it runs like mush, and has barely enough memory to run firefox and one other app.
airlied: Telek: BSD would have the same problem with firefox type apps.
airlied: Telek: if you are trying to run the modern desktop apps on older hardware yes it will suck, no matter what OS you install
Telek: airlied: Yeah, but especially with the modern linux distros you can't install small enough to make due even using the same set of apps you did 4 years ago.
airlied: Telek: but they aren't the same apps, firefox from 4 years ago isn't firefox from toady..
Telek: nods.
airlied: Telek: you can get Debian on most of those style systems in a low memory foot print I would expect.
airlied: using an xfce desktop
Telek: I question though if that's a matter of features or bloat.
Telek: Point taken.
Telek: Debian is good that way.
airlied: Telek: well I would say bloat as well, but I wouldn't blame the core OS as much as I would the apps.
airlied: I don't think the kernel has gotten that much worse, granted generic kernel builds are going to be a bit painful.
airlied: as they contain every feature under the sun.
Telek: Maybe not.
Telek: I do know 2.6 vs 2.4 is 1.5x as big image-wise.
airlied: Telek: same config?
Telek: should check on glibc sizing between 2.8, 2.3 and 2.0
Telek: airlied: Yeah, using the same .config file updated for driver name changes.
airlied: Telek: I'd guess playing with some of the CONFIG_EMBEDDED options could drop that down a lot
Telek: Possibly now, they were available when I tested that though.
airlied: granted things like alternatives have increased the code size as the same kernel is used on UP and SMP
airlied: whereas 2.4 didn't do that
airlied: but I would also expect BSD kernels to have increased with features..
Telek: nods.
Telek: I'd have to go check, since it's been a few years since I had a BSD box up, but FreeBSD 4.5 to 5.0 I don't think size changed much for me (Ballpark versions there, I think I got it updated to 5.0 then due to wiring difficulties took it offline).