Nightwulf|work: hi all
kcodyjr: hrm. hey airlied, it seems that drmCheckModesettingSupported invalidates the fd if called after Open()?
kcodyjr: airlied, should i expect your kms kernel to miss the DIN tv/component connector?
airlied: kcodyjr: yes even userspace doesn't do tv-out yet
kcodyjr: not pushing, just wanted to know if the connector should show up in the drmModeRes list
kcodyjr: though you inspire me to wonder, what userspace would be required to put a logical crtc on a tvout connector
airlied: kcodyjr: no I mean even the userspace radeon drivers don't have tv-out on r600 that works
airlied: I've yet to port it what I got working to the kernel.
MostAwesomeDude: Okay, from now on, non-Gallium Mesa is "classic Mesa."
MostAwesomeDude: Because "legacy" is just too mean.
kcodyjr: MostAwesomeDude, is it really too mean?
MostAwesomeDude: kcodyjr: Sure. After all, it'll stay in use for all of the non-shaderful chipsets.
ernstp: to enable the "DRI" option you need to build a kernel module, don't you?
kcodyjr: nods. is that going to insanely complicate distro setup? i mean, can the Gallium and classic mesa's coexist on the same machine?
MostAwesomeDude: I hope so.
kcodyjr: understood ;)
kcodyjr: of course, anyone running an old and new card together is asking for it anyway. i'd think that only one really needs to load at once... though i suppose full legacy compat would be -nice-...
MostAwesomeDude: Well, there's the more important matter of what a distro is supposed to package.
kcodyjr: i'd imagine for the time being, they will have to package both somehow - IMO a distro is not allowed to make such broad decisions at install time
MostAwesomeDude: Well, we'll see.
kcodyjr: are the properties and modelists associated to the Connector because some cards let you drive multiple connectors from a single crtc?
nanonyme: kcodyjr: "a distro is not allowed to make such broad decisions at install time" meaning we can expect Ubuntu and Fedora will drop classic Mesa? :P
kcodyjr: lol no i meant exactly the opposite
kcodyjr: a distro shouldn't dictate, "you will use only newer video cards"
nanonyme: Oh, I thought you were only referring to the distros who abide common sense. ;)
nanonyme: That rules Fedora and Ubuntu out.
kcodyjr: actually, ubuntu is a paragon of common sense compared to its upstream
nanonyme: kcodyjr: And really, haven't they already done that by putting Compiz on by default? :)
MostAwesomeDude: kcodyjr: You've got that backwards. :3
kcodyjr: that's something that can be easily turned off
kcodyjr: incompatible mesas are something else entirely...
nanonyme: Well, that's a non-issue with a sane virtual package system.
kcodyjr: nanonyme, which leads us back t the common sense issue... ;)
nanonyme: Indeed.
nanonyme: kcodyjr: And since Ubuntu doesn't know how to use the virtual package system in a sane manner...
kcodyjr: there is that. i was talking about debian's fanatical views on "true open source"
nanonyme: Ah.
kcodyjr: ice weasel.
kcodyjr: might as well have called evolution "spanking monkey", in honor of ximian, and just to keep with the trend ;)
nanonyme: *shrug* I think Linus' opinion in the matter is fine.
nanonyme: He takes the engineer approach and thinks politics shouldn't interfere with opensource programming.
kcodyjr: which i quite concur with
kcodyjr: far as i can tell, ice weasel was purely political
nanonyme: Actually the matter was pushed through Debian's lawyers. Apparently they wanted to drop some parts of Firefox off but they couldn't do it and still call the product Firefox.
MostAwesomeDude: Protip: Iceweasel and Icedove were done because Mozilla Foundation was not willing to permit free usage of its trademarked names and artwork.
nanonyme: Iirc artwork.
nanonyme: MostAwesomeDude: You can use the trademarked name if you use the artwork.
nanonyme: Debian didn't want to use the artwork because it's non-free according to their lawyers => they needed a rename.
MostAwesomeDude: nanonyme: But they can't use the artwork unless they follow a very specific patch review process which doesn't actually make the resulting artwork free.
nanonyme: MostAwesomeDude: Sure, just wanted to keep the causality chain clear here.
MostAwesomeDude: And, to Debian, it was more important that patches be pushable immediately, then to have the official artwork.
nanonyme: Artwork was the reason, rename was the result.
MostAwesomeDude: Frankly, I agree with Debian on this point.
kcodyjr: seems pretty silly to me: why does debian seem to be the only distro that has a problem with it?
nanonyme: Also iirc there were conflicting opinions on the freeness of the artwork from Debian side. I suppose they just decided to play safe.
kcodyjr: they came off seeming like they decided to play zealot, possibly that's merely a pr problem though
kcodyjr: i mean, forking (even trivially) something the size of firefox is a pretty heavy handed thing to do. was the patch review process really sooooo onerous?
MostAwesomeDude: Clearly you've never seen Mozilla's development process. :3
MostAwesomeDude: But, at any rate, Debian's forked tons of stuff over the years, and it's never really been a bad idea.
kcodyjr: no. browsers are something i've kept on the easy side of the compiler. ;)
MostAwesomeDude: I mean, you wanna talk about big forks, what about XF86?
kcodyjr: that is a huge honkin fork, and i wasn't aware debian had done it
MostAwesomeDude: Not Debian, no.
kcodyjr: oh you mean way back when
MostAwesomeDude: But I'm just saying that Debian's not the only forker.
MostAwesomeDude: Hm. "Fork" is a weird verb.
kcodyjr: certainly is when you try to conjugate it ;)
nanonyme: kcodyjr: They didn't technically fork it.
nanonyme: They just took out the non-free stuff and renamed it.
nanonyme: They still pull new versions from upstream.
kcodyjr: nanonyme, that's why i called it a 'trivial' fork. that essentially dies and gets reforked on each upstream release. ;)
kcodyjr: how many forks could an ice weasel fork if a weasel could fork forks ;)
nanonyme: >.<
nanonyme: Luckily ice weasels don't fork.
kcodyjr: no, or we'd all be forked
kcodyjr: yeow. airlied, i'm seeing lots of EDID failures - that expected?
airlied: if EDID fails yes.
airlied: need to knock down the severity probably
kcodyjr: well, the last one shut down my console
adamk: Bah.
rehabdoll: any interesting commits in the near future?
loki_666_: how to deal with overscan/underscan?
kcodyjr: airlied, there is definitely something random going on in the modesetting
kcodyjr: i just rebooted 4 times and got 3 different behaviors
kcodyjr: 1st time, crt was connected but powered off, the panel got 1920x1080 but put its console in the first 800x600. second time, both screens stayed black. pulled the vga cable, 3rd time was also black, and i noticed it had set a DAC on DVI-I rather than TMDS. 4th time, i got a clean full screen console.
rindolf: Hi all.
rindolf: When will the r6xx-r7xx branch work on AGP cards?
lucxxx: hy all
lucxxx: any fixes or patches for radeon hd3200?
Honk: read the svn logs ;P
nanonyme: Honk: Hmm, did you mean git?
Honk: whatever ;p
nanonyme: Nothing new in r6xx-r7xx-support front, apparently.
lucxxx: I was asking for out side patches or something
lucxxx: i saw that there is no change on git
Zajec: how can I compile rhd_dump?
Zajec: pwd && make
Zajec: /home/zajec/xf86-video-radeonhd/utils/conntest
Zajec: make: *** No targets specified and no makefile found. Stop.
nanonyme: Hrm?
nanonyme: Zajec: Is that in r6xx-r7xx-support branch?
Zajec: nanonyme: no, master
Zajec: ls gives: Imakefile Makefile.am README rhd_conntest.c rhd_dump.c
nanonyme: Zajec: Have you run configure?
Zajec: in main dir? didn't think it can affect ./utils/conntest
Zajec: will try of course
nanonyme: Zajec: It's the most common way to make Makefile's out of Makefile.am's.
yangman: Zajec: rhd_conntest and rhd_dump compiles automatically when you compile the driver
nanonyme: yangman: Shouldn't you be able to compile them separately after having ran configure though?
Zajec: uhh, i didn't know about many thing i see :)
yangman: automake; make ?
nanonyme: Automake? Hmm.
nanonyme: Zajec: There's always a many things one doesn't know.
nanonyme: s/a //
Zajec: :) works with simple ./autogen.sh && make
nanonyme: Yups.
ernstp: is there any vsync support in the radeonhd driver?
kdekorte: Anything new in the r6xx branch to test?
nanonyme: kdekorte: http://cgit.freedesktop.org/xorg/driver/xf86-video-radeonhd/atom/?h=r6xx-r7xx-support there's an RSS feed for the changes, you know. :)
kdekorte: nanonyme, oh, I've been updating from git, but just getting minor withdrawals from no knew patches... ;)
nanonyme: Hmm?
nanonyme: kdekorte: No idea what you meant by that.
_Steve_: i know what kdekorte means, there haven't been a lot of commits in the last week or so
_Steve_: doesn't mean nothing is happening, of course
nanonyme: Ah, he meant that. :)
nanonyme: Yeah, actually I've kept telling myself it probably means big changes are happening.
nanonyme: As in, big changes => rare commits, small tweaks => frequent commits.
_Steve_: yeah
_Steve_: that's what i was thinking too
nanonyme: Meaning we might get some badass experimental code to test in near future. ^^
kdekorte: _Steve_, yeah that is what I am hoping too...
nanonyme: kdekorte: Well, either that, a vacation or someone got their fingers cut and can't code. In any case, no can't rush the code artists. ^^
kdekorte: Yup, I agree no point in rushing someone to get done, but still it is fun to play with the 1/2 working stuff at times
nanonyme: That's the very reason I have the radeonhd and drm r6xx-r7xx-support branch RSS feeds in my live bookmarks. ^^
nanonyme: Btw, any ideas on how to reduce vibration from a TFT?
nanonyme: This looks awful in 1280x1024.
nanonyme: Maybe it's just the display failing, just pressed autoadjust and the problem seemed to disappear. >.<
yangman: you mean flickering, right? because I'd be really worried if a TFT is vibrating noticibly
nanonyme: Hmm, yeah, I guess. The text just doesn't stay clear in some sections of the display but looks a bit shaky.
nanonyme: Hoping this will last long enough that I can replace it with a Full HD display with DVI-D.
nanonyme: Should reduce problems to a very minimum. (I currently use DVI->VGA adapter since the display only has a VGA connector)
nanonyme: Impressive. Apparently modern computers can run Google Earth fine without GPU rendering.
nanonyme: (Note that my fine means no painful latencies)
Enverex: Just a question about GIT and branches. I see r6xx-r7xx-support is a "branch" of the radeonhd driver. If I compile from GIT does it include all those or do I have to switch to that specific branch?
MostAwesomeDude: Branches are invisible to the automake system.
MostAwesomeDude: You must tell git to change branches with "git checkout r6xx-r7xx-support".
Enverex: hmm.. any particular reason 600/700 isn't part of the master?
MostAwesomeDude: ...And I just remembered that you probably don't have it branched, so maybe you'll need "git checkout -b r6xx-r7xx-support origin/r6xx-r7xx-support".
MostAwesomeDude: Sure, not well-tested, still experimental, for developers only.
MostAwesomeDude: Consider that nobody's ported it to radeon yet. :3
Enverex: The whole "two projects for the same thing" kinda makes me lose faith in the OS driver entirely :/
yangman: Enverex: eh?
yangman: Enverex: are you not familiar with the concept of branches?
Enverex: yangman, They don't seem to be forking anything though, just looks like duplicated effort doing the same thing, but I may be ill informed
yangman: Enverex: are we talking about radeon vs radeonhd or master vs branch-X?
Enverex: radeon vs radeonhd
yangman: ah
yangman: lets not get into that... long story
MostAwesomeDude: Enverex: If it makes you feel better, only one person's working on Gallium stuff, so it's impossible for there to be a fork there. :3
Enverex: MostAwesomeDude, ... yay... no progress through lack of resources...
MostAwesomeDude: Enverex: "I am not a resource, I am a human being!" :3
MostAwesomeDude: Honestly, it's more due to people not being interested, then anything else.
MostAwesomeDude: And X work is hard.
MostAwesomeDude: Hell, I've got the easy job. The guys that actually do X core stuff are crazy.
Enverex: heh, it just seems odd, one of the things that is so core to the system has such little actually piped into it
airlied: Enverex: it has quite a bit piped into it considering Linux as a desktop OS doesn't really make any money
Enverex: hmm, true. But it's kinda a vicious circle. No-one wants to play games on an OS that doesn't have drivers in a state where you can actually play them :P
airlied: games don't drive that much sales.
airlied: compiz actually drives way more development than games, annoying as that is.
Enverex: "omg, spinning boxx!!!11". Yeah, seen that -way- too much
airlied: most of my development is purely to make graphics smooth, compiz run, and try and maintain stability
Exy: Hmm, I'm getting good 2D performance with EXA and radeonhd with DRI but it locks up after 5 seconds. I believe the key for that is to add another option to xorg.conf but I think that ends up crippling it so it's unbelievably slow...
Exy: I'm also getting crazy fast speeds with gtkperf with EXA enabled on an X1700
Exy: Wow, gtkperf times, EXA: 23.41, EXANoComposite (which is needed to stop the crashes): 132.77... that's .. not good
yangman: Exy: http://bugs.freedesktop.org/show_bug.cgi?id=18097 ?
atokhy: Hello
atokhy: I noticed with radeonhd version 1.2.4 I cannot change my brightness. I can do this when switching to the radeon driver. Also, in 1.2.4, I see some virtual terminal corruption (spaces added/removed when scrolling in gnome-terminal)
atokhy: are these known issues?
_moep_: where can i found in the .git something like a changelog?
MostAwesomeDude: _moep_: "git log", "git whatchanged"
_moep_: thx
MostAwesomeDude: NP.
Daemonik: Is the radeonhd driver stable? Is EXA support stable?
nanonyme: Which card is this for?