kokachev: guys.. When do you plan to support tv-out?
udovdh: FWIW: http://core.tweakers.net/nieuws/51173/amd-introduceert-notebook-gpus-met-directx-101-en-displayport.html
udovdh: (yes, in dutch)
udovdh: but it mentions newer AMD (ATI) GPU's for notebooks
libv: rehabdoll: the ati specific dongle can be detected through i2c
libv: rehabdoll: the other one probably cannot be detected
libv: rehabdoll: this is why ATI claims this
libv: rehabdoll: but don't worry, we will of course provide a workaround for this
rbmorse: Hi guys! Mostly fooling around, but I do want to report that the latest git (26c6) works fine on Ubuntu 8.04 Alpha2 with the 2.6.24-3 kernel they pushed last night. The video card is an R580+ (single display).
rehabdoll: libv: sweeet
libvde: caramba: first of all; hdmi is just dvi on a different connector, and with audio thrown in on the same signals
libvde: caramba: where the dongle comes in is a) getting from one connector to the other b) possibly use it for detecting whether we can enable audio or not
libvde: caramba: you do need to have an rs6xx or r6xx to be able to even think about getting audio over hdmi to work as the functionality is not present on r5xx
caramba: Hi. Yes I thought so. I can go without sound. There is no dongle that has a separate plug-in for SPDIF?
libvde: caramba: this would be some highly intelligent dongle :)
caramba: heh okay ;) just a thought
libvde: caramba: the difference between the ati dongle and other dongles is that we can detect whether the ati dongle is there and that we probably cannot do so on the cheap ones
Zhenech: libvde, btw, did you have time to look at alex' hacks for tvout on r5xx? in xf86-video-ati
libvde: Zhenech: we are looking into this, yes
Zhenech: nice :)
caramba: Would there be another reason to know about the dongle, except for sound tweaking?
libvde: caramba: not really
libvde: not in a way that will limit functionality
libvde: we could do a nice message in the log ;p
caramba: So with your previous comment you meant, that once the card outputs a correct digital DVI signal, the HDMI dongle is never a issue for the graphics driver... It will "always work" provided the dongle is ok?
libvde: caramba: there are also dvi-hdmi cables and such
libvde: caramba: they contain no special logic
caramba: libvde: I see. And the radeonhd driver already deals with DVI output right?
libvde: yup :)
caramba: so it must be a configuration issue that I can't get image. I will try the advice I got yesterday.
libvde: caramba: what hardware is this again?
caramba: HD 2600 of some manifacturer, I can't recall...
caramba: so I guess it goes under r6xx
libvde: ok, and it doesn't detect dvi properly?
caramba: libvde: Well xrandr tells me that the 2nd (digital) output is connected. It's just that it's always a black screen, probably no signal.
caramba: ...on the TV
libvde: on the hdmi capable tv
caramba: yes
libvde: is its edid block shown in the log?
caramba: pardon me, what log is that?
wltjr: is loving all these people with the same chipset as me :)
libvde: /var/log/Xorg.0.log
libvde: wltjr: the hd2600 is a pretty cheap card with a load of good features
wltjr: is cheap :)
libvde: it's just a good buy :)
wltjr: I thought so, comparable nvidia would have costed 2x as much or more
wltjr: these are what I was considering when I decided on the 2600 -> http://tinyurl.com/2q4dpt
caramba: libvde: Yes there is a row with EDID, is it what comes beneath it that's significant?
caramba: there's a bunch of these, for each resolution: Not using default mode "1024x768" (vrefresh out of range)
libvde: caramba: how many monitors are attached atm?
libvde: only the tv?
caramba: well that was an old log record, for what it's worth
caramba: I have one D-SUB monitor (DVI->VGA), and then the other with the dongle, both are always connected
caramba: the TV is not always switched on though, if that matters
libvde: ok, and the one with the dongle is found as a dvi device?
caramba: yes
libvde: it just doesn't come up
caramba: correct
caramba: I see in the log: EDID for output DVI-I_1/digital
libvde: ok, then we do need a log sent in to the mailinglist :)
caramba: I'll do that.
libvde: can you describe your problem there and include a log? that way we will not forget
caramba: and subscribe
caramba: sure. thank you for the support.
libvde: :)
libvde: it might be a few days until we can get to this issue though, we are gathering a bit of a backlog there at the moment
caramba: no problem
wltjr: libvde: FYI was messing with a live git ebuild for Gentoo, once I get it working, I will likely commit it to tree so we can easily test sources and etc
wltjr: unless one is already floating around :) we have lots of places to stick stuff
libvde: cool :)
libvde: so if we break stuff, the gentoo people will be the first to complain :)
yangman: that's what hard masks are for ;)
wltjr: yep, no keywords and etc :)
wltjr: libvde: that's kinda the idea, so we can report back faster and help expedite dev
theclaw: hi
HeroreV: Is there some way I can contribute? The handful of bugs in the tracker all look way too hard for me, and I don't have a clue what those specs are saying. But I still want to help. Is there anything I can do?
libvde: HeroreV: the first step is always to use the driver and report whatever problems you encounter :)
HeroreV: When I try to change resolution, whether through xrandr or the KDE settings GUI, the X server restarts. I get thrown back to KDM.
caramba: libvde: Oh, I made a breakthrough with my DVI output. I actually got an image on the TV, when switching to xrandr --mode 640x480
caramba: I never bothered to try that one before ;) All other mode gives just a black screen.
libvde: caramba: so we were attempting a mode that the screen wouldn't accept?
libvde: caramba: weird
libvde: caramba: can you still send in the log so we can see what it claims to support?
caramba: sure I will do that
caramba: Could it have something to do with rates?
libvde: could be indeed
Daemonik: Has AMD released enough actual hardware specs for the RadeonHD driver to be able to achieve the same or better performance as the fglrx driver in the future?
ajax: not yet.
Daemonik: What about the Radeon driver?
airlied: Daemonik: same specs :)
airlied: and when ppl same performance they mean different things, 2D, 3D, movie..etc
Daemonik: Are any AMD engineers working on the RadeonHD driver?
airlied: Daemonik: no.
Sir_Lewk: thank god :P
Daemonik: Heh
Daemonik: Yeah looking at fglrx it's probably a good thing. But this is the second largest processor company in the world. They have the leverage to make this happen. Is it too early to call bullshit because the fglrx driver hasn't officially been abandoned?
airlied: Daemonik: are you like a journalist or something?
airlied: Daemonik: you can call bullshit but I don't think anyone cares..
airlied: Daemonik: where did you hear they would abandon fglrx?
Daemonik: airlied, I didn't. If they have any faith in the RadeonHD project which they are backing by releasing specs, why are they wasting resources on fglrx?
Sir_Lewk: they want something they can support (however little) themselves
airlied: Daemonik: because radeonhd isn't a replacement for fglrx..
airlied: Daemonik: they have customers also who pay money..
Daemonik: airlied, What would fglrx keep doing that RadeonHD wouldn't?
Sir_Lewk: so they can say that *technically* the cards are supported for linux
Daemonik: Ahh
airlied: Daemonik: things they can't legally release ever..
Sir_Lewk: yeah, there are IP issues with their current cards
ajax: and things that their customers want that the open source community historically hasn't cared enough to implement.
ajax: (stereo 3d, for example)
Daemonik: airlied, Being the second largest processor company, I think they _can_ if they want to bad enough. They just currently may not.
airlied: and wierdass overlays..
Daemonik: ajax, Then shouldn't they implement that in their own version of the RadeonHD driver?
airlied: Daemonik: no they can't... it doesn't matter wha size the company is..
ajax: Daemonik: why? they already implemented it in fglrx, why do it twice?
ajax: that's time (read: money) they don't need to spend.
airlied: ajax: but but they are the second but but :)
ajax: being a large company doesn't mean you have cash to burn.
ajax: (man, if only.)
Daemonik: But fglrx sucks. If the RadeonHD project is realistic won't customers eventually want to use that driver instead?
ajax: Daemonik: maybe they will! when that glorious day comes, amd will reconsider their strategy.
ajax: but here in reality, that's just not an option.
airlied: Daemonik: you also cna't write a new driver in < than a year..
airlied: to support all the cards fglrx supports..
Daemonik: Hopefull Intel releases gaming grade GMA chips to give a decent shove to this situation. >_>
Daemonik: Ah
Sir_Lewk: and hopefully I win the lottery ;)
airlied: Daemonik: Intel have no customers for gaming grade chips.
airlied: unfortunately..
Daemonik: airlied, The GMA X4000 is gaming grade for some games. =)
airlied: Daemonik: yes it can play games, but its hardly a G80...
airlied: or X1950XTX
Sir_Lewk: they'd be breaking into a market that is already saturated, even if their cards had nice linux support the vast majority of people buying gaming grade cards wouldn't care
Daemonik: Reason I care here is, I work for a company that sells GNU/Linux desktops to small to medium-sized businesses, and we're limited to Intel GMA chips right now.
airlied: businesses don't care about games though..
airlied: they like onboard graphics, one less bit to replace..
Daemonik: Yeup, which means we are anti-AMD and anti-Nvidia (as far as GPUs) at the moment.
mstrobert: Daemonik: "This [open source] new driver is ideal for FOSS enthusiasts and those wishing to run the latest development kernels and versions of X.Org. The fglrx driver will continue full steam ahead with their monthly releases and will be for those who want a stable driver with top-notch performance, all of the bells and whistles, and avoid checking out the latest git code in order to get the latest fixes and features." ( http://www.phoronix.com/
mstrobert: scan.php?page=article&item=826&num=1 ). Also, http://www.beyond3d.com/content/interviews/43/2 indicates that the fglrx and radeonhd will co-exist; fglrx might have better performance. But those of us who have used proprietary drivers will of course realize that the open-source driver will work better for personal Linux users (i.e., those using the latest release of their favorite distribution).
mstrobert: sorry, that was big.
mstrobert: bah, x-chat split my URI :)
Daemonik: If only fglrx actually were stable. :
Daemonik: goes to actually read that.
mstrobert: Daemonik: at http://www.beyond3d.com/content/interviews/43/2 , look at the "Will the new open source driver ever completely replace ..." section.
Daemonik: Thanks mstrobert
mstrobert: yup.
HeroreV: How do I build a debug build of RadeonHD?
soc: Daemonik: is the GMA X4000 already released?!
Daemonik: soc Unfortunately no.
libvde: ajax: stereo sync has enough info out i think, just no point
libvde: airlied: "weirdass overlays"... trivial, just takes time which is not well spent atm
libvde: HeroreV: you basically set CFLAGS to -g -O0 to have something decently gdbable
libvde: HeroreV: otherwise, we have a nicely working Xorg -logverbose 7, which we actively use
libvde: HeroreV: so if you have a problem, and you want to send in a log, run the xserver with that serverflag
airlied: libvde: everything takes time... its all about return on investment..
airlied: as in spending 3 days on a feature 2 ppl will use is not a great ROI..
airlied: but getting paid to add that feature for 2 ppl makes it worth it..
libvde: sure, but the overlay looks like a it is just a few days of quick fun, as the implementation seems rather clean
airlied: make it useful with 3D which is the only use for the r500 by the looks of it though is where the fun is..
libvde: i'm sure that an xvmc like XvPutImage with a buffer handle as the data (for the buffer into which is being rendered in) is a rather quick solution there
marcheu: may I ask what's weird about the overlay ?
libvde: marcheu: only 1:1/1:2 scaling and rather limited FOURCCs
libvde: marcheu: so not really useful for video playback
marcheu: fourcc as in pixel format ?
libvde: marcheu: yup
marcheu: what does it handle ? AFAIK YV12 is all you ever need
libvde: marcheu: i think it is like packed RGBA and YUVA and that's it
libvde: marcheu: little hazy on the actual details there, but it is in the docs
libvde: marcheu: no YV12 without serious manual conversion :)
marcheu: weird
marcheu: yeah weirdass qualifies... I even wonder what it's there for
libvde: marcheu: so our take on it is that this is used for certain workstation purposes, where gl is still rendered in an overlay
airlied: ACrYCb 8888 or ARGB 8888
marcheu: oh makes sense, that's why you have per pixel alpha
ryanpg: well, I'm pretty excited and hopeful about radeonhd now that I've read the phoronix forums - seems fglrx is pretty much a disaster :)
ryanpg: radeonhd is working pretty reliably on my RS690M [Radeon X1200 Series] based toshiba satellite
ryanpg: is adding 2D/3D acceleration near the top of the list after the next code/documentation drop?
libvde: ryanpg: 2D/3D as far we understand basically means porting over a rather limited amount of code from the -ati driver
libvde: ryanpg: as rs690 is r4xx acceleration with r6xx modesetting
ryanpg: libvde, I kinda got that impression from reading the threads yeah
ryanpg: libvde, so it's a matter of man-hours then I'm guessing - and priorities?
libvde: yup
HeroreV: Is "startx -- -logverbose 7" an appropriate way of running "Xorg -logverbose 7"? It seemed to work. I think the problem is that rhdRRXF86CrtcResize is being called with a null parameter. Should I file a bug or something?
libvde: HeroreV: there is /etc/X11/xinit/xserverrc where you can add this :)
libvde: HeroreV: but for basic modesetting issues, with a remote login, Xorg -logverbose 7 is often enough for debugging :)
HeroreV: will it be detrimental to performance to have logverbose on 7 all the time?
libvde: HeroreV: this is still modesetting :)
libvde: HeroreV: it only happens once in a while :)
libvde: HeroreV: we wouldn't dream of having this in things which should happen thousands of times per second :)
dmb: hey
dmb: smacks PinkFreud
dmb: is there any dri acceleration yet for the r5xx chipset?
marcheu: no, because there are no 3D docs either
dmb: marcheu: you think they will ever be released?
marcheu: AMD said they'll release 3D sample code
dmb: marcheu: so does that mean there is no video support either?
marcheu: that's correct
marcheu: although it seems to work if you have a beefy cpu
dmb: oh :/
dmb: marcheu: i don't understand how you guys can read these huge 900 page documents
marcheu: I don't, I do nouveau
dmb: marcheu: is nouveau the nvidia open source driver?
marcheu: yeah
dmb: oh
dmb: marcheu: hows that project going anyway?
marcheu: http://nouveau.freedesktop.org/wiki/FeatureMatrix
marcheu: but it's getting pretty off topic :)
dmb: oh